You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<pid="section-5-1">This section defines the structure of an <em>issuance log</em>.<ahref="#section-5-1" class="pilcrow">¶</a></p>
2179
2179
<pid="section-5-2">An issuance log describes an append-only sequence of <em>entries</em> (<ahref="#log-entries" class="auto internal xref">Section 5.3</a>), identified consecutively by an index value, starting from zero. Each entry is an assertion that the CA has certified. The entries in the issuance log are represented as a Merkle Tree, described in <span><ahref="https://rfc-editor.org/rfc/rfc9162#section-2.1" class="relref">Section 2.1</a> of [<ahref="#RFC9162" class="cite xref">RFC9162</a>]</span>.<ahref="#section-5-2" class="pilcrow">¶</a></p>
2180
-
<pid="section-5-3">Issuance logs have an interface for the log operator, i.e. the CA, to add entries. Unlike <span>[<ahref="#RFC6962" class="cite xref">RFC6962</a>]</span> and <span>[<ahref="#RFC9162" class="cite xref">RFC9162</a>]</span>, this interface is not publicly accessible. The log only contains entries which the log operator themselves has chosen to add. As entries are added, the Merkle Tree is updated to be computed over the new sequence.<ahref="#section-5-3" class="pilcrow">¶</a></p>
2180
+
<pid="section-5-3">Unlike <span>[<ahref="#RFC6962" class="cite xref">RFC6962</a>]</span> and <span>[<ahref="#RFC9162" class="cite xref">RFC9162</a>]</span>, an issuance log does not have a public submission interface. The log only contains entries which the log operator, i.e. the CA, chose to add. As entries are added, the Merkle Tree is updated to be computed over the new sequence.<ahref="#section-5-3" class="pilcrow">¶</a></p>
2181
2181
<pid="section-5-4">A snapshot of the log is known as a <em>checkpoint</em>. A checkpoint is identified by its <em>tree size</em>, that is the number of elements comitted to the log at the time. Its contents can be described by the Merkle Tree Hash (<span><ahref="https://rfc-editor.org/rfc/rfc9162#section-2.1.1" class="relref">Section 2.1.1</a> of [<ahref="#RFC9162" class="cite xref">RFC9162</a>]</span>) of entries zero through <code>tree_size - 1</code>.<ahref="#section-5-4" class="pilcrow">¶</a></p>
2182
2182
<pid="section-5-5">Cosigners (<ahref="#cosigners" class="auto internal xref">Section 5.4</a>) sign assertions about the state of the issuance log. A Merkle Tree CA operates a combination of an issuance log and one or more CA cosigners (<ahref="#certification-authority-cosigners" class="auto internal xref">Section 5.5</a>) that authenticate the log state and certifies the contents. External cosigners may also be deployed to assert correct log operation or provide other services to relying parties (<ahref="#trusted-cosigners" class="auto internal xref">Section 7.3</a>).<ahref="#section-5-5" class="pilcrow">¶</a></p>
<pid="section-5.4-1">This section defines a log <em>cosigner</em>. A cosigner is a class of role that follows some append-only view of the log and signs subtrees (<ahref="#subtrees" class="auto internal xref">Section 4</a>) consistent with that view. The signatures generated by a cosigner are known as <em>cosignatures</em>. The cosigner is responsible for ensuring that all subtrees it signs are consistent with each other. The cosigner may be external to the log, in which case it might ensure consistency by checking consistency proofs as it updates its internal state. The cosigner may be operated together with the log, in which case it can trust its log state.<ahref="#section-5.4-1" class="pilcrow">¶</a></p>
2277
-
<pid="section-5.4-2">Different cosigners may perform different roles. When a cosigner signs a subtree, it can additionally make cosigner-specific assertions about the log state described by the subtree. This document defines one concrete cosigner role, a CA cosigner (<ahref="#certification-authority-cosigners" class="auto internal xref">Section 5.5</a>), to authenticate the log and certify entries. Other documents and specific deployments may define other cosigner roles, to perform different functions in a PKI. For example, <span>[<ahref="#TLOG-WITNESS" class="cite xref">TLOG-WITNESS</a>]</span> defines a cosigner that only checks the log is append-only, and <span>[<ahref="#TLOG-MIRROR" class="cite xref">TLOG-MIRROR</a>]</span> defines a cosigner that mirrors a log.<ahref="#section-5.4-2" class="pilcrow">¶</a></p>
2278
-
<pid="section-5.4-3">Each cosigner has a public key and a <em>cosigner ID</em>, which uniquely identifies the cosigner. The cosigner ID is a trust anchor ID <span>[<ahref="#I-D.ietf-tls-trust-anchor-ids" class="cite xref">I-D.ietf-tls-trust-anchor-ids</a>]</span>. By identifying the cosigner, the cosigner ID specifies both the public key and the role-specific assertions made by the cosigner's signatures. If a single operator performs multiple cosigner roles in an ecosystem, each role MUST use a distinct cosigner ID and SHOULD use a distinct key.<ahref="#section-5.4-3" class="pilcrow">¶</a></p>
2279
-
<pid="section-5.4-4">A single cosigner, with a single cosigner name and public key, MAY generate cosignatures for multiple logs. In this case, signed subtrees only need to be consistent with others for the same log.<ahref="#section-5.4-4" class="pilcrow">¶</a></p>
2276
+
<pid="section-5.4-1">This section defines a log <em>cosigner</em>. A cosigner follows some append-only view of the log and signs subtrees (<ahref="#subtrees" class="auto internal xref">Section 4</a>) consistent with that view. The signatures generated by a cosigner are known as <em>cosignatures</em>. All subtrees signed by a cosigner MUST be consistent with each other. The cosigner may be external to the log, in which case it might ensure consistency by checking consistency proofs. The cosigner may be operated together with the log, in which case it can trust its log state.<ahref="#section-5.4-1" class="pilcrow">¶</a></p>
2277
+
<pid="section-5.4-2">A cosignature MAY implicitly make additional statements about a subtree, determined by the cosigner's role. This document defines one concrete cosigner role, a CA cosigner (<ahref="#certification-authority-cosigners" class="auto internal xref">Section 5.5</a>), to authenticate the log and certify entries. Other documents and specific deployments may define other cosigner roles, to perform different functions in a PKI. For example, <span>[<ahref="#TLOG-WITNESS" class="cite xref">TLOG-WITNESS</a>]</span> defines a cosigner that only checks the log is append-only, and <span>[<ahref="#TLOG-MIRROR" class="cite xref">TLOG-MIRROR</a>]</span> defines a cosigner that mirrors a log.<ahref="#section-5.4-2" class="pilcrow">¶</a></p>
2278
+
<pid="section-5.4-3">Each cosigner has a public key and a <em>cosigner ID</em>, which uniquely identifies the cosigner. The cosigner ID is a trust anchor ID <span>[<ahref="#I-D.ietf-tls-trust-anchor-ids" class="cite xref">I-D.ietf-tls-trust-anchor-ids</a>]</span>. By identifying the cosigner, the cosigner ID specifies both the public key and the additional statements made by the cosigner's signatures. If a single operator performs multiple cosigner roles in an ecosystem, each role MUST use a distinct cosigner ID and SHOULD use a distinct key.<ahref="#section-5.4-3" class="pilcrow">¶</a></p>
2279
+
<pid="section-5.4-4">A single cosigner, with a single cosigner ID and public key, MAY generate cosignatures for multiple logs. In this case, signed subtrees only need to be consistent with others for the same log.<ahref="#section-5.4-4" class="pilcrow">¶</a></p>
<pid="section-5.4.1-3"><code>log_id</code> MUST be the issuance log's ID (<ahref="#log-ids" class="auto internal xref">Section 5.2</a>), in its binary representation (<span><ahref="https://datatracker.ietf.org/doc/html/draft-ietf-tls-trust-anchor-ids-01#section-3" class="relref">Section 3</a> of [<ahref="#I-D.ietf-tls-trust-anchor-ids" class="cite xref">I-D.ietf-tls-trust-anchor-ids</a>]</span>). <code>start</code> and <code>end</code> MUST define a valid subtree of the log, and <code>hash</code> MUST be the subtree's hash value in the cosigner's view of the log. The <code>label</code> is a fixed prefix for domain separation. Its value MUST be the string <code>mtc-subtree/v1</code>, followed by a newline (U+000A), followed by a zero byte (U+0000). <code>cosigner_id</code> MUST be the cosigner ID, in its binary representation.<ahref="#section-5.4.1-3" class="pilcrow">¶</a></p>
2308
2308
<pid="section-5.4.1-4">The resulting signature is known as a <em>subtree signature</em>. When <code>start</code> is zero, the resulting signature describes the checkpoint with tree size <code>end</code> and is also known as a <em>checkpoint signature</em>.<ahref="#section-5.4.1-4" class="pilcrow">¶</a></p>
2309
2309
<pid="section-5.4.1-5">For each supported log, a cosigner retains its checkpoint signature with the largest <code>end</code>. This is known as the cosigner's <em>current</em> checkpoint. If the cosigner's current checkpoint has tree size <code>tree_size</code>, it MUST NOT generate a signature for a subtree <code>[start, end)</code> if <code>start > 0</code> and <code>end > tree_size</code>. That is, a cosigner can only sign a non-checkpoint subtree if it is contained in its current checkpoint. In a correctly-operated cosigner, every signature made by the cosigner can be proven consistent with its current checkpoint with a subtree consistency proof (<ahref="#subtree-consistency-proofs" class="auto internal xref">Section 4.3</a>). As a consequence, a cosigner that signs a subtree is held responsible for all the entries in the tree of size matching the subtree end, even if the corresponding checkpoint is erroneously unavailable.<ahref="#section-5.4.1-5" class="pilcrow">¶</a></p>
2310
-
<pid="section-5.4.1-6">Before signing a subtree, the cosigner MUST ensure that <code>hash</code> is consistent with its log state. Different cosigner roles may obtain this assurance differently. For example, a cosigner may compute the hash from its saved log state (e.g. if it is the log operator or maintains a copy of the log) or by verifying a subtree consistency proof (<ahref="#subtree-consistency-proofs" class="auto internal xref">Section 4.3</a>) from its current checkpoint. When a cosigner signs a subtree, it is held responsible <em>both</em> for the subtree being consistent with its other signatures, <em>and</em> for any cosigner-specific assertions made on the subtree being signed.<ahref="#section-5.4.1-6" class="pilcrow">¶</a></p>
2310
+
<pid="section-5.4.1-6">Before signing a subtree, the cosigner MUST ensure that <code>hash</code> is consistent with its log state. Different cosigner roles may obtain this assurance differently. For example, a cosigner may compute the hash from its saved log state (e.g. if it is the log operator or maintains a copy of the log) or by verifying a subtree consistency proof (<ahref="#subtree-consistency-proofs" class="auto internal xref">Section 4.3</a>) from its current checkpoint. When a cosigner signs a subtree, it is held responsible <em>both</em> for the subtree being consistent with its other signatures, <em>and</em> for the cosigner-specific additional statements.<ahref="#section-5.4.1-6" class="pilcrow">¶</a></p>
2311
2311
<pid="section-5.4.1-7">Cosigners SHOULD publish their current checkpoint, along with the checkpoint signature.<ahref="#section-5.4.1-7" class="pilcrow">¶</a></p>
2312
2312
<pid="section-5.4.1-8">[[TODO: CT and tlog put timestamps in checkpoint signatures. Do we want them here? In CT and tlog, the timestamps are monotonically increasing as the log progresses, but we also sign subtrees. We can separate subtree and checkpoint signatures, with timestamps only in the latter, but it's unclear if there is any benefit to this.]]<ahref="#section-5.4.1-8" class="pilcrow">¶</a></p>
<pid="section-5.5-1">A <em>CA cosigner</em> is a cosigner (<ahref="#cosigners" class="auto internal xref">Section 5.4</a>) that certifies the contents of a log.<ahref="#section-5.5-1" class="pilcrow">¶</a></p>
2352
-
<pid="section-5.5-2">When a CA cosigner signs a subtree, it provides the additional guarantee that it has certified the contents of each entry in the subtree. For example, a domain-validating CA would be held responsible for having performed domain validation for all such entries, at some time consistent with the validity datesin each entry.<ahref="#section-5.5-2" class="pilcrow">¶</a></p>
2353
-
<pid="section-5.5-3">Entries are extensible, so each entry type determines the semantics of what the CA is certifying:<ahref="#section-5.5-3" class="pilcrow">¶</a></p>
2352
+
<pid="section-5.5-2">When a CA cosigner signs a subtree, it makes the additional statement that it has certified each entry in the subtree. For example, a domain-validating CA states that it has performed domain validation for each entry, at some time consistent with the entry's validity dates. CAs are held responsible for every entry in every subtree they sign. Proving an entry is included (<ahref="#subtree-inclusion-proofs" class="auto internal xref">Section 4.2</a>) in a CA-signed subtree is sufficient to prove the CA certified it.<ahref="#section-5.5-2" class="pilcrow">¶</a></p>
2353
+
<pid="section-5.5-3">What it means to certify an entry depends on the entry type:<ahref="#section-5.5-3" class="pilcrow">¶</a></p>
2354
2354
<ulclass="normal">
2355
2355
<liclass="normal" id="section-5.5-4.1">
2356
2356
<pid="section-5.5-4.1.1">To certify an entry of type <code>null_entry</code> is a no-op. A CA MAY freely certify <code>null_entry</code> without being held responsible for any validation.<ahref="#section-5.5-4.1.1" class="pilcrow">¶</a></p>
<pid="section-5.5-4.2.1">To certify an entry of type <code>tbs_cert_entry</code> is to certify the TBSCertificateLogEntry, as defined in <ahref="#log-entries" class="auto internal xref">Section 5.3</a>.<ahref="#section-5.5-4.2.1" class="pilcrow">¶</a></p>
2360
2360
</li>
2361
2361
</ul>
2362
-
<pid="section-5.5-5">Future documents MAY define <code>type</code> values and what it means to certify them. A CA MUST NOT sign a subtree if it contains an entry with <code>type</code> that it does not recognize. Doing so would certify that the CA has validated the information in some not-yet-defined entry format. <ahref="#new-log-entry-types" class="auto internal xref">Section 12.5</a> further discusses security implications of new formats.<ahref="#section-5.5-5" class="pilcrow">¶</a></p>
2363
-
<pid="section-5.5-6">A CA operator MAY operate multiple CA cosigners that all certify the same log in parallel. This may be useful when, e.g., rotating CA keys. In this case, each CA instance MUST have a distinct name. The CA operator's ACME server can return all CA cosignatures together in a single certificate, with TLS negotiation sending the right ones to each client.<ahref="#section-5.5-6" class="pilcrow">¶</a></p>
2362
+
<pid="section-5.5-5">Entries are extensible. Future documents MAY define <code>type</code> values and what it means to certify them. A CA MUST NOT sign a subtree if it contains an entry with <code>type</code> that it does not recognize. Doing so would certify that the CA has validated the information in some not-yet-defined entry format. <ahref="#new-log-entry-types" class="auto internal xref">Section 12.5</a> further discusses security implications of new formats.<ahref="#section-5.5-5" class="pilcrow">¶</a></p>
2363
+
<pid="section-5.5-6">A CA operator MAY operate multiple CA cosigners that all certify the same log in parallel. This may be useful when, e.g., rotating CA keys. In this case, each CA instance MUST have a distinct name. The CA operator's ACME server can return all CA cosignatures together in a single certificate, with the application protocol selecting the cosignatures to use. <ahref="#use-in-tls" class="auto internal xref">Section 8</a> describes how this is done in TLS <span>[<ahref="#RFC8446" class="cite xref">RFC8446</a>]</span>.<ahref="#section-5.5-6" class="pilcrow">¶</a></p>
2364
2364
<pid="section-5.5-7">If the CA operator additionally operates a traditional X.509 CA, that CA key MUST be distinct from any Merkle Tree CA cosigner keys.<ahref="#section-5.5-7" class="pilcrow">¶</a></p>
0 commit comments