Detail client-constructed landmark-relative construction

Flesh out how a party holding a standalone certificate constructs a
landmark-relative certificate for the same entry, and cross-reference
the MTC-TLOG profile from the log-serving and cost discussions.

Author: lukevalenta

draft-ietf-plants-merkle-tree-certs.md

@@ -1052,7 +1052,7 @@ This protocol aims to enable monitors to detect misissued certificates by observ
 
 This document does not prescribe a particular method of observing the issuance log. The access protocols do not affect certificate interoperability, and different applications may have different needs. For example, a PKI that authenticates public services might publicly serve issuance logs, while a PKI that authenticates a single organization's intranet services might keep the log private to the organization. Relying parties SHOULD define log serving requirements, including the allowed protocols and expected availability, as part of their policies on which CAs to support. See also {{log-availability}}.
 
-For example, a log ecosystem could use {{TLOG-TILES}} to serve logs. {{TLOG-TILES}} improves on {{?RFC6962}} and {{?RFC9162}} by exposing the log as a collection of cacheable, immutable "tiles". This works well with a variety of common HTTP {{?RFC9110}} serving architectures. It also allows log clients to request arbitrary tree nodes, so log clients can fetch the structures described in {{subtrees}}.
+For example, a log ecosystem could use {{TLOG-TILES}} to serve logs; {{MTC-TLOG}} defines such a profile for Merkle Tree Certificates. {{TLOG-TILES}} improves on {{?RFC6962}} and {{?RFC9162}} by exposing the log as a collection of cacheable, immutable "tiles". This works well with a variety of common HTTP {{?RFC9110}} serving architectures. It also allows log clients to request arbitrary tree nodes, so log clients can fetch the structures described in {{subtrees}}.
 
 ### Log Pruning
 
@@ -1422,7 +1422,19 @@ Given the inputs in {{certificate-inputs}} and a landmark sequence, a landmark-r
 
 Before sending this certificate, the authenticating party SHOULD obtain an application-protocol-specific signal that implies the relying party has been configured with the corresponding landmark. ({{trusted-subtrees}} defines how relying parties are configured.) The trust anchor ID of the landmark may be used as an efficient identifier in the application protocol. {{use-in-tls}} discusses how to do this in TLS {{!RFC8446}}.
 
-The procedure above is not specific to the CA. Any party with access to the certificate inputs ({{certificate-inputs}}), the issuance log, and the landmark sequence can construct a landmark-relative certificate. {{MTC-TLOG}} describes such a procedure for an authenticating party holding a standalone certificate, in log ecosystems based on {{TLOG-TILES}}.
+The procedure above is not specific to the CA. Any party with access to the certificate inputs ({{certificate-inputs}}), the issuance log, and its landmark sequence can construct a landmark-relative certificate. In particular, a party holding a standalone certificate ({{standalone-certificates}}) for an entry can construct a landmark-relative certificate for the same entry, without any CA-specific issuance service, as follows:
+
+1. Recover the certificate inputs ({{certificate-inputs}}) from the standalone certificate. The TBSCertificateLogEntry fields and subject public key are those of the standalone certificate, and the log entry's `extensions` are carried in the standalone certificate's MTCProof ({{certificate-format}}). The CA ID is the certificate's issuer ({{ca-ids}}), and the log number and entry index are recovered from the serial number, which is `(log_number << 48) | index` ({{certificate-format}}).
+
+1. Obtain the CA's landmark sequence, for example from its published active landmarks ({{publishing-landmarks}}).
+
+1. Produce the subtree inclusion proof ({{subtree-inclusion-proofs}}) by reading the necessary hashes directly from the issuance log ({{issuance-logs}}). A party that is aware of a mirror of the issuance log MAY read these hashes from the mirror instead.
+
+1. Construct the landmark-relative certificate following the steps above, selecting the landmark subtree that covers the entry and using no signatures. The result copies every field of the standalone certificate except the `signatureValue`: its MTCProof instead describes the selected landmark subtree and its inclusion proof, and has an empty `signatures` field.
+
+To use such a certificate, the party configures certificate selection as for any landmark-relative certificate ({{use-in-tls}} describes this for TLS). The certificate's landmark trust anchor ID and its single-log landmark group ({{single-log-landmark-groups}}) follow directly from the CA ID, log number, and landmark number. However, if the PKI also uses timestamped landmark groups ({{timestamped-landmark-groups}}) spanning multiple CAs, configuring the corresponding group inclusions requires knowledge of those group definitions, which is not derivable from the issuance log and must be obtained out of band.
+
+The CA does not need to perform any per-entry work to enable this: the landmark sequence and inclusion proof hashes are exactly those already published by the issuance log. {{MTC-TLOG}} specifies this construction for log ecosystems based on {{TLOG-TILES}}, including where to fetch the landmark sequence and the inclusion proof hashes.
 
 ## Size Estimates
 
@@ -1711,7 +1723,7 @@ As an alternative to fetching the landmark-relative certificate from the ACME se
 
 While Merkle Tree certificates expect CAs to operate logs, the costs of these logs are expected to be much lower than a CT log from {{?RFC6962}} or {{?RFC9162}}:
 
-{{publishing-logs}} does not constrain the API to the one defined in {{?RFC6962}} or {{?RFC9162}}. If the PKI uses a tile-based protocol, such as {{TLOG-TILES}}, the issuance log benefits from the improved caching properties of such designs.
+{{publishing-logs}} does not constrain the API to the one defined in {{?RFC6962}} or {{?RFC9162}}. If the PKI uses a tile-based protocol, such as {{TLOG-TILES}} (profiled for Merkle Tree Certificates in {{MTC-TLOG}}), the issuance log benefits from the improved caching properties of such designs.
 
 Unlike a CT log, an issuance log does not have public submission APIs. Log entries are only added by the CA directly. Costs are thus expected to scale with the CA's own issuance.