• Hash and signature algorithm agility: Permitted algorithms are now specified in IANA registries.
• Precertificate format: Precertificates are now CMS objects rather than X.509 certificates, which avoids violating the certificate serial number uniqueness requirement in Section 4.1.2.2 of RFC 5280.
• Removal of precertificate signing certificates and the precertificate poison extension: The change of precertificate format means that these are no longer needed.
• Logs IDs: Each log is now identified by an OID rather than by the hash of its public key. OID allocations are available from an IANA registry.
• TransItem structure: This new data structure is used to encapsulate most types of CT data. A TransItemList, consisting of one or more TransItem structures, can be used anywhere that SignedCertificateTimestampList was used in [RFC 6962].
• Merkle Tree leaves: The MerkleTreeLeaf structure has been replaced by the TransItem structure, which eases extensibility and simplifies the leaf structure by removing one layer of abstraction.
• Unified leaf format: The structure for both certificate and precertificate entries now includes only the TBSCertificate (whereas certificate entries in [RFC 6962] included the entire certificate).
• Log artifact extensions: These are now typed and managed by an IANA registry, and they can now appear not only in Signed Certificate Timestamps (SCTs) but also in Signed Tree Heads (STHs).
• API outputs: Complete TransItem structures are returned rather than the constituent parts of each structure.
• get-all-by-hash: This is a new client API for obtaining an inclusion proof and the corresponding consistency proof at the same time.
• submit-entry: This is a new client API, replacing add-chain and add-pre-chain.
• Presenting SCTs with proofs: TLS servers may present SCTs together with the corresponding inclusion proofs, using any of the mechanisms that [RFC 6962] defined for presenting SCTs only. (Presenting SCTs only is still supported).
• CT TLS extension: The signed_certificate_timestamp TLS extension has been replaced by the transparency_info TLS extension.
• Verification algorithms: Detailed algorithms for verifying inclusion proofs, for verifying consistency between two STHs, and for verifying a root hash given a complete list of the relevant leaf input entries have been added.
• Extensive clarifications and editorial work.

MTH({}) = HASH().

MTH({d[0]}) = HASH(0x00 || d[0]).

MTH(D_n) = HASH(0x01 || MTH(D[0:k]) || MTH(D[k:n])),

• || denotes concatenation
• : denotes concatenation of lists
• D[k1:k2] = D'_(k2-k1) denotes the list {d'[0] = d[k1], d'[1] = d[k1+1], ..., d'[k2-k1-1] = d[k2-1]} of length (k2 - k1).

1. Set stack to an empty stack.
2. For each i from 0 up to tree_size - 1:
   1. Push HASH(0x00 || entries[i]) to stack.
   2. Set merge_count to the lowest value (0 included) such that LSB(i >> merge_count) is not set, where LSB means the least significant bit. In other words, set merge_count to the number of consecutive 1s found starting at the least significant bit of i.
   3. Repeat merge_count times:
      1. Pop right from stack.
      2. Pop left from stack.
      3. Push HASH(0x01 || left || right) to stack.
3. If there is more than one element in the stack, repeat the same merge procedure (the sub-items of Step 2(c) above) until only a single element remains.
4. The remaining element in stack is the Merkle Tree Hash for the given tree_size and should be compared by equality against the supplied root_hash.

1. Compare leaf_index from the inclusion_proof_v2 structure against tree_size. If leaf_index is greater than or equal to tree_size, then fail the proof verification.
2. Set fn to leaf_index and sn to tree_size - 1.
3. Set r to hash.
4. For each value p in the inclusion_path array:
   1. If sn is 0, then stop the iteration and fail the proof verification.
   2. If LSB(fn) is set, or if fn is equal to sn, then:
      1. Set r to HASH(0x01 || p || r).
      2. If LSB(fn) is not set, then right-shift both fn and sn equally until either LSB(fn) is set or fn is 0.
      Otherwise:
      1. Set r to HASH(0x01 || r || p).
   3. Finally, right-shift both fn and sn one time.
