From 0d8103b3be1035a50022e61fd0460ecd8b1593d7 Mon Sep 17 00:00:00 2001 From: David Benjamin Date: Thu, 21 Aug 2025 13:54:05 -0400 Subject: [PATCH 1/6] Add some diagrams to the Overview section Maybe this will be more understandable? --- draft-davidben-tls-merkle-tree-certs.md | 99 +++++++++++++++++++++---- 1 file changed, 86 insertions(+), 13 deletions(-) diff --git a/draft-davidben-tls-merkle-tree-certs.md b/draft-davidben-tls-merkle-tree-certs.md index 431fc04..2a6a2dc 100644 --- a/draft-davidben-tls-merkle-tree-certs.md +++ b/draft-davidben-tls-merkle-tree-certs.md @@ -278,29 +278,100 @@ Signatureless certificate: # Overview -Merkle Tree certificate issuance begins as in a typical CA: The CA receives an issuance request, e.g. over ACME {{?RFC8555}}, and validates it, e.g. with ACME challenges. From there, the issuance process differs. +In Certificate Transparency, a CA first certifies information by signing it, then submits the resulting certificate to logs for logging. Merkle Tree Certificates inverts this process: the CA certifies information by logging it, then submits the log to cosigners to verify log operation. A certificate is assembled from the result and proves the information is in the CA's log. -1. The CA operates an *issuance log* ({{issuance-logs}}), which is an append-only Merkle Tree ({{Section 2.1 of !RFC9162}}). Unlike a CT log, this log only contains entries added by the CA. +~~~aasvg ++-- Certificate Authority -----+ +-- Authenticating Party ----+ +| | | | +| 2. Validate request <---+----+-- 1. Request certificate | +| | | | | +| | | | | +| V | | | +| | | | +| 3. Add to issuance log | | | +| +---[ CA cosign ] | | | +| / \ ----+----+-> 5. Download certificates | +| / \ | | | +| / \ | | * tbscert | +| +-------+ | | = = = inclusion proof | +| * * * * tbscert entries | | [ CA ] cosignatures | +| | | [ mirror ] | ++------------------------------+ +-----------------------------+ + / | \ + / | \ 4. Submit log to cosigners + V V V for cosignatures + ++-- Mirrors, other cosigners --+ +-- Monitors -----------------+ +| | | | +| +---[ CA cosign ] +-+ | | +| / \ [ mirror cosign ] | | | | +| / \ | | | | +| / \ <-+-+--+-- 6. Monitor CA operation | +| +-------+ | | | | +| * * * * | | +-----------------------------+ ++-+----------------------------+ | + | ...quorum of cosigners... | + +------------------------------+ +~~~ +{: #fig-issuance-overview title="A diagram of the issuance architecture, detailed below"} + +Merkle Tree Certificates are issued as follows. {{fig-issuance-overview}} depicts this process. + +1. The authenticating party requests a certificate, e.g. over ACME {{?RFC8555}} + +2. The CA validates each incoming issuance request, e.g. with ACME challenges. From there, the process differs. + +3. The CA operates an append-only *issuance log* ({{issuance-logs}}). Unlike a CT log, this log only contains entries added by the CA: -2. The CA adds a TBSCertificateLogEntry ({{log-entries}}) to its log, describing the information it is certifying. + 1. The CA adds a TBSCertificateLogEntry ({{log-entries}}) to its log, describing the information it is certifying. -3. The CA signs a *checkpoint*, which describes the current state of the log. A signed checkpoint certifies that the CA issued *every* entry in the Merkle Tree ({{certification-authority-cosigners}}). + 2. The CA signs a *checkpoint*, which describes the current state of the log. A signed checkpoint certifies that the CA issued *every* entry in the Merkle Tree ({{certification-authority-cosigners}}). -4. The CA additionally signs *subtrees* ({{subtrees}}) that together contain certificates added since the last checkpoint ({{arbitrary-intervals}}). This is an optimization to reduce inclusion proof sizes. A signed subtree certifies that the CA has issued *every* entry in the subtree. + 3. The CA additionally signs *subtrees* ({{subtrees}}) that together contain certificates added since the last checkpoint ({{arbitrary-intervals}}). This is an optimization to reduce inclusion proof sizes. A signed subtree certifies that the CA has issued *every* entry in the subtree. -These signatures prove to relying parties that the CA has issued the certificate. +4. The CA submits the new log state to *cosigners*. Cosigners validate the log is append-only and optionally provide additional services, such as mirroring its contents. They cosign the CA's checkpoints and subtrees. -A relying party may require additional proof of the proper operation of the issuance log by third parties, like CT logs provide additional transparency. Instead of presenting certificates to transparency logs, CAs present their log state to *cosigners*. Cosigners validate the log is append-only and optionally provide additional services, such as mirroring its contents. They cosign the CA's checkpoints and subtrees. +5. The CA now has enough information to construct a certificate and give it to the authenticating party. A certificate contains: -A signature from either the CA or a cosigner is known as a *cosignature*. A combination of cosignatures from sufficient trusted parties proves both that the CA has issued the certificate, and that the issuance satisfies any additional relying party transparency requirements. + * The TBSCertificate being certified + * An inclusion proof from the TBSCertificate to some subtree + * Cosignatures from the CA and cosigners + +6. As in Certificate Transparency, monitors observe the issuance log to ensure the CA is operated correctly. + +A certificate with cosignatures is known as a *full certificate*. Analogous to X.509 trust anchors and trusted CT logs, relying parties are configured with trusted cosigners ({{trusted-cosigners}}) that allow them to accept Merkle Tree certificates. The inclusion proof proves the TBSCertificate is part of some subtree, and cosignatures frm trusted cosigners prove the subtree was certified by the CA and available to monitors. Where CT logs entire certificates, the issuance log's entries are smaller TBSCertificateLogEntry ({{log-entries}}) structures, which do not scale with public key or signature size. -A *full certificate* contains: +This same issuance process also produces a *signatureless certificate*. This is an optional, optimized certificate that avoids cosignatures. Signatureless certificates are available after a short period of time and usable with up-to-date relying parties. -* The TBSCertificate being certified -* An inclusion proof from the TBSCertificate to some subtree -* Sufficient cosignatures to meet the relying party's requirements +~~~aasvg ++-- Certificate Authority -------+ +| | +-- Update Channel --+ +| /\ | | | +| / \ 1. Allocate landmarks -+--+----------------+ | +| +----+ | | | | | ++--------------------------+-----+ +----------------+---+ + | | + 2. Make signatureless | 3. Distribute | + cert from landmark | landmarks | + V | ++-- Authenticating Party --------+ | +| | | +| signatureless cert | V +| tbscert | +-- Up-to-date RP -----+ +| inclusion proof to landmark -+->| landmark hashes | +| | | trusted cosigners | +| | +----------------------+ +| full cert | +| tbscert | +-- Unupdated RP ------+ +| inclusion proof | | (stale or no hashes) | +| cosignatures ------------+->| trusted cosigners | +| | +----------------------+ ++--------------------------------+ + 4. Select certificate by RP +~~~ +{: #fig-signatureless-overview title="A diagram of signatureless certificates construction and usage, detailed below"} -This same issuance process also produces a *signatureless certificate*. This is an optional optimized certificate that avoids any cosignatures: +Signatureless certificates are constructed and used as follows. {{fig-signatureless-overview}} depicts this process. 1. Periodically, the tree size of the CA's most recent checkpoint is designated as a *landmark*. This determines *landmark subtrees*, which are common points of reference between relying parties and signatureless certificates. @@ -1470,3 +1541,5 @@ In draft-04, there is no fast issuance mode. In draft-05, frequent, non-landmark - Rename 'landmarks checkpoint' to 'landmarks' - Clarify and fix an off-by-one error in recommended landmark allocation scheme + +- Add some diagrams to the Overview section From 5de8682c8d185e0fa13257420f0af8904da5541e Mon Sep 17 00:00:00 2001 From: David Benjamin Date: Fri, 22 Aug 2025 14:57:39 -0400 Subject: [PATCH 2/6] Update draft-davidben-tls-merkle-tree-certs.md Co-authored-by: Luke Valenta --- draft-davidben-tls-merkle-tree-certs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-davidben-tls-merkle-tree-certs.md b/draft-davidben-tls-merkle-tree-certs.md index 2a6a2dc..fdc35eb 100644 --- a/draft-davidben-tls-merkle-tree-certs.md +++ b/draft-davidben-tls-merkle-tree-certs.md @@ -278,7 +278,7 @@ Signatureless certificate: # Overview -In Certificate Transparency, a CA first certifies information by signing it, then submits the resulting certificate to logs for logging. Merkle Tree Certificates inverts this process: the CA certifies information by logging it, then submits the log to cosigners to verify log operation. A certificate is assembled from the result and proves the information is in the CA's log. +In Certificate Transparency, a CA first certifies information by signing it, then submits the resulting certificate (or precertificate) to logs for logging. Merkle Tree Certificates inverts this process: the CA certifies information by logging it, then submits the log to cosigners to verify log operation. A certificate is assembled from the result and proves the information is in the CA's log. ~~~aasvg +-- Certificate Authority -----+ +-- Authenticating Party ----+ From 4e628bd9affaf22e1899d47a9795fa135f1384e8 Mon Sep 17 00:00:00 2001 From: David Benjamin Date: Fri, 22 Aug 2025 14:57:49 -0400 Subject: [PATCH 3/6] Update draft-davidben-tls-merkle-tree-certs.md Co-authored-by: Luke Valenta --- draft-davidben-tls-merkle-tree-certs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-davidben-tls-merkle-tree-certs.md b/draft-davidben-tls-merkle-tree-certs.md index fdc35eb..0e3b831 100644 --- a/draft-davidben-tls-merkle-tree-certs.md +++ b/draft-davidben-tls-merkle-tree-certs.md @@ -335,7 +335,7 @@ Merkle Tree Certificates are issued as follows. {{fig-issuance-overview}} depict * The TBSCertificate being certified * An inclusion proof from the TBSCertificate to some subtree - * Cosignatures from the CA and cosigners + * Cosignatures from the CA and cosigners on the subtree 6. As in Certificate Transparency, monitors observe the issuance log to ensure the CA is operated correctly. From 8d1988ebf971f4513f4709a4e12843ca62e82a1c Mon Sep 17 00:00:00 2001 From: David Benjamin Date: Fri, 22 Aug 2025 14:57:56 -0400 Subject: [PATCH 4/6] Update draft-davidben-tls-merkle-tree-certs.md Co-authored-by: Luke Valenta --- draft-davidben-tls-merkle-tree-certs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-davidben-tls-merkle-tree-certs.md b/draft-davidben-tls-merkle-tree-certs.md index 0e3b831..2c0116e 100644 --- a/draft-davidben-tls-merkle-tree-certs.md +++ b/draft-davidben-tls-merkle-tree-certs.md @@ -339,7 +339,7 @@ Merkle Tree Certificates are issued as follows. {{fig-issuance-overview}} depict 6. As in Certificate Transparency, monitors observe the issuance log to ensure the CA is operated correctly. -A certificate with cosignatures is known as a *full certificate*. Analogous to X.509 trust anchors and trusted CT logs, relying parties are configured with trusted cosigners ({{trusted-cosigners}}) that allow them to accept Merkle Tree certificates. The inclusion proof proves the TBSCertificate is part of some subtree, and cosignatures frm trusted cosigners prove the subtree was certified by the CA and available to monitors. Where CT logs entire certificates, the issuance log's entries are smaller TBSCertificateLogEntry ({{log-entries}}) structures, which do not scale with public key or signature size. +A certificate with cosignatures is known as a *full certificate*. Analogous to X.509 trust anchors and trusted CT logs, relying parties are configured with trusted cosigners ({{trusted-cosigners}}) that allow them to accept Merkle Tree certificates. The inclusion proof proves the TBSCertificate is part of some subtree, and cosignatures from trusted cosigners prove the subtree was certified by the CA and available to monitors. Where CT logs entire certificates, the issuance log's entries are smaller TBSCertificateLogEntry ({{log-entries}}) structures, which do not scale with public key or signature size. This same issuance process also produces a *signatureless certificate*. This is an optional, optimized certificate that avoids cosignatures. Signatureless certificates are available after a short period of time and usable with up-to-date relying parties. From ffa4e863fcb8962dd1fdf2d074eb53f1a2258651 Mon Sep 17 00:00:00 2001 From: David Benjamin Date: Fri, 22 Aug 2025 14:58:18 -0400 Subject: [PATCH 5/6] Review comment --- draft-davidben-tls-merkle-tree-certs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-davidben-tls-merkle-tree-certs.md b/draft-davidben-tls-merkle-tree-certs.md index 2c0116e..f9fb4a9 100644 --- a/draft-davidben-tls-merkle-tree-certs.md +++ b/draft-davidben-tls-merkle-tree-certs.md @@ -341,7 +341,7 @@ Merkle Tree Certificates are issued as follows. {{fig-issuance-overview}} depict A certificate with cosignatures is known as a *full certificate*. Analogous to X.509 trust anchors and trusted CT logs, relying parties are configured with trusted cosigners ({{trusted-cosigners}}) that allow them to accept Merkle Tree certificates. The inclusion proof proves the TBSCertificate is part of some subtree, and cosignatures from trusted cosigners prove the subtree was certified by the CA and available to monitors. Where CT logs entire certificates, the issuance log's entries are smaller TBSCertificateLogEntry ({{log-entries}}) structures, which do not scale with public key or signature size. -This same issuance process also produces a *signatureless certificate*. This is an optional, optimized certificate that avoids cosignatures. Signatureless certificates are available after a short period of time and usable with up-to-date relying parties. +This same issuance process also produces a *signatureless certificate*. This is an optional, optimized certificate that avoids all cosignatures, including the CA signature. Signatureless certificates are available after a short period of time and usable with up-to-date relying parties. ~~~aasvg +-- Certificate Authority -------+ From d98f2c6cc092819876b96769010791539c2ba124 Mon Sep 17 00:00:00 2001 From: David Benjamin Date: Fri, 22 Aug 2025 15:01:08 -0400 Subject: [PATCH 6/6] Hint at multiple signatureless --- draft-davidben-tls-merkle-tree-certs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-davidben-tls-merkle-tree-certs.md b/draft-davidben-tls-merkle-tree-certs.md index f9fb4a9..78fc362 100644 --- a/draft-davidben-tls-merkle-tree-certs.md +++ b/draft-davidben-tls-merkle-tree-certs.md @@ -382,7 +382,7 @@ Signatureless certificates are constructed and used as follows. {{fig-signaturel 3. In the background, landmark subtrees are predistributed to relying parties, with cosignatures checked against relying party requirements. This occurs periodically in the background, separate from the application protocol. -4. During the application protocol, such as TLS {{?RFC8446}}, if the relying party already supports the landmark subtree, the authenticating party can present the signatureless certificate. Otherwise, it presents a full certificate. +4. During the application protocol, such as TLS {{?RFC8446}}, if the relying party already supports the landmark subtree, the authenticating party can present the signatureless certificate. Otherwise, it presents a full certificate. The authenticating party may also select between several signatureless certificates, as described in {{certificate-renewal}}. # Subtrees