Skip to content

Commit 0d8103b

Browse files
davidbendavidben
committed
Add some diagrams to the Overview section
Maybe this will be more understandable?
1 parent efb26d5 commit 0d8103b

1 file changed

Lines changed: 86 additions & 13 deletions

File tree

‎draft-davidben-tls-merkle-tree-certs.md‎

Lines changed: 86 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -278,29 +278,100 @@ Signatureless certificate:
278278

279279
# Overview
280280

281-
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.
281+
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.
282282

283-
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.
283+
~~~aasvg
284+
+-- Certificate Authority -----+ +-- Authenticating Party ----+
285+
| | | |
286+
| 2. Validate request <---+----+-- 1. Request certificate |
287+
| | | | |
288+
| | | | |
289+
| V | | |
290+
| | | |
291+
| 3. Add to issuance log | | |
292+
| +---[ CA cosign ] | | |
293+
| / \ ----+----+-> 5. Download certificates |
294+
| / \ | | |
295+
| / \ | | * tbscert |
296+
| +-------+ | | = = = inclusion proof |
297+
| * * * * tbscert entries | | [ CA ] cosignatures |
298+
| | | [ mirror ] |
299+
+------------------------------+ +-----------------------------+
300+
/ | \
301+
/ | \ 4. Submit log to cosigners
302+
V V V for cosignatures
303+
304+
+-- Mirrors, other cosigners --+ +-- Monitors -----------------+
305+
| | | |
306+
| +---[ CA cosign ] +-+ | |
307+
| / \ [ mirror cosign ] | | | |
308+
| / \ | | | |
309+
| / \ <-+-+--+-- 6. Monitor CA operation |
310+
| +-------+ | | | |
311+
| * * * * | | +-----------------------------+
312+
+-+----------------------------+ |
313+
| ...quorum of cosigners... |
314+
+------------------------------+
315+
~~~
316+
{: #fig-issuance-overview title="A diagram of the issuance architecture, detailed below"}
317+
318+
Merkle Tree Certificates are issued as follows. {{fig-issuance-overview}} depicts this process.
319+
320+
1. The authenticating party requests a certificate, e.g. over ACME {{?RFC8555}}
321+
322+
2. The CA validates each incoming issuance request, e.g. with ACME challenges. From there, the process differs.
323+
324+
3. The CA operates an append-only *issuance log* ({{issuance-logs}}). Unlike a CT log, this log only contains entries added by the CA:
284325

285-
2. The CA adds a TBSCertificateLogEntry ({{log-entries}}) to its log, describing the information it is certifying.
326+
1. The CA adds a TBSCertificateLogEntry ({{log-entries}}) to its log, describing the information it is certifying.
286327

287-
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}}).
328+
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}}).
288329

289-
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.
330+
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.
290331

291-
These signatures prove to relying parties that the CA has issued the certificate.
332+
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.
292333

293-
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.
334+
5. The CA now has enough information to construct a certificate and give it to the authenticating party. A certificate contains:
294335

295-
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.
336+
* The TBSCertificate being certified
337+
* An inclusion proof from the TBSCertificate to some subtree
338+
* Cosignatures from the CA and cosigners
339+
340+
6. As in Certificate Transparency, monitors observe the issuance log to ensure the CA is operated correctly.
341+
342+
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.
296343

297-
A *full certificate* contains:
344+
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.
298345

299-
* The TBSCertificate being certified
300-
* An inclusion proof from the TBSCertificate to some subtree
301-
* Sufficient cosignatures to meet the relying party's requirements
346+
~~~aasvg
347+
+-- Certificate Authority -------+
348+
| | +-- Update Channel --+
349+
| /\ | | |
350+
| / \ 1. Allocate landmarks -+--+----------------+ |
351+
| +----+ | | | | |
352+
+--------------------------+-----+ +----------------+---+
353+
| |
354+
2. Make signatureless | 3. Distribute |
355+
cert from landmark | landmarks |
356+
V |
357+
+-- Authenticating Party --------+ |
358+
| | |
359+
| signatureless cert | V
360+
| tbscert | +-- Up-to-date RP -----+
361+
| inclusion proof to landmark -+->| landmark hashes |
362+
| | | trusted cosigners |
363+
| | +----------------------+
364+
| full cert |
365+
| tbscert | +-- Unupdated RP ------+
366+
| inclusion proof | | (stale or no hashes) |
367+
| cosignatures ------------+->| trusted cosigners |
368+
| | +----------------------+
369+
+--------------------------------+
370+
4. Select certificate by RP
371+
~~~
372+
{: #fig-signatureless-overview title="A diagram of signatureless certificates construction and usage, detailed below"}
302373

303-
This same issuance process also produces a *signatureless certificate*. This is an optional optimized certificate that avoids any cosignatures:
374+
Signatureless certificates are constructed and used as follows. {{fig-signatureless-overview}} depicts this process.
304375

305376
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.
306377

@@ -1470,3 +1541,5 @@ In draft-04, there is no fast issuance mode. In draft-05, frequent, non-landmark
14701541
- Rename 'landmarks checkpoint' to 'landmarks'
14711542

14721543
- Clarify and fix an off-by-one error in recommended landmark allocation scheme
1544+
1545+
- Add some diagrams to the Overview section

0 commit comments

Comments
 (0)