5. Compare sn to 0. Compare r against the root_hash. If sn is equal to 0 and r and the root_hash are equal, then the log has proven the inclusion of hash. Otherwise, fail the proof verification.

1. If consistency_path is an empty array, stop and fail the proof verification.
2. If first is an exact power of 2, then prepend first_hash to the consistency_path array.
3. Set fn to first - 1 and sn to second - 1.
4. If LSB(fn) is set, then right-shift both fn and sn equally until LSB(fn) is not set.
5. Set both fr and sr to the first value in the consistency_path array.
6. For each subsequent value c in the consistency_path array:
   1. If sn is 0, then stop the iteration and fail the proof verification.
   2. If LSB(fn) is set, or if fn is equal to sn, then:
      1. Set fr to HASH(0x01 || c || fr).
      2. Set sr to HASH(0x01 || c || sr).
      3. If LSB(fn) is not set, then right-shift both fn and sn equally until either LSB(fn) is set or fn is 0.
      Otherwise:
      1. Set sr to HASH(0x01 || sr || c).
   3. Finally, right-shift both fn and sn one time.
7. After completing iterating through the consistency_path array as described above, verify that the fr calculated is equal to the first_hash supplied, that the sr calculated is equal to the second_hash supplied, and that sn is 0.

• It MUST be DER encoded, as described in [X690].
• SignedData.version MUST be v3(3).
• SignedData.digestAlgorithms MUST be the same as the SignerInfo.digestAlgorithm OID value (see below).
• SignedData.encapContentInfo:
  • eContentType MUST be the OID 1.3.101.78.
  • eContent MUST contain a TBSCertificate [RFC 5280] that will be identical to the TBSCertificate in the issued certificate, except that the Transparency Information (Section 7.1) extension MUST be omitted.
• SignedData.certificates MUST be omitted.
• SignedData.crls MUST be omitted.
• SignedData.signerInfos MUST contain one SignerInfo:
  • version MUST be v3(3).
  • sid MUST use the subjectKeyIdentifier option.
  • digestAlgorithm MUST be one of the hash algorithm OIDs listed in the IANA "Hash Algorithms" registry, described in Section 10.2.1.
  • signedAttrs MUST be present and MUST contain two attributes:
    • a content-type attribute whose value is the same as SignedData.encapContentInfo.eContentType and
    • a message-digest attribute whose value is the message digest of SignedData.encapContentInfo.eContent.
  • signatureAlgorithm MUST be the same OID as TBSCertificate.signature.
  • signature MUST be from the same (root or intermediate) CA that intends to issue the corresponding certificate (see Section 3.2.1).
  • unsignedAttrs MUST be omitted.

• Misissuance of a precertificate is considered equivalent to misissuance of the corresponding certificate. The CA should expect to be held accountable, even if the corresponding certificate has not actually been issued.
• Upon observing a precertificate, a client can reasonably presume that the corresponding certificate has been issued. A client may wish to obtain status information (e.g., by using the Online Certificate Status Protocol [RFC 6960] or by checking a Certificate Revocation List [RFC 5280]) about a certificate that is presumed to exist, especially if there is evidence or suspicion that the corresponding precertificate was misissued.
• TLS clients may have policies that require CAs to be able to revoke and to provide certificate status services for each certificate that is presumed to exist based on the existence of a corresponding precertificate.

• Allocate a tree index to the entry representing the accepted submission.
• Calculate the root of the tree.
• Sign the root of the tree (see Section 4.10).

Base URL:

The prefix used to construct URLs [RFC 3986] for client messages (see Section 5). The base URL MUST be an "https" URL, MAY contain a port, and MAY contain a path with any number of path segments but MUST NOT contain a query string, fragment, or trailing "/". Example: https://ct.example.org/blue.

Hash Algorithm:

The hash algorithm used for the Merkle Tree (see Section 10.2.1).

Signature Algorithm:

The signature algorithm used (see Section 2.2).

Public Key:

The public key used to verify signatures generated by the log. A log MUST NOT use the same keypair as any other log.

Log ID:

The OID that uniquely identifies the log.

Maximum Merge Delay:

