From 737e718433013c48ccb1a5f09a56bc30b7e8d8e1 Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Mon, 20 Jul 2026 15:30:22 -0500 Subject: [PATCH 1/5] Some attempt to adjust wording --- draft-ietf-plants-merkle-tree-certs.md | 38 ++++++++++++++------------ 1 file changed, 20 insertions(+), 18 deletions(-) diff --git a/draft-ietf-plants-merkle-tree-certs.md b/draft-ietf-plants-merkle-tree-certs.md index 4c2b2d3..38c1a43 100644 --- a/draft-ietf-plants-merkle-tree-certs.md +++ b/draft-ietf-plants-merkle-tree-certs.md @@ -430,7 +430,7 @@ Not all intervals can form subtrees. Subtrees are limited to intervals that can {{subtree-test-vectors}} provides test vectors for the algorithms defined in this section. -## Definition of a Subtree +## Definition of a Subtree {#sec-subtree} Given an ordered list of `n` inputs, `D_n = {d[0], d[1], ..., d[n-1]}`, {{Section 2.1.1 of !RFC9162}} defines the Merkle Tree via the Merkle Tree Hash `MTH(D_n)`. @@ -1037,15 +1037,15 @@ The fields of a TBSCertificateLogEntry are defined as follows: Note the subject's public key algorithm is incorporated into both `subjectPublicKeyAlgorithm` and `subjectPublicKeyInfoHash`. -MTCLogEntry is an extensible structure. Future documents may define new values for MTCLogEntryType or MTCLogEntryExtensionType, with corresponding semantics. See {{certification-authority-cosigners}} and {{extensibility}} for additional discussion. +MTCLogEntry is an extensible structure. Future documents MAY define new values for MTCLogEntryType or MTCLogEntryExtensionType, with corresponding semantics. See {{certification-authority-cosigners}} and {{extensibility}} for additional discussion. -An MTCLogEntry's size SHOULD NOT exceed 65535 (216-1) bytes. Doing so may exceed size limits in common log-serving protocols, such as {{TLOG-TILES}}. TBSCertificateLogEntry does not include signatures and hashes public keys, so post-quantum algorithms do not contribute to this size. +An MTCLogEntry's size SHOULD NOT exceed 65535 (216-1) bytes. Doing so might exceed size limits in common log-serving protocols, such as {{TLOG-TILES}}, so implementer SHOULD be caution about any limits imposed by the protocls and log providers that they intend to use. TBSCertificateLogEntry does not include signatures and hashes public keys, so post-quantum algorithms do not contribute to this size. ### Publishing Logs This protocol aims to enable monitors to detect misissued certificates by observing the issuance log. See {{transparency}}. -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}}. +This document does not prescribe a particular method of observing the issuance log. The access protocols do not affect certificate interoperability, and different applications could 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 which could, for example, require an authentication mechanism. 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}}. @@ -1053,7 +1053,7 @@ For example, a log ecosystem could use {{TLOG-TILES}} to serve logs. {{TLOG-TILE Over time, an issuance log's entries will expire and likely be replaced as certificates are renewed. As this happens, the total size of the log grows, even if the unexpired subset remains fixed. To mitigate this, issuance logs MAY be *pruned*, as described in this section. -Pruning makes some prefix of the log unavailable, without changing the tree structure. It may be used to reduce the serving cost of long-lived logs, where any entries have long expired. {{log-availability}} discusses policies on when pruning may be permitted. This section discusses how it is done and the impact on log structure. +Pruning makes some prefix of the log unavailable, without changing the tree structure. It is a technique to reduce the serving cost of long-lived logs, by dropping entries that have long expired. {{log-availability}} discusses policies on when pruning MAY be performed. This section discusses how it is done and the impact on log structure. An issuance log is pruned by updating its *minimum index* parameter ({{issuance-logs}}). The minimum index is the index of the first log entry that the log publishes. (See {{publishing-logs}}.) It MUST be less than or equal to the tree size of the log's current checkpoint, and also satisfy any availability policies set by relying parties who trust the CA. @@ -1124,7 +1124,7 @@ Logs MAY retain additional nodes, or expect log clients to compute required node This section defines a log *cosigner*. A cosigner follows some append-only view of the log and signs subtrees ({{subtrees}}) consistent with that view. The signatures generated by a cosigner are known as *cosignatures*. 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. -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 ({{certification-authority-cosigners}}), 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, {{TLOG-WITNESS}} defines a cosigner that only checks the log is append-only, and {{TLOG-MIRROR}} defines a cosigner that mirrors a log. +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 ({{certification-authority-cosigners}}), 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, {{TLOG-WITNESS}} defines a cosigner that only checks the log is append-only, and {{TLOG-MIRROR}} defines a cosigner that mirrors a log. Each cosigner has a public key and a *cosigner ID*, which uniquely identifies the cosigner. The cosigner ID is a trust anchor ID {{!I-D.ietf-tls-trust-anchor-ids}}. By identifying the cosigner, the cosigner ID specifies the public key, signature algorithm, and any 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. @@ -1166,28 +1166,30 @@ This is equivalent to the concatenation of: For example, the trust anchor ID 32473.1 would be encoded as the ASCII string `oid/1.3.6.1.4.1.32473.1`. -`start` and `end` MUST define a valid subtree of the log, and `subtree_hash` MUST be the subtree's hash value in the cosigner's view of the log. +`start` and `end` MUST define a valid subtree of the log {{sec-subtree}}, and `subtree_hash` MUST be the subtree's hash value {{sec-subtree}} in the cosigner's view of the log. If `timestamp` is non-zero, it MUST be the time that the signature was produced. This time is represented as seconds since the Epoch, as defined in Section 4.19 of Volume 1 of {{!POSIX=DOI.10.1109/IEEESTD.2024.10555529}}. Additionally, if `timestamp` is non-zero, the following MUST be true: * `start` MUST be zero. * `end` MUST be the size of the largest consistent tree that the cosigner has observed for the log. -`timestamp` MAY be zero, in which case no additional constraints are placed on `start` or `end`, and no statement is made about the signing time or largest observed tree. +`timestamp` MAY be zero, in which case no additional constraints are placed on `start` or `end` (beyond being a valid subtree), and no statement is made about the signing time or largest observed tree. ### Signature Semantics -Before signing a subtree of some log, the cosigner MUST ensure that `subtree_hash` is consistent with its view of the log. Different cosigner roles may obtain this assurance differently. For example: +Before signing a subtree of some log, the cosigner MUST ensure that `subtree_hash` is consistent with its view of the log. Different cosigner roles will obtain this assurance differently. For example: -* A cosigner may maintain a full copy of the log, e.g. if it's the log operator. The cosigner can then compute `subtree_hash` from this copy. +* A cosigner MAY maintain a full copy of the log, e.g. if it's the log operator. The cosigner can then compute `subtree_hash` from this copy. -* A cosigner may maintain the hash of the largest consistent tree observed by the log. The cosigner can then check `subtree_hash` with a subtree consistency proof ({{subtree-consistency-proofs}}). +* A cosigner MAY maintain the hash of the largest consistent tree observed by the log. The cosigner can then check `subtree_hash` with a subtree consistency proof ({{subtree-consistency-proofs}}). -In both cases, the cosigner MUST ensure that, as it updates its view of the log, the old and new views are consistent. For example, {{TLOG-WITNESS}} defines a cosigner that checks consistency proofs ({{Section 2.1.4 of !RFC9162}}) between the two views. +* A cosigner MAY maintain any other representation of the log which allows it to verify the consistency of the log. + +In all cases, the cosigner MUST ensure that, as it updates its view of the log, the old and new views are consistent. When a cosigner signs a subtree, it is held separately responsible *both* for the subtree being consistent with its other signatures, *and* for the cosigner-specific additional statements. That is, if a cosigner signs an inconsistent subtree, it is held responsible for its additional statements on all entries in the inconsistent subtree, even if some other signed subtree exists that asserts different entries. -Subtree signatures can be used to sign timestamped log checkpoints with a non-zero `timestamp`. A signature with a non-zero `timestamp` asserts the complete state of the cosigner's view of the log at a given time. These signatures are not directly used in Merkle Tree Certificates ({{certificate-format}}), but cosigners MAY generate them, subject to the rules above, as part of other functions in a PKI. This may include log serving or integrating an issuance log into a transparency ecosystem. For example, {{TLOG-TILES}} and {{TLOG-WITNESS}} use such signatures. +Subtree signatures can be used to sign timestamped log checkpoints by using a non-zero `timestamp`. A signature with a non-zero `timestamp` asserts the complete state of the cosigner's view of the log at a given time. These signatures are not directly used in Merkle Tree Certificates ({{certificate-format}}), but cosigners MAY generate them, subject to the rules above, as part of other functions in a PKI, such as log serving or integrating an issuance log into a transparency ecosystem. For example, {{TLOG-TILES}} and {{TLOG-WITNESS}} use such signatures. ### Signature Algorithms @@ -1208,7 +1210,7 @@ What it means to certify an entry depends on the entry type: * To certify an entry of type `null_entry` is a no-op. A CA MAY freely certify `null_entry` without being held responsible for any validation. * To certify an entry of type `tbs_cert_entry` is to certify the TBSCertificateLogEntry, as defined in {{log-entries}}. -Entries are extensible. Future documents MAY define `type` and `extension_type` values and what it means to certify them. A CA MUST NOT sign a subtree if it contains an entry with `type` or `extension_type` that it does not recognize. Doing so would certify that the CA has validated the information in some not-yet-defined format. {{extensibility}} further discusses security implications of such extensions. +Entries are extensible. Future documents MAY define `type` and `extension_type` values and the semantics of the data that they contain. A CA MUST NOT sign a subtree if it contains an entry with `type` or `extension_type` that it does not recognize. Doing so would certify that the CA has validated the information in some not-yet-defined format. {{extensibility}} further discusses security implications of such extensions. If the CA issues certificate revocation lists (CRLs) {{!RFC5280}} or Online Certificate Status Protocol (OCSP) responses {{!RFC6960}}, the CA's cosigner key MAY be used to directly sign TBSCertList or OCSP ResponseData structures, respectively, but only for this CA instance. Such uses remain subject to other X.509 constraints, such as the key usage extension, which are out of scope for this document. See {{signature-domain-separation}} for a discussion of domain separation. @@ -1273,7 +1275,7 @@ If this extension is present, the key described in `subjectPublicKeyInfo` is a C This extension indicates the subtree signature format defined in {{signature-format}}. If a later version of the protocol defines a new format, this SHOULD be represented in CA certificates with a new extension type. -A CA certificate using this format SHOULD NOT be self-signed by the Merkle Tree Certificate CA. Doing so would require writing the information in the issuance log. Instead, if used to represent a trust anchor, the certificate should be an unsigned certificate {{!RFC9925}}. +A CA certificate using this format SHOULD NOT be self-signed by the Merkle Tree Certificate CA. Doing so would require writing the information in the issuance log. Instead, if used to represent a trust anchor, the certificate SHOULD be an unsigned certificate {{!RFC9925}}. # Certificates @@ -1288,7 +1290,7 @@ A Merkle Tree Certificate is constructed from the following inputs: * A subtree ({{subtrees}}) that contains the log entry * Zero or more signatures ({{cosigners}}) over the subtree, which together satisfy relying party requirements ({{trusted-cosigners}}) -For any given TBSCertificateLogEntry, there are multiple possible certificates that may prove the entry is certified by the CA and publicly logged, varying by choice of subtree and signatures. {{certificate-format}} defines how the certificate is constructed based on those choices. {{standalone-certificates}} and {{landmark-relative-certificates}} define two profiles of Merkle Tree Certificates, standalone certificates and landmark-relative certificates, and how to select the subtree and signatures for them. +For any given TBSCertificateLogEntry, there are multiple possible certificates that may prove the entry is certified and publicly logged by the the issuing CA indicated in its TBSCertificateLogEntry, varying by choice of subtree and signatures. {{certificate-format}} defines how the certificate is constructed based on those choices. {{standalone-certificates}} and {{landmark-relative-certificates}} define two profiles of Merkle Tree Certificates, standalone certificates and landmark-relative certificates, and how to select the subtree and signatures for them. ## Certificate Format @@ -1370,7 +1372,7 @@ A *landmark-relative certificate* is a Merkle Tree certificate which contains no ### Landmark Tree Sizes -To issue landmark-relative certificates, a CA must additionally maintain a *landmark sequence*, which is a sequence of *landmarks*. +To issue landmark-relative certificates, a CA MUST additionally maintain a *landmark sequence*, which is a sequence of *landmarks*. Each landmark specifies a tree size, used as a common point of reference across the ecosystem for optimizing certificates. Landmarks are numbered consecutively from zero. The first landmark, numbered zero, MUST have a tree size of zero. The sequence of tree sizes MUST be append-only and strictly monotonically increasing. @@ -2337,7 +2339,7 @@ They are hash values of the outputs of all possible inputs for each algorithm, f For all the test vectors, a tree `D_n` of size `n` is constructed with leaf values `d[0] = 0x00, d[1] = 0x01, ...`. The hash function used is SHA-256. The hash values are encoded in hexadecimal. -## Subtree Hashes +## Subtree Hashes {#subtree-hashes} For each value of `end` from 1 to 130, and each value of `start` from 0 to `end - 1`, if `[start, end)` is a valid subtree, add to the rolling hash the ASCII string `[START, END) HASH` followed by a newline (U+000A), where `START` and `END` are the decimal representations of `start` and `end`, respectively, and `HASH` is the hexadecimal encoding of `MTH(D[start:end])`, according to {{subtrees}}. From 74ce9c4f9f1d8611b77f060f9ac5550836235bc3 Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Tue, 21 Jul 2026 08:27:07 -0500 Subject: [PATCH 2/5] Update draft-ietf-plants-merkle-tree-certs.md Co-authored-by: David Benjamin --- draft-ietf-plants-merkle-tree-certs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-plants-merkle-tree-certs.md b/draft-ietf-plants-merkle-tree-certs.md index d7e8c0f..cb7879e 100644 --- a/draft-ietf-plants-merkle-tree-certs.md +++ b/draft-ietf-plants-merkle-tree-certs.md @@ -1302,7 +1302,7 @@ A Merkle Tree Certificate is constructed from the following inputs: * The `log_number` and the zero-based entry `index` of that log entry within the issuance log, used to construct the certificate's `serialNumber` ({{certificate-format}}). * An `MTCProof` ({{certificate-format}}) proving the entry's inclusion in a subtree, along with zero or more signatures ({{cosigners}}) over that subtree, which together satisfy relying party requirements ({{trusted-cosigners}}) -For any given TBSCertificateLogEntry, there are multiple possible certificates that may prove the entry is certified and publicly logged by the the issuing CA indicated in its TBSCertificateLogEntry, varying by choice of subtree and signatures. {{certificate-format}} defines how the certificate is constructed based on those choices. {{standalone-certificates}} and {{landmark-relative-certificates}} define two profiles of Merkle Tree Certificates, standalone certificates and landmark-relative certificates, and how to select the subtree and signatures for them. +By varying the choice of subtree and signatures, there can be multiple ways to prove the entry is in the log, and thus certified by the CA. {{certificate-format}} defines how a certificate is constructed based on those choices. {{standalone-certificates}} and {{landmark-relative-certificates}} define two profiles of Merkle Tree Certificates, standalone certificates and landmark-relative certificates, and how to select the subtree and signatures for them. ## Certificate Format From 1406ee103b2b6e10d03a3be18d7f21f5375ff0ba Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Tue, 21 Jul 2026 08:27:43 -0500 Subject: [PATCH 3/5] Update draft-ietf-plants-merkle-tree-certs.md Co-authored-by: David Benjamin --- draft-ietf-plants-merkle-tree-certs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-plants-merkle-tree-certs.md b/draft-ietf-plants-merkle-tree-certs.md index cb7879e..d3c2fc0 100644 --- a/draft-ietf-plants-merkle-tree-certs.md +++ b/draft-ietf-plants-merkle-tree-certs.md @@ -1384,7 +1384,7 @@ A *landmark-relative certificate* is a Merkle Tree certificate which contains no ### Landmark Tree Sizes -To issue landmark-relative certificates, a CA MUST additionally maintain a *landmark sequence*, which is a sequence of *landmarks*. +A CA that issues landmark-relative certificates MUST additionally maintain a *landmark sequence*. A landmark sequence is a sequence of *landmarks*, defined below: Each landmark specifies a tree size, used as a common point of reference across the ecosystem for optimizing certificates. Landmarks are numbered consecutively from zero. The first landmark, numbered zero, MUST have a tree size of zero. The sequence of tree sizes MUST be append-only and strictly monotonically increasing. From da1b60d236520d4f1311245763c9e05d6c1fbe08 Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Tue, 21 Jul 2026 08:28:54 -0500 Subject: [PATCH 4/5] davidben comments addressed (hopefully) --- draft-ietf-plants-merkle-tree-certs.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-ietf-plants-merkle-tree-certs.md b/draft-ietf-plants-merkle-tree-certs.md index 38c1a43..5373016 100644 --- a/draft-ietf-plants-merkle-tree-certs.md +++ b/draft-ietf-plants-merkle-tree-certs.md @@ -430,7 +430,7 @@ Not all intervals can form subtrees. Subtrees are limited to intervals that can {{subtree-test-vectors}} provides test vectors for the algorithms defined in this section. -## Definition of a Subtree {#sec-subtree} +## Definition of a Subtree Given an ordered list of `n` inputs, `D_n = {d[0], d[1], ..., d[n-1]}`, {{Section 2.1.1 of !RFC9162}} defines the Merkle Tree via the Merkle Tree Hash `MTH(D_n)`. @@ -1039,13 +1039,13 @@ Note the subject's public key algorithm is incorporated into both `subjectPublic MTCLogEntry is an extensible structure. Future documents MAY define new values for MTCLogEntryType or MTCLogEntryExtensionType, with corresponding semantics. See {{certification-authority-cosigners}} and {{extensibility}} for additional discussion. -An MTCLogEntry's size SHOULD NOT exceed 65535 (216-1) bytes. Doing so might exceed size limits in common log-serving protocols, such as {{TLOG-TILES}}, so implementer SHOULD be caution about any limits imposed by the protocls and log providers that they intend to use. TBSCertificateLogEntry does not include signatures and hashes public keys, so post-quantum algorithms do not contribute to this size. +An MTCLogEntry's size SHOULD NOT exceed 65535 (216-1) bytes. Implementers SHOULD CONSIDER that log-serving protocols, or the underlying transport mechanisms they use, could have lower limits. TBSCertificateLogEntry does not include signatures and hashes public keys, so post-quantum algorithms do not contribute to this size. ### Publishing Logs This protocol aims to enable monitors to detect misissued certificates by observing the issuance log. See {{transparency}}. -This document does not prescribe a particular method of observing the issuance log. The access protocols do not affect certificate interoperability, and different applications could 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 which could, for example, require an authentication mechanism. 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}}. +This document does not prescribe a particular method of observing the issuance log. The access protocols do not affect certificate interoperability, and different applications could 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}}. @@ -1166,7 +1166,7 @@ This is equivalent to the concatenation of: For example, the trust anchor ID 32473.1 would be encoded as the ASCII string `oid/1.3.6.1.4.1.32473.1`. -`start` and `end` MUST define a valid subtree of the log {{sec-subtree}}, and `subtree_hash` MUST be the subtree's hash value {{sec-subtree}} in the cosigner's view of the log. +`start` and `end` MUST define a valid subtree of the log, and `subtree_hash` MUST be the subtree's hash value in the cosigner's view of the log. See {{definition-of-a-subtree}}. If `timestamp` is non-zero, it MUST be the time that the signature was produced. This time is represented as seconds since the Epoch, as defined in Section 4.19 of Volume 1 of {{!POSIX=DOI.10.1109/IEEESTD.2024.10555529}}. Additionally, if `timestamp` is non-zero, the following MUST be true: @@ -2339,7 +2339,7 @@ They are hash values of the outputs of all possible inputs for each algorithm, f For all the test vectors, a tree `D_n` of size `n` is constructed with leaf values `d[0] = 0x00, d[1] = 0x01, ...`. The hash function used is SHA-256. The hash values are encoded in hexadecimal. -## Subtree Hashes {#subtree-hashes} +## Subtree Hashes For each value of `end` from 1 to 130, and each value of `start` from 0 to `end - 1`, if `[start, end)` is a valid subtree, add to the rolling hash the ASCII string `[START, END) HASH` followed by a newline (U+000A), where `START` and `END` are the decimal representations of `start` and `end`, respectively, and `HASH` is the hexadecimal encoding of `MTH(D[start:end])`, according to {{subtrees}}. From 294f24c9985357ce920cfdbaf1d0af7531650005 Mon Sep 17 00:00:00 2001 From: David Benjamin Date: Mon, 27 Jul 2026 13:27:04 -0400 Subject: [PATCH 5/5] Update draft-ietf-plants-merkle-tree-certs.md --- draft-ietf-plants-merkle-tree-certs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-plants-merkle-tree-certs.md b/draft-ietf-plants-merkle-tree-certs.md index 67645ad..aa836c5 100644 --- a/draft-ietf-plants-merkle-tree-certs.md +++ b/draft-ietf-plants-merkle-tree-certs.md @@ -1054,7 +1054,7 @@ Note the subject's public key algorithm is incorporated into both `subjectPublic MTCLogEntry is an extensible structure. Future documents MAY define new values for MTCLogEntryType or MTCLogEntryExtensionType, with corresponding semantics. See {{certification-authority-cosigners}} and {{extensibility}} for additional discussion. -An MTCLogEntry's size SHOULD NOT exceed 65535 (216-1) bytes. Implementers SHOULD CONSIDER that log-serving protocols, or the underlying transport mechanisms they use, could have lower limits. TBSCertificateLogEntry does not include signatures and hashes public keys, so post-quantum algorithms do not contribute to this size. +An MTCLogEntry's size MUST NOT exceed 65535 (216-1) bytes. TBSCertificateLogEntry does not include signatures and hashes public keys, so post-quantum algorithms do not contribute to this size. ### Publishing Logs