draft-ietf-trans-rfc6962-bis-30.txt   draft-ietf-trans-rfc6962-bis-31.txt 
TRANS (Public Notary Transparency) B. Laurie TRANS (Public Notary Transparency) B. Laurie
Internet-Draft A. Langley Internet-Draft A. Langley
Obsoletes: 6962 (if approved) E. Kasper Obsoletes: 6962 (if approved) E. Kasper
Intended status: Experimental E. Messeri Intended status: Experimental E. Messeri
Expires: May 10, 2019 Google Expires: August 29, 2019 Google
R. Stradling R. Stradling
Sectigo Sectigo
November 06, 2018 February 25, 2019
Certificate Transparency Version 2.0 Certificate Transparency Version 2.0
draft-ietf-trans-rfc6962-bis-30 draft-ietf-trans-rfc6962-bis-31
Abstract Abstract
This document describes version 2.0 of the Certificate Transparency This document describes version 2.0 of the Certificate Transparency
(CT) protocol for publicly logging the existence of Transport Layer (CT) protocol for publicly logging the existence of Transport Layer
Security (TLS) server certificates as they are issued or observed, in Security (TLS) server certificates as they are issued or observed, in
a manner that allows anyone to audit certification authority (CA) a manner that allows anyone to audit certification authority (CA)
activity and notice the issuance of suspect certificates as well as activity and notice the issuance of suspect certificates as well as
to audit the certificate logs themselves. The intent is that to audit the certificate logs themselves. The intent is that
eventually clients would refuse to honor certificates that do not eventually clients would refuse to honor certificates that do not
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 10, 2019. This Internet-Draft will expire on August 29, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 39 skipping to change at page 2, line 39
2.1.2. Verifying a Tree Head Given Entries . . . . . . . . . 8 2.1.2. Verifying a Tree Head Given Entries . . . . . . . . . 8
2.1.3. Merkle Inclusion Proofs . . . . . . . . . . . . . . . 8 2.1.3. Merkle Inclusion Proofs . . . . . . . . . . . . . . . 8
2.1.4. Merkle Consistency Proofs . . . . . . . . . . . . . . 10 2.1.4. Merkle Consistency Proofs . . . . . . . . . . . . . . 10
2.1.5. Example . . . . . . . . . . . . . . . . . . . . . . . 12 2.1.5. Example . . . . . . . . . . . . . . . . . . . . . . . 12
2.2. Signatures . . . . . . . . . . . . . . . . . . . . . . . 13 2.2. Signatures . . . . . . . . . . . . . . . . . . . . . . . 13
3. Submitters . . . . . . . . . . . . . . . . . . . . . . . . . 13 3. Submitters . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Certificates . . . . . . . . . . . . . . . . . . . . . . 14 3.1. Certificates . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Precertificates . . . . . . . . . . . . . . . . . . . . . 14 3.2. Precertificates . . . . . . . . . . . . . . . . . . . . . 14
4. Log Format and Operation . . . . . . . . . . . . . . . . . . 15 4. Log Format and Operation . . . . . . . . . . . . . . . . . . 15
4.1. Log Parameters . . . . . . . . . . . . . . . . . . . . . 16 4.1. Log Parameters . . . . . . . . . . . . . . . . . . . . . 16
4.2. Accepting Submissions . . . . . . . . . . . . . . . . . . 17 4.2. Evaluating Submissions . . . . . . . . . . . . . . . . . 17
4.2.1. Minimum Acceptance Criteria . . . . . . . . . . . . . 17
4.2.2. Discretionary Acceptance Criteria . . . . . . . . . . 18
4.3. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 18 4.3. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 18
4.4. Log ID . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.4. Log ID . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.5. TransItem Structure . . . . . . . . . . . . . . . . . . . 19 4.5. TransItem Structure . . . . . . . . . . . . . . . . . . . 19
4.6. Log Artifact Extensions . . . . . . . . . . . . . . . . . 20 4.6. Log Artifact Extensions . . . . . . . . . . . . . . . . . 20
4.7. Merkle Tree Leaves . . . . . . . . . . . . . . . . . . . 20 4.7. Merkle Tree Leaves . . . . . . . . . . . . . . . . . . . 21
4.8. Signed Certificate Timestamp (SCT) . . . . . . . . . . . 21 4.8. Signed Certificate Timestamp (SCT) . . . . . . . . . . . 22
4.9. Merkle Tree Head . . . . . . . . . . . . . . . . . . . . 22 4.9. Merkle Tree Head . . . . . . . . . . . . . . . . . . . . 23
4.10. Signed Tree Head (STH) . . . . . . . . . . . . . . . . . 22 4.10. Signed Tree Head (STH) . . . . . . . . . . . . . . . . . 23
4.11. Merkle Consistency Proofs . . . . . . . . . . . . . . . . 23 4.11. Merkle Consistency Proofs . . . . . . . . . . . . . . . . 24
4.12. Merkle Inclusion Proofs . . . . . . . . . . . . . . . . . 24 4.12. Merkle Inclusion Proofs . . . . . . . . . . . . . . . . . 25
4.13. Shutting down a log . . . . . . . . . . . . . . . . . . . 24 4.13. Shutting down a log . . . . . . . . . . . . . . . . . . . 25
5. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 25
5. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 26
5.1. Submit Entry to Log . . . . . . . . . . . . . . . . . . . 27 5.1. Submit Entry to Log . . . . . . . . . . . . . . . . . . . 27
5.2. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 29 5.2. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 30
5.3. Retrieve Merkle Consistency Proof between Two Signed Tree 5.3. Retrieve Merkle Consistency Proof between Two Signed Tree
Heads . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Heads . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.4. Retrieve Merkle Inclusion Proof from Log by Leaf Hash . . 30 5.4. Retrieve Merkle Inclusion Proof from Log by Leaf Hash . . 31
5.5. Retrieve Merkle Inclusion Proof, Signed Tree Head and 5.5. Retrieve Merkle Inclusion Proof, Signed Tree Head and
Consistency Proof by Leaf Hash . . . . . . . . . . . . . 31 Consistency Proof by Leaf Hash . . . . . . . . . . . . . 32
5.6. Retrieve Entries and STH from Log . . . . . . . . . . . . 32 5.6. Retrieve Entries and STH from Log . . . . . . . . . . . . 33
5.7. Retrieve Accepted Trust Anchors . . . . . . . . . . . . . 34 5.7. Retrieve Accepted Trust Anchors . . . . . . . . . . . . . 35
6. TLS Servers . . . . . . . . . . . . . . . . . . . . . . . . . 34 6. TLS Servers . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.1. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . . 35 6.1. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . . 36
6.2. TransItemList Structure . . . . . . . . . . . . . . . . . 36 6.2. TransItemList Structure . . . . . . . . . . . . . . . . . 37
6.3. Presenting SCTs, inclusions proofs and STHs . . . . . . . 36 6.3. Presenting SCTs, inclusions proofs and STHs . . . . . . . 37
6.4. transparency_info TLS Extension . . . . . . . . . . . . . 36 6.4. transparency_info TLS Extension . . . . . . . . . . . . . 37
6.5. cached_info TLS Extension . . . . . . . . . . . . . . . . 37 7. Certification Authorities . . . . . . . . . . . . . . . . . . 38
7. Certification Authorities . . . . . . . . . . . . . . . . . . 37 7.1. Transparency Information X.509v3 Extension . . . . . . . 38
7.1. Transparency Information X.509v3 Extension . . . . . . . 37
7.1.1. OCSP Response Extension . . . . . . . . . . . . . . . 38 7.1.1. OCSP Response Extension . . . . . . . . . . . . . . . 38
7.1.2. Certificate Extension . . . . . . . . . . . . . . . . 38 7.1.2. Certificate Extension . . . . . . . . . . . . . . . . 38
7.2. TLS Feature X.509v3 Extension . . . . . . . . . . . . . . 38 7.2. TLS Feature X.509v3 Extension . . . . . . . . . . . . . . 39
8. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 8. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.1. TLS Client . . . . . . . . . . . . . . . . . . . . . . . 38 8.1. TLS Client . . . . . . . . . . . . . . . . . . . . . . . 39
8.1.1. Receiving SCTs and inclusion proofs . . . . . . . . . 38 8.1.1. Receiving SCTs and inclusion proofs . . . . . . . . . 39
8.1.2. Reconstructing the TBSCertificate . . . . . . . . . . 39 8.1.2. Reconstructing the TBSCertificate . . . . . . . . . . 39
8.1.3. Validating SCTs . . . . . . . . . . . . . . . . . . . 39 8.1.3. Validating SCTs . . . . . . . . . . . . . . . . . . . 40
8.1.4. Fetching inclusion proofs . . . . . . . . . . . . . . 39 8.1.4. Fetching inclusion proofs . . . . . . . . . . . . . . 40
8.1.5. Validating inclusion proofs . . . . . . . . . . . . . 40 8.1.5. Validating inclusion proofs . . . . . . . . . . . . . 41
8.1.6. Evaluating compliance . . . . . . . . . . . . . . . . 40 8.1.6. Evaluating compliance . . . . . . . . . . . . . . . . 41
8.1.7. cached_info TLS Extension . . . . . . . . . . . . . . 40
8.2. Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 41 8.2. Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.3. Auditing . . . . . . . . . . . . . . . . . . . . . . . . 42 8.3. Auditing . . . . . . . . . . . . . . . . . . . . . . . . 42
9. Algorithm Agility . . . . . . . . . . . . . . . . . . . . . . 43 9. Algorithm Agility . . . . . . . . . . . . . . . . . . . . . . 43
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
10.1. New Entry to the TLS ExtensionType Registry . . . . . . 43 10.1. New Entry to the TLS ExtensionType Registry . . . . . . 44
10.2. New Entry to the TLS CachedInformationType registry . . 43 10.2. Hash Algorithms . . . . . . . . . . . . . . . . . . . . 44
10.3. Hash Algorithms . . . . . . . . . . . . . . . . . . . . 44 10.2.1. Expert Review guidelines . . . . . . . . . . . . . . 45
10.3.1. Expert Review guidelines . . . . . . . . . . . . . . 44 10.3. Signature Algorithms . . . . . . . . . . . . . . . . . . 45
10.4. Signature Algorithms . . . . . . . . . . . . . . . . . . 44 10.3.1. Expert Review guidelines . . . . . . . . . . . . . . 45
10.4.1. Expert Review guidelines . . . . . . . . . . . . . . 45 10.4. VersionedTransTypes . . . . . . . . . . . . . . . . . . 45
10.5. VersionedTransTypes . . . . . . . . . . . . . . . . . . 45 10.4.1. Expert Review guidelines . . . . . . . . . . . . . . 46
10.5.1. Expert Review guidelines . . . . . . . . . . . . . . 46 10.5. Log Artifact Extension Registry . . . . . . . . . . . . 46
10.6. Log Artifact Extension Registry . . . . . . . . . . . . 46 10.5.1. Expert Review guidelines . . . . . . . . . . . . . . 47
10.6.1. Expert Review guidelines . . . . . . . . . . . . . . 47 10.6. Object Identifiers . . . . . . . . . . . . . . . . . . . 47
10.7. Object Identifiers . . . . . . . . . . . . . . . . . . . 47 10.6.1. Log ID Registry . . . . . . . . . . . . . . . . . . 47
10.7.1. Log ID Registry . . . . . . . . . . . . . . . . . . 47
11. Security Considerations . . . . . . . . . . . . . . . . . . . 48 11. Security Considerations . . . . . . . . . . . . . . . . . . . 48
11.1. Misissued Certificates . . . . . . . . . . . . . . . . . 49 11.1. Misissued Certificates . . . . . . . . . . . . . . . . . 49
11.2. Detection of Misissue . . . . . . . . . . . . . . . . . 49 11.2. Detection of Misissue . . . . . . . . . . . . . . . . . 49
11.3. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 49 11.3. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 49
11.4. Preventing Tracking Clients . . . . . . . . . . . . . . 50 11.4. Preventing Tracking Clients . . . . . . . . . . . . . . 50
11.5. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . 50 11.5. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . 50
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
13.1. Normative References . . . . . . . . . . . . . . . . . . 50 13.1. Normative References . . . . . . . . . . . . . . . . . . 50
13.2. Informative References . . . . . . . . . . . . . . . . . 52 13.2. Informative References . . . . . . . . . . . . . . . . . 52
skipping to change at page 6, line 49 skipping to change at page 6, line 49
chain. chain.
o Presenting SCTs with proofs: TLS servers may present SCTs together o Presenting SCTs with proofs: TLS servers may present SCTs together
with the corresponding inclusion proofs using any of the with the corresponding inclusion proofs using any of the
mechanisms that [RFC6962] defined for presenting SCTs only. mechanisms that [RFC6962] defined for presenting SCTs only.
(Presenting SCTs only is still supported). (Presenting SCTs only is still supported).
o CT TLS extension: the "signed_certificate_timestamp" TLS extension o CT TLS extension: the "signed_certificate_timestamp" TLS extension
has been replaced by the "transparency_info" TLS extension. has been replaced by the "transparency_info" TLS extension.
o Other TLS extensions: "status_request_v2" may be used (in the same
manner as "status_request"); "cached_info" may be used to avoid
sending the same complete SCTs and inclusion proofs to the same
TLS clients multiple times.
o Verification algorithms: added detailed algorithms for verifying o Verification algorithms: added detailed algorithms for verifying
inclusion proofs, for verifying consistency between two STHs, and inclusion proofs, for verifying consistency between two STHs, and
for verifying a root hash given a complete list of the relevant for verifying a root hash given a complete list of the relevant
leaf input entries. leaf input entries.
o Extensive clarifications and editorial work. o Extensive clarifications and editorial work.
2. Cryptographic Components 2. Cryptographic Components
2.1. Merkle Hash Trees 2.1. Merkle Hash Trees
2.1.1. Definition of the Merkle Tree 2.1.1. Definition of the Merkle Tree
The log uses a binary Merkle Hash Tree for efficient auditing. The The log uses a binary Merkle Hash Tree for efficient auditing. The
hash algorithm used is one of the log's parameters (see Section 4.1). hash algorithm used is one of the log's parameters (see Section 4.1).
We have established a registry of acceptable hash algorithms (see We have established a registry of acceptable hash algorithms (see
Section 10.3). Throughout this document, the hash algorithm in use Section 10.2). Throughout this document, the hash algorithm in use
is referred to as HASH and the size of its output in bytes as is referred to as HASH and the size of its output in bytes as
HASH_SIZE. The input to the Merkle Tree Hash is a list of data HASH_SIZE. The input to the Merkle Tree Hash is a list of data
entries; these entries will be hashed to form the leaves of the entries; these entries will be hashed to form the leaves of the
Merkle Hash Tree. The output is a single HASH_SIZE Merkle Tree Hash. Merkle Hash Tree. The output is a single HASH_SIZE Merkle Tree Hash.
Given an ordered list of n inputs, D_n = {d[0], d[1], ..., d[n-1]}, Given an ordered list of n inputs, D_n = {d[0], d[1], ..., d[n-1]},
the Merkle Tree Hash (MTH) is thus defined as follows: the Merkle Tree Hash (MTH) is thus defined as follows:
The hash of an empty list is the hash of an empty string: The hash of an empty list is the hash of an empty string:
MTH({}) = HASH(). MTH({}) = HASH().
skipping to change at page 13, line 45 skipping to change at page 13, line 45
The consistency proof between hash1 and hash is PROOF(4, D[7]) = [l]. The consistency proof between hash1 and hash is PROOF(4, D[7]) = [l].
hash can be verified using hash1=k and l. hash can be verified using hash1=k and l.
The consistency proof between hash2 and hash is PROOF(6, D[7]) = [i, The consistency proof between hash2 and hash is PROOF(6, D[7]) = [i,
j, k]. k, i are used to verify hash2, and j is additionally used to j, k]. k, i are used to verify hash2, and j is additionally used to
show hash is consistent with hash2. show hash is consistent with hash2.
2.2. Signatures 2.2. Signatures
Various data structures Section 1.2 are signed. A log MUST use one Various data structures Section 1.2 are signed. A log MUST use one
of the signature algorithms defined in Section 10.4. of the signature algorithms defined in Section 10.3.
3. Submitters 3. Submitters
Submitters submit certificates or preannouncements of certificates Submitters submit certificates or preannouncements of certificates
prior to issuance (precertificates) to logs for public auditing, as prior to issuance (precertificates) to logs for public auditing, as
described below. In order to enable attribution of each logged described below. In order to enable attribution of each logged
certificate or precertificate to its issuer, each submission MUST be certificate or precertificate to its issuer, each submission MUST be
accompanied by all additional certificates required to verify the accompanied by all additional certificates required to verify the
chain up to an accepted trust anchor (Section 5.7). The trust anchor chain up to an accepted trust anchor (Section 5.7). The trust anchor
(a root or intermediate CA certificate) MAY be omitted from the (a root or intermediate CA certificate) MAY be omitted from the
skipping to change at page 15, line 16 skipping to change at page 15, line 16
o "SignedData.crls" MUST be omitted. o "SignedData.crls" MUST be omitted.
o "SignedData.signerInfos" MUST contain one "SignerInfo": o "SignedData.signerInfos" MUST contain one "SignerInfo":
* "version" MUST be v3(3). * "version" MUST be v3(3).
* "sid" MUST use the "subjectKeyIdentifier" option. * "sid" MUST use the "subjectKeyIdentifier" option.
* "digestAlgorithm" MUST be one of the hash algorithm OIDs listed * "digestAlgorithm" MUST be one of the hash algorithm OIDs listed
in Section 10.3. in Section 10.2.
* "signedAttrs" MUST be present and MUST contain two attributes: * "signedAttrs" MUST be present and MUST contain two attributes:
+ A content-type attribute whose value is the same as + A content-type attribute whose value is the same as
"SignedData.encapContentInfo.eContentType". "SignedData.encapContentInfo.eContentType".
+ A message-digest attribute whose value is the message digest + A message-digest attribute whose value is the message digest
of "SignedData.encapContentInfo.eContent". of "SignedData.encapContentInfo.eContent".
* "signatureAlgorithm" MUST be the same OID as * "signatureAlgorithm" MUST be the same OID as
skipping to change at page 16, line 40 skipping to change at page 16, line 40
sharing data from the log. sharing data from the log.
4.1. Log Parameters 4.1. Log Parameters
A log is defined by a collection of parameters, which are used by A log is defined by a collection of parameters, which are used by
clients to communicate with the log and to verify log artifacts. clients to communicate with the log and to verify log artifacts.
Base URL: The URL to substitute for <log server> in Section 5. Base URL: The URL to substitute for <log server> in Section 5.
Hash Algorithm: The hash algorithm used for the Merkle Tree (see Hash Algorithm: The hash algorithm used for the Merkle Tree (see
Section 10.3). Section 10.2).
Signature Algorithm: The signature algorithm used (see Section 2.2). Signature Algorithm: The signature algorithm used (see Section 2.2).
Public Key: The public key used to verify signatures generated by 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. the log. A log MUST NOT use the same keypair as any other log.
Log ID: The OID that uniquely identifies the log. Log ID: The OID that uniquely identifies the log.
Maximum Merge Delay: The MMD the log has committed to. Maximum Merge Delay: The MMD the log has committed to.
skipping to change at page 17, line 25 skipping to change at page 17, line 25
Final STH: If a log has been closed down (i.e., no longer accepts 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, 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 the client should know the final valid STH in the log to ensure no
new entries can be added without detection. The final STH should new entries can be added without detection. The final STH should
be provided in the form of a TransItem of type be provided in the form of a TransItem of type
"signed_tree_head_v2". "signed_tree_head_v2".
[JSON.Metadata] is an example of a metadata format which includes the [JSON.Metadata] is an example of a metadata format which includes the
above elements. above elements.
4.2. Accepting Submissions 4.2. Evaluating Submissions
A log determines whether to accept or reject a submission by
evaluating it against the minimum acceptance criteria (see
Section 4.2.1) and against the log's discretionary acceptance
criteria (see Section 4.2.2).
If the acceptance criteria are met, the log SHOULD accept the
submission. (A log may decide, for example, to temporarily reject
acceptable submissions to protect itself against denial-of-service
attacks).
The log SHALL allow retrieval of its list of accepted trust anchors
(see Section 5.7), each of which is a root or intermediate CA
certificate. This list might usefully be the union of root
certificates trusted by major browser vendors.
4.2.1. Minimum Acceptance Criteria
To ensure that logged certificates and precertificates are To ensure that logged certificates and precertificates are
attributable to a known trust anchor, and to set clear expectations attributable to an accepted trust anchor, and to set clear
for what monitors would find in a log, and to avoid being overloaded expectations for what monitors would find in the log, and to avoid
by invalid submissions, the log MUST NOT accept any submission until being overloaded by invalid submissions, the log MUST reject a
it has verified that the submitted certificate or precertificate submission if any of the following conditions are not met:
chains to an accepted trust anchor.
The log MUST NOT use other sources of intermediate CA certificates to o The "submission", "type" and "chain" inputs MUST be set as
attempt certification path construction; instead, it MUST only use described in Section 5.1. The log MUST NOT accommodate misordered
the intermediate CA certificates provided in the submission, in the CA certificates or use any other source of intermediate CA
order provided. certificates to attempt certification path construction.
Logs SHOULD accept certificates and precertificates that are fully o Each of the zero or more intermediate CA certificates in the chain
valid according to RFC 5280 [RFC5280] verification rules and are MUST have one or both of the following features:
submitted with such a chain. (A log may decide, for example, to
temporarily reject valid submissions to protect itself against
denial-of-service attacks).
Logs MAY accept certificates and precertificates that have expired, * The Basic Constraints extension with the cA boolean asserted.
are not yet valid, have been revoked, or are otherwise not fully
valid according to RFC 5280 verification rules in order to * The Key Usage extension with the keyCertSign bit asserted.
accommodate quirks of CA certificate-issuing software. However, logs
MUST reject submissions without a valid signature chain to an o Each certificate in the chain MUST fall within the limits imposed
accepted trust anchor. Logs MUST also reject precertificates that do by the zero or more Basic Constraints pathLenConstraint values
not conform to the requirements in Section 3.2. found higher up the chain.
o Precertificate submissions MUST conform to all of the requirements
in Section 3.2.
4.2.2. Discretionary Acceptance Criteria
If the minimum acceptance criteria are met but the submission is not
fully valid according to [RFC5280] verification rules (e.g., the
certificate or precertificate has expired, is not yet valid, has been
revoked, exhibits ASN.1 DER encoding errors but the log can still
parse it, etc), then the acceptability of the submission is left to
the log's discretion. It is useful for logs to accept such
submissions in order to accommodate quirks of CA certificate-issuing
software and to facilitate monitoring of CA compliance with
applicable policies and technical standards. However, it is
impractical for this document to enumerate, and for logs to consider,
all of the ways that a submission might fail to comply with
[RFC5280].
Logs SHOULD limit the length of chain they will accept. The maximum Logs SHOULD limit the length of chain they will accept. The maximum
chain length is one of the log's parameters (see Section 4.1). chain length is one of the log's parameters (see Section 4.1).
The log SHALL allow retrieval of its list of accepted trust anchors
(see Section 5.7), each of which is a root or intermediate CA
certificate. This list might usefully be the union of root
certificates trusted by major browser vendors.
4.3. Log Entries 4.3. Log Entries
If a submission is accepted and an SCT issued, the accepting log MUST If a submission is accepted and an SCT issued, the accepting log MUST
store the entire chain used for verification. This chain MUST store the entire chain used for verification. This chain MUST
include the certificate or precertificate itself, the zero or more include the certificate or precertificate itself, the zero or more
intermediate CA certificates provided by the submitter, and the trust intermediate CA certificates provided by the submitter, and the trust
anchor used to verify the chain (even if it was omitted from the anchor used to verify the chain (even if it was omitted from the
submission). The log MUST present this chain for auditing upon submission). The log MUST present this chain for auditing upon
request (see Section 5.6). This prevents the CA from avoiding blame request (see Section 5.6). This prevents the CA from avoiding blame
by logging a partial or empty chain. Each log entry is a "TransItem" by logging a partial or empty chain. Each log entry is a "TransItem"
skipping to change at page 18, line 37 skipping to change at page 19, line 15
"TimestampedCertificateEntryDataV2" structure. The "TransItem" can "TimestampedCertificateEntryDataV2" structure. The "TransItem" can
be reconstructed from these fields and the entire chain that the log be reconstructed from these fields and the entire chain that the log
used to verify the submission. used to verify the submission.
4.4. Log ID 4.4. Log ID
Each log is identified by an OID, which is one of the log's Each log is identified by an OID, which is one of the log's
parameters (see Section 4.1) and which MUST NOT be used to identify parameters (see Section 4.1) and which MUST NOT be used to identify
any other log. A log's operator MUST either allocate the OID any other log. A log's operator MUST either allocate the OID
themselves or request an OID from the Log ID Registry (see themselves or request an OID from the Log ID Registry (see
Section 10.7.1). Various data structures include the DER encoding of Section 10.6.1). Various data structures include the DER encoding of
this OID, excluding the ASN.1 tag and length bytes, in an opaque this OID, excluding the ASN.1 tag and length bytes, in an opaque
vector: vector:
opaque LogID<2..127>; opaque LogID<2..127>;
Note that the ASN.1 length and the opaque vector length are identical Note that the ASN.1 length and the opaque vector length are identical
in size (1 byte) and value, so the DER encoding of the OID can be in size (1 byte) and value, so the DER encoding of the OID can be
reproduced simply by prepending an OBJECT IDENTIFIER tag (0x06) to reproduced simply by prepending an OBJECT IDENTIFIER tag (0x06) to
the opaque vector length and contents. the opaque vector length and contents.
skipping to change at page 19, line 33 skipping to change at page 20, line 27
case x509_entry_v2: TimestampedCertificateEntryDataV2; case x509_entry_v2: TimestampedCertificateEntryDataV2;
case precert_entry_v2: TimestampedCertificateEntryDataV2; case precert_entry_v2: TimestampedCertificateEntryDataV2;
case x509_sct_v2: SignedCertificateTimestampDataV2; case x509_sct_v2: SignedCertificateTimestampDataV2;
case precert_sct_v2: SignedCertificateTimestampDataV2; case precert_sct_v2: SignedCertificateTimestampDataV2;
case signed_tree_head_v2: SignedTreeHeadDataV2; case signed_tree_head_v2: SignedTreeHeadDataV2;
case consistency_proof_v2: ConsistencyProofDataV2; case consistency_proof_v2: ConsistencyProofDataV2;
case inclusion_proof_v2: InclusionProofDataV2; case inclusion_proof_v2: InclusionProofDataV2;
} data; } data;
} TransItem; } TransItem;
"versioned_type" is a value from the IANA registry in Section 10.5 "versioned_type" is a value from the IANA registry in Section 10.4
that identifies the type of the encapsulated data structure and the that identifies the type of the encapsulated data structure and the
earliest version of this protocol to which it conforms. This earliest version of this protocol to which it conforms. This
document is v2. document is v2.
"data" is the encapsulated data structure. The various structures "data" is the encapsulated data structure. The various structures
named with the "DataV2" suffix are defined in later sections of this named with the "DataV2" suffix are defined in later sections of this
document. document.
Note that "VersionedTransType" combines the v1 [RFC6962] type Note that "VersionedTransType" combines the v1 [RFC6962] type
enumerations "Version", "LogEntryType", "SignatureType" and enumerations "Version", "LogEntryType", "SignatureType" and
skipping to change at page 20, line 23 skipping to change at page 21, line 20
opaque extension_data<0..2^16-1>; opaque extension_data<0..2^16-1>;
} Extension; } Extension;
The "Extension" structure provides a generic extensibility for log The "Extension" structure provides a generic extensibility for log
artifacts, including Signed Certificate Timestamps (Section 4.8) and artifacts, including Signed Certificate Timestamps (Section 4.8) and
Signed Tree Heads (Section 4.10). The interpretation of the Signed Tree Heads (Section 4.10). The interpretation of the
"extension_data" field is determined solely by the value of the "extension_data" field is determined solely by the value of the
"extension_type" field. "extension_type" field.
This document does not define any extensions, but it does establish a This document does not define any extensions, but it does establish a
registry for future "ExtensionType" values (see Section 10.6). Each registry for future "ExtensionType" values (see Section 10.5). Each
document that registers a new "ExtensionType" must specify the document that registers a new "ExtensionType" must specify the
context in which it may be used (e.g., SCT, STH, or both) and context in which it may be used (e.g., SCT, STH, or both) and
describe how to interpret the corresponding "extension_data". describe how to interpret the corresponding "extension_data".
4.7. Merkle Tree Leaves 4.7. Merkle Tree Leaves
The leaves of a log's Merkle Tree correspond to the log's entries The leaves of a log's Merkle Tree correspond to the log's entries
(see Section 4.3). Each leaf is the leaf hash (Section 2.1) of a (see Section 4.3). Each leaf is the leaf hash (Section 2.1) of a
"TransItem" structure of type "x509_entry_v2" or "precert_entry_v2", "TransItem" structure of type "x509_entry_v2" or "precert_entry_v2",
which encapsulates a "TimestampedCertificateEntryDataV2" structure. which encapsulates a "TimestampedCertificateEntryDataV2" structure.
skipping to change at page 36, line 27 skipping to change at page 37, line 27
the serialized "TransItem" structure. This encoding ensures that TLS the serialized "TransItem" structure. This encoding ensures that TLS
clients can decode each "TransItem" individually (so, for example, if clients can decode each "TransItem" individually (so, for example, if
there is a version upgrade, out-of-date clients can still parse old there is a version upgrade, out-of-date clients can still parse old
"TransItem" structures while skipping over new "TransItem" structures "TransItem" structures while skipping over new "TransItem" structures
whose versions they don't understand). whose versions they don't understand).
6.3. Presenting SCTs, inclusions proofs and STHs 6.3. Presenting SCTs, inclusions proofs and STHs
In each "TransItemList" that is sent to a client during a TLS In each "TransItemList" that is sent to a client during a TLS
handshake, the TLS server MUST include a "TransItem" structure of handshake, the TLS server MUST include a "TransItem" structure of
type "x509_sct_v2" or "precert_sct_v2" (except as described in type "x509_sct_v2" or "precert_sct_v2".
Section 6.5).
Presenting inclusion proofs and STHs in the TLS handshake helps to Presenting inclusion proofs and STHs in the TLS handshake helps to
protect the client's privacy (see Section 8.1.4) and reduces load on protect the client's privacy (see Section 8.1.4) and reduces load on
log servers. Therefore, if the TLS server can obtain them, it SHOULD log servers. Therefore, if the TLS server can obtain them, it SHOULD
also include "TransItem"s of type "inclusion_proof_v2" and also include "TransItem"s of type "inclusion_proof_v2" and
"signed_tree_head_v2" in the "TransItemList". "signed_tree_head_v2" in the "TransItemList".
6.4. transparency_info TLS Extension 6.4. transparency_info TLS Extension
Provided that a TLS client includes the "transparency_info" extension Provided that a TLS client includes the "transparency_info" extension
skipping to change at page 37, line 16 skipping to change at page 38, line 16
messages: messages:
o the ServerHello message (for TLS 1.2 or earlier). o the ServerHello message (for TLS 1.2 or earlier).
o the Certificate or CertificateRequest message (for TLS 1.3). o the Certificate or CertificateRequest message (for TLS 1.3).
TLS servers MUST NOT process or include this extension when a TLS TLS servers MUST NOT process or include this extension when a TLS
session is resumed, since session resumption uses the original session is resumed, since session resumption uses the original
session information. session information.
6.5. cached_info TLS Extension
When a TLS server includes the "transparency_info" extension, it
SHOULD NOT include any "TransItem" structures of type "x509_sct_v2"
or "precert_sct_v2" in the "TransItemList" if all of the following
conditions are met:
o The TLS client includes the "cached_info" ([RFC7924]) extension
type in the ClientHello, with a "CachedObject" of type
"ct_compliant" (see Section 8.1.7) and at least one "CachedObject"
of type "cert".
o The TLS server sends a modified Certificate message (as described
in section 4.1 of [RFC7924]).
If the "hash_value" of any "CachedObject" of type "ct_compliant" sent
by a TLS client is not 1 byte long with the value 0, the CT-using TLS
server MUST abort the handshake.
7. Certification Authorities 7. Certification Authorities
7.1. Transparency Information X.509v3 Extension 7.1. Transparency Information X.509v3 Extension
The Transparency Information X.509v3 extension, which has OID The Transparency Information X.509v3 extension, which has OID
1.3.101.75 and SHOULD be non-critical, contains one or more 1.3.101.75 and SHOULD be non-critical, contains one or more
"TransItem" structures in a "TransItemList". This extension MAY be "TransItem" structures in a "TransItemList". This extension MAY be
included in OCSP responses (see Section 7.1.1) and certificates (see included in OCSP responses (see Section 7.1.1) and certificates (see
Section 7.1.2). Since RFC5280 requires the "extnValue" field (an Section 7.1.2). Since RFC5280 requires the "extnValue" field (an
OCTET STRING) of each X.509v3 extension to include the DER encoding OCTET STRING) of each X.509v3 extension to include the DER encoding
skipping to change at page 39, line 26 skipping to change at page 40, line 11
TBSCertificate component of the certificate as follows: TBSCertificate component of the certificate as follows:
o Remove the Transparency Information extension (see Section 7.1). o Remove the Transparency Information extension (see Section 7.1).
o Remove embedded v1 SCTs, identified by OID 1.3.6.1.4.1.11129.2.4.2 o Remove embedded v1 SCTs, identified by OID 1.3.6.1.4.1.11129.2.4.2
(see section 3.3 of [RFC6962]). This allows embedded v1 and v2 (see section 3.3 of [RFC6962]). This allows embedded v1 and v2
SCTs to co-exist in a certificate (see Appendix A). SCTs to co-exist in a certificate (see Appendix A).
8.1.3. Validating SCTs 8.1.3. Validating SCTs
In addition to normal validation of the server certificate and its In order to make use of a received SCT, the TLS client MUST first
chain, CT-using TLS clients MUST validate each received SCT for which validate it as follows:
they have the corresponding log's parameters. To validate an SCT, a
TLS client computes 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:
o "timestamp" is copied from the SCT. o 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:
o "tbs_certificate" is the reconstructed TBSCertificate portion of * "timestamp" is copied from the SCT.
the server certificate, as described in Section 8.1.2.
o "issuer_key_hash" is computed as described in Section 4.7. * "tbs_certificate" is the reconstructed TBSCertificate portion
of the server certificate, as described in Section 8.1.2.
o "sct_extensions" is copied from the SCT. * "issuer_key_hash" is computed as described in Section 4.7.
The SCT's "signature" is then verified using the public key of the * "sct_extensions" is copied from the SCT.
corresponding log, which is identified by the "log_id". The required
signature algorithm is one of the log's parameters. o 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.
If the TLS client does not have the corresponding log's parameters,
it cannot attempt to validate the SCT. When evaluating compliance
(see Section 8.1.6), the TLS client will consider only those SCTs
that it was able to validate.
Note that SCT validation is not a substitute for the normal
validation of the server certificate and its chain.
8.1.4. Fetching inclusion proofs 8.1.4. Fetching inclusion proofs
When a TLS client has validated a received SCT but does not yet When a TLS client has validated a received SCT but does not yet
possess a corresponding inclusion proof, the TLS client MAY request possess a corresponding inclusion proof, the TLS client MAY request
the inclusion proof directly from a log using "get-proof-by-hash" the inclusion proof directly from a log using "get-proof-by-hash"
(Section 5.4) or "get-all-by-hash" (Section 5.5). (Section 5.4) or "get-all-by-hash" (Section 5.5).
Note that fetching inclusion proofs directly from a log will disclose Note that fetching inclusion proofs directly from a log will disclose
to the log which TLS server the client has been communicating with. to the log which TLS server the client has been communicating with.
skipping to change at page 40, line 40 skipping to change at page 41, line 32
achieve compliance and how to handle non-compliance. achieve compliance and how to handle non-compliance.
A TLS client can only evaluate compliance if it has given the TLS A TLS client can only evaluate compliance if it has given the TLS
server the opportunity to send SCTs and inclusion proofs by any of server the opportunity to send SCTs and inclusion proofs by any of
the three mechanisms that are mandatory to implement for CT-using TLS the three mechanisms that are mandatory to implement for CT-using TLS
clients (see Section 8.1.1). Therefore, a TLS client MUST NOT clients (see Section 8.1.1). Therefore, a TLS client MUST NOT
evaluate compliance if it did not include both the evaluate compliance if it did not include both the
"transparency_info" and "status_request" TLS extensions in the "transparency_info" and "status_request" TLS extensions in the
ClientHello. ClientHello.
8.1.7. cached_info TLS Extension
If a TLS client uses the "cached_info" TLS extension ([RFC7924]) to
indicate 1 or more cached certificates, all of which it already
considers to be CT compliant, the TLS client MAY also include a
"CachedObject" of type "ct_compliant" in the "cached_info" extension.
Its "hash_value" field MUST have the value 0 and be 1 byte long (the
minimum length permitted by [RFC7924]).
8.2. Monitor 8.2. Monitor
Monitors watch logs to check that they behave correctly, for Monitors watch logs to check that they behave correctly, for
certificates of interest, or both. For example, a monitor may be certificates of interest, or both. For example, a monitor may be
configured to report on all certificates that apply to a specific configured to report on all certificates that apply to a specific
domain name when fetching new entries for consistency validation. domain name when fetching new entries for consistency validation.
A monitor MUST at least inspect every new entry in every log it A monitor MUST at least inspect every new entry in every log it
watches, and it MAY also choose to keep copies of entire logs. watches, and it MAY also choose to keep copies of entire logs.
skipping to change at page 43, line 47 skipping to change at page 44, line 28
The assignment policy criteria mentioned in this section refer to the The assignment policy criteria mentioned in this section refer to the
policies outlined in [RFC8126]. policies outlined in [RFC8126].
10.1. New Entry to the TLS ExtensionType Registry 10.1. New Entry to the TLS ExtensionType Registry
IANA is asked to add an entry for "transparency_info(TBD)" to the IANA is asked to add an entry for "transparency_info(TBD)" to the
"TLS ExtensionType Values" registry defined in [RFC8446], setting the "TLS ExtensionType Values" registry defined in [RFC8446], setting the
"Recommended" value to "Y", setting the "TLS 1.3" value to "CH, CR, "Recommended" value to "Y", setting the "TLS 1.3" value to "CH, CR,
CT", and citing this document as the "Reference". CT", and citing this document as the "Reference".
10.2. New Entry to the TLS CachedInformationType registry 10.2. Hash Algorithms
IANA is asked to add an entry for "ct_compliant(TBD)" to the "TLS
CachedInformationType Values" registry defined in [RFC7924], citing
this document as the "Reference".
10.3. Hash Algorithms
IANA is asked to establish a registry of hash algorithm values, named IANA is asked to establish a registry of hash algorithm values, named
"CT Hash Algorithms", that initially consists of: "CT Hash Algorithms", that initially consists of:
+--------+------------+------------------------+--------------------+ +--------+------------+------------------------+--------------------+
| Value | Hash | OID | Reference / | | Value | Hash | OID | Reference / |
| | Algorithm | | Assignment Policy | | | Algorithm | | Assignment Policy |
+--------+------------+------------------------+--------------------+ +--------+------------+------------------------+--------------------+
| 0x00 | SHA-256 | 2.16.840.1.101.3.4.2.1 | [RFC6234] | | 0x00 | SHA-256 | 2.16.840.1.101.3.4.2.1 | [RFC6234] |
| | | | | | | | | |
skipping to change at page 44, line 27 skipping to change at page 45, line 5
| 0xDF | | | Required and | | 0xDF | | | Required and |
| | | | Expert Review | | | | | Expert Review |
| | | | | | | | | |
| 0xE0 - | Reserved | | Experimental Use | | 0xE0 - | Reserved | | Experimental Use |
| 0xEF | | | | | 0xEF | | | |
| | | | | | | | | |
| 0xF0 - | Reserved | | Private Use | | 0xF0 - | Reserved | | Private Use |
| 0xFF | | | | | 0xFF | | | |
+--------+------------+------------------------+--------------------+ +--------+------------+------------------------+--------------------+
10.3.1. Expert Review guidelines 10.2.1. Expert Review guidelines
The appointed Expert should ensure that the proposed algorithm has a The appointed Expert should ensure that the proposed algorithm has a
public specification and is suitable for use as a cryptographic hash public specification and is suitable for use as a cryptographic hash
algorithm with no known preimage or collision attacks. These attacks algorithm with no known preimage or collision attacks. These attacks
can damage the integrity of the log. can damage the integrity of the log.
10.4. Signature Algorithms 10.3. Signature Algorithms
IANA is asked to establish a registry of signature algorithm values, IANA is asked to establish a registry of signature algorithm values,
named "CT Signature Algorithms", that initially consists of: named "CT Signature Algorithms", that initially consists of:
+--------------------------------+--------------------+-------------+ +--------------------------------+--------------------+-------------+
| SignatureScheme Value | Signature | Reference / | | SignatureScheme Value | Signature | Reference / |
| | Algorithm | Assignment | | | Algorithm | Assignment |
| | | Policy | | | | Policy |
+--------------------------------+--------------------+-------------+ +--------------------------------+--------------------+-------------+
| ecdsa_secp256r1_sha256(0x0403) | ECDSA (NIST P-256) | [FIPS186-4] | | ecdsa_secp256r1_sha256(0x0403) | ECDSA (NIST P-256) | [FIPS186-4] |
skipping to change at page 45, line 25 skipping to change at page 45, line 37
| | with HMAC-SHA256 | | | | with HMAC-SHA256 | |
| | | | | | | |
| ed25519(0x0807) | Ed25519 (PureEdDSA | [RFC8032] | | ed25519(0x0807) | Ed25519 (PureEdDSA | [RFC8032] |
| | with the | | | | with the | |
| | edwards25519 | | | | edwards25519 | |
| | curve) | | | | curve) | |
| | | | | | | |
| private_use(0xFE00..0xFFFF) | Reserved | Private Use | | private_use(0xFE00..0xFFFF) | Reserved | Private Use |
+--------------------------------+--------------------+-------------+ +--------------------------------+--------------------+-------------+
10.4.1. Expert Review guidelines 10.3.1. Expert Review guidelines
The appointed Expert should ensure that the proposed algorithm has a The appointed Expert should ensure that the proposed algorithm has a
public specification, has a value assigned to it in the TLS public specification, has a value assigned to it in the TLS
SignatureScheme Registry (that IANA is asked to establish in SignatureScheme Registry (that IANA is asked to establish in
[RFC8446]) and is suitable for use as a cryptographic signature [RFC8446]) and is suitable for use as a cryptographic signature
algorithm. algorithm.
10.5. VersionedTransTypes 10.4. VersionedTransTypes
IANA is asked to establish a registry of "VersionedTransType" values, IANA is asked to establish a registry of "VersionedTransType" values,
named "CT VersionedTransTypes", that initially consists of: named "CT VersionedTransTypes", that initially consists of:
+-------------+----------------------+------------------------------+ +-------------+----------------------+------------------------------+
| Value | Type and Version | Reference / Assignment | | Value | Type and Version | Reference / Assignment |
| | | Policy | | | | Policy |
+-------------+----------------------+------------------------------+ +-------------+----------------------+------------------------------+
| 0x0000 | Reserved | [RFC6962] (*) | | 0x0000 | Reserved | [RFC6962] (*) |
| | | | | | | |
skipping to change at page 46, line 41 skipping to change at page 46, line 41
| 0xF000 - | Reserved | Private Use | | 0xF000 - | Reserved | Private Use |
| 0xFFFF | | | | 0xFFFF | | |
+-------------+----------------------+------------------------------+ +-------------+----------------------+------------------------------+
(*) The 0x0000 value is reserved so that v1 SCTs are distinguishable (*) The 0x0000 value is reserved so that v1 SCTs are distinguishable
from v2 SCTs and other "TransItem" structures. from v2 SCTs and other "TransItem" structures.
[RFC Editor: please update 'RFCXXXX' to refer to this document, once [RFC Editor: please update 'RFCXXXX' to refer to this document, once
its RFC number is known.] its RFC number is known.]
10.5.1. Expert Review guidelines 10.4.1. Expert Review guidelines
The appointed Expert should review the public specification to ensure The appointed Expert should review the public specification to ensure
that it is detailed enough to ensure implementation interoperability. that it is detailed enough to ensure implementation interoperability.
10.6. Log Artifact Extension Registry 10.5. Log Artifact Extension Registry
IANA is asked to establish a registry of "ExtensionType" values, IANA is asked to establish a registry of "ExtensionType" values,
named "CT Log Artifact Extensions", that initially consists of: named "CT Log Artifact Extensions", that initially consists of:
+---------------+------------+-----+--------------------------------+ +---------------+------------+-----+--------------------------------+
| ExtensionType | Status | Use | Reference / Assignment Policy | | ExtensionType | Status | Use | Reference / Assignment Policy |
+---------------+------------+-----+--------------------------------+ +---------------+------------+-----+--------------------------------+
| 0x0000 - | Unassigned | n/a | Specification Required and | | 0x0000 - | Unassigned | n/a | Specification Required and |
| 0xDFFF | | | Expert Review | | 0xDFFF | | | Expert Review |
| | | | | | | | | |
skipping to change at page 47, line 25 skipping to change at page 47, line 25
| 0xFFFF | | | | | 0xFFFF | | | |
+---------------+------------+-----+--------------------------------+ +---------------+------------+-----+--------------------------------+
The "Use" column should contain one or both of the following values: The "Use" column should contain one or both of the following values:
o "SCT", for extensions specified for use in Signed Certificate o "SCT", for extensions specified for use in Signed Certificate
Timestamps. Timestamps.
o "STH", for extensions specified for use in Signed Tree Heads. o "STH", for extensions specified for use in Signed Tree Heads.
10.6.1. Expert Review guidelines 10.5.1. Expert Review guidelines
The appointed Expert should review the public specification to ensure The appointed Expert should review the public specification to ensure
that it is detailed enough to ensure implementation interoperability. that it is detailed enough to ensure implementation interoperability.
The Expert should also verify that the extension is appropriate to The Expert should also verify that the extension is appropriate to
the contexts in which it is specified to be used (SCT, STH, or both). the contexts in which it is specified to be used (SCT, STH, or both).
10.7. Object Identifiers 10.6. Object Identifiers
This document uses object identifiers (OIDs) to identify Log IDs (see This document uses object identifiers (OIDs) to identify Log IDs (see
Section 4.4), the precertificate CMS "eContentType" (see Section 4.4), the precertificate CMS "eContentType" (see
Section 3.2), and X.509v3 extensions in certificates (see Section 3.2), and X.509v3 extensions in certificates (see
Section 7.1.2) and OCSP responses (see Section 7.1.1). The OIDs are Section 7.1.2) and OCSP responses (see Section 7.1.1). The OIDs are
defined in an arc that was selected due to its short encoding. defined in an arc that was selected due to its short encoding.
10.7.1. Log ID Registry 10.6.1. Log ID Registry
IANA is asked to establish a registry of Log IDs, named "CT Log ID IANA is asked to establish a registry of Log IDs, named "CT Log ID
Registry", that initially consists of: Registry", that initially consists of:
+---------------------+------------+--------------------------------+ +---------------------+------------+--------------------------------+
| Value | Log | Reference / Assignment Policy | | Value | Log | Reference / Assignment Policy |
+---------------------+------------+--------------------------------+ +---------------------+------------+--------------------------------+
| 1.3.101.8192 - | Unassigned | Parameters Required and First | | 1.3.101.8192 - | Unassigned | Parameters Required and First |
| 1.3.101.16383 | | Come First Served | | 1.3.101.16383 | | Come First Served |
| | | | | | | |
skipping to change at page 51, line 48 skipping to change at page 51, line 48
<https://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS) [RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS)
Feature Extension", RFC 7633, DOI 10.17487/RFC7633, Feature Extension", RFC 7633, DOI 10.17487/RFC7633,
October 2015, <https://www.rfc-editor.org/info/rfc7633>. October 2015, <https://www.rfc-editor.org/info/rfc7633>.
[RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP [RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP
APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016, APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016,
<https://www.rfc-editor.org/info/rfc7807>. <https://www.rfc-editor.org/info/rfc7807>.
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension", RFC 7924,
DOI 10.17487/RFC7924, July 2016,
<https://www.rfc-editor.org/info/rfc7924>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>. <https://www.rfc-editor.org/info/rfc8032>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
 End of changes. 48 change blocks. 
156 lines changed or deleted 146 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/