The MMD the log has committed to. This document deliberately does not specify any limits on the value to allow for experimentation.

Version:

The version of the protocol supported by the log (currently 1 or 2).

Maximum Chain Length:

The longest certificate chain submission the log is willing to accept, if the log imposes any limit.

STH Frequency Count:

The maximum number of STHs the log may produce in any period equal to the Maximum Merge Delay (see Section 4.10).

Final STH:

If a log has been closed down (i.e., no longer accepts new entries), existing entries may still be valid. In this case, the client should know the final valid STH in the log to ensure no new entries can be added without detection. This value MUST be provided in the form of a TransItem of type signed_tree_head_v2. If a log is still accepting entries, this value should not be provided.

• The submission, type, and chain inputs MUST be set as described in Section 5.1. The log MUST NOT accommodate misordered CA certificates or use any other source of intermediate CA certificates to attempt certification path construction.
• Each of the zero or more intermediate CA certificates in the chain MUST have one or both of the following features:
  • The Basic Constraints extension with the cA boolean asserted.
  • The Key Usage extension with the keyCertSign bit asserted.
• Each certificate in the chain MUST fall within the limits imposed by the zero or more Basic Constraints pathLenConstraint values found higher up the chain.
• Precertificate submissions MUST conform to all of the requirements in Section 3.2.

• Make it known to clients and monitors that the log will be frozen. This is not part of the API, so it will have to be done via a relevant out-of-band mechanism.
• Stop accepting new submissions (the error code "shutdown" should be returned for such requests).
• Once MMD from the last accepted submission has passed and all pending submissions are incorporated, issue a final STH and publish it as one of the log's parameters. Having an STH with a timestamp that is after the MMD has passed from the last SCT issuance allows clients to audit this log regularly without special handling for the final STH. At this point, the log's private key is no longer needed and can be destroyed.
• Keep the log running until the certificates in all of its entries have expired or exist in other logs (this can be determined by scanning other logs or connecting to domains mentioned in the certificates and inspecting the SCTs served).

type:

A URN reference identifying the problem. To facilitate automated response to errors, this document defines a set of standard tokens for use in the type field within the URN namespace of: "urn:ietf:params:trans:error:".

detail:

A human-readable string describing the error that prevented the log from processing the request, ideally with sufficient detail to enable the error to be rectified.

    {
        "type": "urn:ietf:params:trans:error:endBeforeStart",
        "detail": "'start' cannot be greater than 'end'"
    }

Inputs:

submission:

The base64-encoded certificate or precertificate.

type:

The VersionedTransType integer value that indicates the type of the submission: 1 for x509_entry_v2 or 2 for precert_entry_v2.

chain:

An array of zero or more JSON strings, each of which is a base64-encoded CA certificate. The first element is the certifier of the submission, the second certifies the first, etc. The last element of chain (or, if chain is an empty array, the submission) is certified by an accepted trust anchor.

Outputs:

sct:

A base64-encoded TransItem of type x509_sct_v2 or precert_sct_v2, signed by this log, that corresponds to the submission.

If the submitted entry is immediately appended to (or already exists in) this log's tree, then the log SHOULD also output:

sth:

A base64-encoded TransItem of type signed_tree_head_v2 signed by this log.

inclusion:

A base64-encoded TransItem of type inclusion_proof_v2 whose inclusion_path array of Merkle Tree nodes proves the inclusion of the submission in the returned sth.

Outputs:

sth:

A base64-encoded TransItem of type signed_tree_head_v2 signed by this log that is no older than the log's MMD.

Inputs:

first:

The tree_size of the older tree, in decimal.

second:

The tree_size of the newer tree, in decimal (optional).

Both tree sizes must be from existing v2 STHs. However, because of skew, the receiving front end may not know one or both of the existing STHs. If both are known, then only the consistency output is returned. If the first is known but the second is not (or has been omitted), then the latest known STH is returned, along with a consistency proof between the first STH and the latest. If neither are known, then the latest known STH is returned without a consistency proof.

Outputs:

consistency:

A base64-encoded TransItem of type consistency_proof_v2 whose tree_size_1 MUST match the first input. If the sth output is omitted, then tree_size_2 MUST match the second input. If first and second are equal and correspond to a known STH, the returned consistency proof MUST be empty (a consistency_path array with zero elements).

sth:

A base64-encoded TransItem of type signed_tree_head_v2, signed by this log.

Note that no signature is required for the consistency output, as it is used to verify the consistency between two signed STHs.

Inputs:

hash:

A base64-encoded v2 leaf hash.

tree_size:

The tree_size of the tree on which to base the proof, in decimal.

The hash must be calculated as defined in Section 4.7. A v2 STH must exist for the tree_size. Because of skew, the front end may not know the requested tree head. In that case, it will return the latest STH it knows, along with an inclusion proof to that STH. If the front end knows the requested tree head, then only inclusion is returned.

Outputs:

inclusion:

A base64-encoded TransItem of type inclusion_proof_v2 whose inclusion_path array of Merkle Tree nodes proves the inclusion of the certificate (as specified by the hash parameter) in the selected STH.

sth:

A base64-encoded TransItem of type signed_tree_head_v2, signed by this log.

Note that no signature is required for the inclusion output, as it is used to verify inclusion in the selected STH, which is signed.

Inputs:

hash:

A base64-encoded v2 leaf hash.

tree_size:

The tree_size of the tree on which to base the proofs, in decimal.

The hash must be calculated as defined in Section 4.7. A v2 STH must exist for the tree_size.

Outputs:

inclusion:

A base64-encoded TransItem of type inclusion_proof_v2 whose inclusion_path array of Merkle Tree nodes proves the inclusion of the certificate (as specified by the hash parameter) in the selected STH.

sth:

A base64-encoded TransItem of type signed_tree_head_v2, signed by this log.

consistency:

A base64-encoded TransItem of type consistency_proof_v2 that proves the consistency of the requested tree head and the returned STH.

Note that no signature is required for the inclusion or consistency outputs, as they are used to verify inclusion in and consistency of signed STHs.

Inputs:

start:

0-based index of first entry to retrieve, in decimal.

end:

0-based index of last entry to retrieve, in decimal.

Outputs:

entries:

An array of objects, each consisting of:

log_entry:

The base64-encoded TransItem structure of type x509_entry_v2 or precert_entry_v2 (see Section 4.3).

submitted_entry:

JSON object equivalent to inputs that were submitted to submit-entry, with the addition of the trust anchor to the chain field if the submission did not include it.

sct:

The base64-encoded TransItem of type x509_sct_v2 or precert_sct_v2, corresponding to this log entry.

sth:

A base64-encoded TransItem of type signed_tree_head_v2, signed by this log.

Outputs:

certificates:

An array of JSON strings, each of which is a base64-encoded CA certificate that is acceptable to the log.

max_chain_length:

If the server has chosen to limit the length of chains it accepts, this is the maximum number of certificates in the chain, in decimal. If there is no limit, this is omitted.

This data is not signed, and the protocol depends on the security guarantees of TLS to ensure correctness.

• The greater security exposure is for clients to end up interacting with an illegitimate server.
• In general, TLS client certificates are not expected to be submitted to CT logs, particularly those intended for general public use.

• The set of logs trusted by TLS clients is neither unified nor static; each client vendor may maintain an independent list of trusted logs, and, over time, new logs may become trusted and current logs may become distrusted. Note that client discovery, trust, and distrust of logs are expected to be handled out of band and are out of scope of this document.
• If a CA and a log collude, it is possible to temporarily hide misissuance from clients. When a TLS client requires SCTs from multiple logs to be provided, it is more difficult to mount this attack.
• If a log misbehaves or suffers a key compromise, a consequence may be that clients cease to trust it. Since the time an SCT may be in use can be considerable (several years is common in current practice when embedded in a certificate), including SCTs from multiple logs reduces the probability of the certificate being rejected by TLS clients.
• TLS clients may have policies related to the above risks requiring TLS servers to present multiple SCTs. For example, at the time of writing, Chromium [Chromium.Log.Policy] requires multiple SCTs to be presented with Extended Validation (EV) certificates in order for the EV indicator to be shown.

• The TLS server MUST verify that the received extension_data is empty.
• The TLS server MUST construct a TransItemList of relevant TransItems (see Section 6.4), which SHOULD omit any TransItems that are already embedded in the server certificate or the stapled OCSP response (see Section 7.1). If the constructed TransItemList is not empty, then the TLS server MUST include the transparency_info extension with the extension_data set to this TransItemList. If the list is empty, then the server SHOULD omit the extension_data element but MAY send it with an empty array.

• the ServerHello message (for TLS 1.2 or earlier)
• the Certificate or CertificateRequest message (for TLS 1.3)

• Remove the Transparency Information extension (see Section 7.1).
• Remove embedded v1 SCTs, identified by OID 1.3.6.1.4.1.11129.2.4.2 (see Section 3.3 of RFC 6962). This allows embedded v1 and v2 SCTs to co-exist in a certificate (see Appendix A).

• Compute the signature input by constructing a TransItem of type x509_entry_v2 or precert_entry_v2, depending on the SCT's TransItem type. The TimestampedCertificateEntryDataV2 structure is constructed in the following manner:
  • timestamp is copied from the SCT.
  • tbs_certificate is the reconstructed TBSCertificate portion of the server certificate, as described in Section 8.1.2.
  • issuer_key_hash is computed as described in Section 4.7.
  • sct_extensions is copied from the SCT.
• Verify the SCT's signature against the computed signature input using the public key of the corresponding log, which is identified by the log_id. The required signature algorithm is one of the log's parameters.

1. Fetch the current STH (Section 5.2).
2. Verify the STH signature.
3. Fetch all the entries in the tree corresponding to the STH (Section 5.6).
4. If applicable, check each entry to see if it's a certificate of interest.
5. Confirm that the tree made from the fetched entries produces the same hash as that in the STH.

1. Fetch the current STH (Section 5.2). Repeat until the STH changes. To allow for experimentation, this document does not specify the polling frequency.
2. Verify the STH signature.
3. Fetch all the new entries in the tree corresponding to the STH (Section 5.6). If they remain unavailable for an extended period, then this should be viewed as misbehavior on the part of the log.
4. If applicable, check each entry to see if it's a certificate of interest.
5. Either:
   1. Verify that the updated list of all entries generates a tree with the same hash as the new STH.
   Or, if it is not keeping all log entries:
   1. Fetch a consistency proof for the new STH with the previous STH (Section 5.3).
   2. Verify the consistency proof.
   3. Verify that the new entries generate the corresponding elements in the consistency proof.
6. Repeat from Step 1.

• the Maximum Merge Delay (MMD)
• the STH Frequency Count
• the append-only property
• the consistency of the log view presented to all query sources

Signature algorithm:

SCT signatures must remain valid so signature algorithms can only be added, not removed.

Hash algorithm:

A log would have to support the old and new hash algorithms to allow backwards compatibility with clients that are not aware of a hash algorithm change.

Registry name:

trans

Specification:

RFC 9162

Repository:

<https://www.iana.org/assignments/trans>

Index value:

No transformation needed.

• "SCT", for extensions specified for use in Signed Certificate Timestamps.
• "STH", for extensions specified for use in Signed Tree Heads.

• the Log's Base URL (see Section 4.1) and
• the Log Operator's contact details.

• using deterministic signature schemes or
• producing no more than one SCT for each distinct submission and no more than one STH for each distinct tree_size. Each of these SCTs and STHs can be stored by the log and served to other clients that submit the same certificate or request the same STH.

[FIPS186-4]

National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 186-4, July 2013,
<http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf>.

[HTML401]

D. Raggett, A. Le Hors, and I. Jacobs, "HTML 4.01 Specification", W3C Recommendation SPSD-html401-20180327, March 2018,
<https://www.w3.org/TR/2018/SPSD-html401-20180327>.

[RFC2119]

S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC3553]

M. Mealling, L. Masinter, T. Hardie, and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 2003,
<https://www.rfc-editor.org/info/rfc3553>.

[RFC3986]

T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.

[RFC4648]

S. Josefsson, "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.

[RFC5246]

T. Dierks, and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.

[RFC5280]

D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.

[RFC5652]

R. Housley, "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>.

[RFC6066]

D. Eastlake 3rd, "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>.

[RFC6234]

D. Eastlake 3rd, and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.

[RFC6960]

S. Santesson, M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/info/rfc6960>.

[RFC6979]

T. Pornin, "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2013,
<https://www.rfc-editor.org/info/rfc6979>.

[RFC7231]

R. Fielding, and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>.

[RFC7633]

P. Hallam-Baker, "X.509v3 Transport Layer Security (TLS) Feature Extension", RFC 7633, DOI 10.17487/RFC7633, October 2015,
<https://www.rfc-editor.org/info/rfc7633>.

[RFC7807]

M. Nottingham, and E. Wilde, "Problem Details for HTTP APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016,
<https://www.rfc-editor.org/info/rfc7807>.

[RFC8032]

S. Josefsson, and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.

[RFC8174]

B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.

[RFC8259]

T. Bray, "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.

[RFC8391]

A. Huelsing, D. Butin, S. Gazdag, J. Rijneveld, and A. Mohaisen, "XMSS: eXtended Merkle Signature Scheme", RFC 8391, DOI 10.17487/RFC8391, May 2018,
<https://www.rfc-editor.org/info/rfc8391>.

[RFC8446]

E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.

[UNIXTIME]

IEEE, "The Open Group Base Specifications Issue 7", IEEE Std 1003.1-2008, 2016,
<http://pubs.opengroup.org/onlinepubs/9699919799.2016edition/basedefs/V1_chap04.html#tag_04_16>.

[X690]

ITU-T, "Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1, February 2021.

[CABBR]

CA/Browser Forum, "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates", Version 1.7.3, October 2020,
<https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.7.3.pdf>.

[Chromium.Log.Policy]

The Chromium Projects, "Chromium Certificate Transparency Log Policy",
<https://googlechrome.github.io/CertificateTransparency/log_policy.html>.

[Chromium.Policy]

The Chromium Projects, "Chromium Certificate Transparency Policy",
<https://googlechrome.github.io/CertificateTransparency/ct_policy.html>.

[CrosbyWallach]

S. Crosby, and D. Wallach, "Efficient Data Structures for Tamper-Evident Logging", August 2009,
<http://static.usenix.org/event/sec09/tech/full_papers/crosby.pdf>.

[JSON.Metadata]

The Chromium Projects, "Chromium Log Metadata JSON Schema",
<https://www.gstatic.com/ct/log_list/log_list_schema.json>.

[RFC5912]

P. Hoffman, and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010,
<https://www.rfc-editor.org/info/rfc5912>.

[RFC6268]

J. Schaad, and S. Turner, "Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)", RFC 6268, DOI 10.17487/RFC6268, July 2011,
<https://www.rfc-editor.org/info/rfc6268>.

[RFC6962]

B. Laurie, A. Langley, and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<https://www.rfc-editor.org/info/rfc6962>.

[RFC8126]

M. Cotton, B. Leiba, and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.

[RFC8820]

M. Nottingham, "URI Design and Ownership", BCP 190, RFC 8820, DOI 10.17487/RFC8820, June 2020,
<https://www.rfc-editor.org/info/rfc8820>.

[X.680]

ITU-T, "Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, February 2021.

• Create a CMS precertificate, as described in Section 3.2, and submit it to v2 logs.
• Embed the obtained v2 SCTs in the TBSCertificate, as described in Section 7.1.2.
• Use that TBSCertificate to create a v1 precertificate, as described in Section 3.1 of RFC 6962, and submit it to v1 logs.
• Embed the v1 SCTs in the TBSCertificate, as described in Section 3.3 of RFC 6962.
• Sign that TBSCertificate (which now contains v1 and v2 SCTs) to issue the final X.509 certificate.

Ben Laurie

Eran Messeri

Rob Stradling