draft-ietf-trans-rfc6962-bis-16.txt   draft-ietf-trans-rfc6962-bis-17.txt 
Public Notary Transparency Working Group B. Laurie Public Notary Transparency Working Group B. Laurie
Internet-Draft A. Langley Internet-Draft A. Langley
Intended status: Standards Track E. Kasper Intended status: Standards Track E. Kasper
Expires: November 28, 2016 E. Messeri Expires: January 22, 2017 E. Messeri
Google Google
R. Stradling R. Stradling
Comodo Comodo
May 27, 2016 July 21, 2016
Certificate Transparency Certificate Transparency
draft-ietf-trans-rfc6962-bis-16 draft-ietf-trans-rfc6962-bis-17
Abstract Abstract
This document describes a protocol for publicly logging the existence This document describes a protocol for publicly logging the existence
of Transport Layer Security (TLS) certificates as they are issued or of Transport Layer Security (TLS) certificates as they are issued or
observed, in a manner that allows anyone to audit certification observed, in a manner that allows anyone to audit certification
authority (CA) activity and notice the issuance of suspect authority (CA) activity and notice the issuance of suspect
certificates as well as to audit the certificate logs themselves. certificates as well as to audit the certificate logs themselves.
The intent is that eventually clients would refuse to honor The intent is that eventually clients would refuse to honor
certificates that do not appear in a log, effectively forcing CAs to certificates that do not appear in a log, effectively forcing CAs to
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 November 28, 2016. This Internet-Draft will expire on January 22, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
skipping to change at page 2, line 31 skipping to change at page 2, line 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 5 1.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 5
2. Cryptographic Components . . . . . . . . . . . . . . . . . . 5 2. Cryptographic Components . . . . . . . . . . . . . . . . . . 5
2.1. Merkle Hash Trees . . . . . . . . . . . . . . . . . . . . 5 2.1. Merkle Hash Trees . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Merkle Inclusion Proofs . . . . . . . . . . . . . . . 6 2.1.1. Merkle Inclusion Proofs . . . . . . . . . . . . . . . 6
2.1.2. Merkle Consistency Proofs . . . . . . . . . . . . . . 7 2.1.2. Merkle Consistency Proofs . . . . . . . . . . . . . . 7
2.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.4. Signatures . . . . . . . . . . . . . . . . . . . . . 10 2.1.4. Signatures . . . . . . . . . . . . . . . . . . . . . 10
3. Submitters . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Submitters . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Certificates . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Certificates . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Precertificates . . . . . . . . . . . . . . . . . . . . . 10 3.2. Precertificates . . . . . . . . . . . . . . . . . . . . . 11
4. Private Domain Name Labels . . . . . . . . . . . . . . . . . 11 4. Private Domain Name Labels . . . . . . . . . . . . . . . . . 12
4.1. Wildcard Certificates . . . . . . . . . . . . . . . . . . 11 4.1. Wildcard Certificates . . . . . . . . . . . . . . . . . . 12
4.2. Redaction of Domain Name Labels . . . . . . . . . . . . . 12 4.2. Redaction of Domain Name Labels . . . . . . . . . . . . . 13
4.2.1. Redacting Labels in Precertificates . . . . . . . . . 12 4.2.1. Redacting Labels in Precertificates . . . . . . . . . 13
4.2.2. Redacted Labels Certificate Extension . . . . . . . . 12 4.2.2. redactedSubjectAltName Certificate Extension . . . . 13
4.3. Using a Name-Constrained Intermediate CA . . . . . . . . 12 4.3. Using a Name-Constrained Intermediate CA . . . . . . . . 14
5. Log Format and Operation . . . . . . . . . . . . . . . . . . 13 5. Log Format and Operation . . . . . . . . . . . . . . . . . . 15
5.1. Accepting Submissions . . . . . . . . . . . . . . . . . . 14 5.1. Accepting Submissions . . . . . . . . . . . . . . . . . . 15
5.2. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 16
5.3. Log ID . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.3. Log ID . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.4. TransItem Structure . . . . . . . . . . . . . . . . . . . 16 5.4. TransItem Structure . . . . . . . . . . . . . . . . . . . 17
5.5. Merkle Tree Leaves . . . . . . . . . . . . . . . . . . . 17 5.5. Merkle Tree Leaves . . . . . . . . . . . . . . . . . . . 19
5.6. Signed Certificate Timestamp (SCT) . . . . . . . . . . . 18 5.6. Signed Certificate Timestamp (SCT) . . . . . . . . . . . 19
5.7. Merkle Tree Head . . . . . . . . . . . . . . . . . . . . 19 5.7. Merkle Tree Head . . . . . . . . . . . . . . . . . . . . 21
5.8. Signed Tree Head (STH) . . . . . . . . . . . . . . . . . 19 5.8. Signed Tree Head (STH) . . . . . . . . . . . . . . . . . 21
5.9. Merkle Consistency Proofs . . . . . . . . . . . . . . . . 21 5.9. Merkle Consistency Proofs . . . . . . . . . . . . . . . . 23
5.10. Merkle Inclusion Proofs . . . . . . . . . . . . . . . . . 21 5.10. Merkle Inclusion Proofs . . . . . . . . . . . . . . . . . 23
5.11. Shutting down a log . . . . . . . . . . . . . . . . . . . 22 5.11. Shutting down a log . . . . . . . . . . . . . . . . . . . 24
6. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 22 6. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 24
6.1. Add Chain to Log . . . . . . . . . . . . . . . . . . . . 24 6.1. Add Chain to Log . . . . . . . . . . . . . . . . . . . . 26
6.2. Add PreCertChain to Log . . . . . . . . . . . . . . . . . 25 6.2. Add PreCertChain to Log . . . . . . . . . . . . . . . . . 27
6.3. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 25 6.3. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 27
6.4. Retrieve Merkle Consistency Proof between Two Signed Tree 6.4. Retrieve Merkle Consistency Proof between Two Signed Tree
Heads . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Heads . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.5. Retrieve Merkle Inclusion Proof from Log by Leaf Hash . . 26 6.5. Retrieve Merkle Inclusion Proof from Log by Leaf Hash . . 28
6.6. Retrieve Merkle Inclusion Proof, Signed Tree Head and 6.6. Retrieve Merkle Inclusion Proof, Signed Tree Head and
Consistency Proof by Leaf Hash . . . . . . . . . . . . . 27 Consistency Proof by Leaf Hash . . . . . . . . . . . . . 29
6.7. Retrieve Entries and STH from Log . . . . . . . . . . . . 28 6.7. Retrieve Entries and STH from Log . . . . . . . . . . . . 30
6.8. Retrieve Accepted Trust Anchors . . . . . . . . . . . . . 30 6.8. Retrieve Accepted Trust Anchors . . . . . . . . . . . . . 32
7. Optional Client Messages . . . . . . . . . . . . . . . . . . 30 7. Optional Client Messages . . . . . . . . . . . . . . . . . . 32
7.1. Get Entry Number for SCT . . . . . . . . . . . . . . . . 30 7.1. Get Entry Number for SCT . . . . . . . . . . . . . . . . 32
7.2. Get Entry Numbers for Certificate . . . . . . . . . . . . 31 7.2. Get Entry Numbers for Certificate . . . . . . . . . . . . 33
8. TLS Servers . . . . . . . . . . . . . . . . . . . . . . . . . 31 8. TLS Servers . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . . 32 8.1. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . . 34
8.2. TransItemList Structure . . . . . . . . . . . . . . . . . 33 8.2. TransItemList Structure . . . . . . . . . . . . . . . . . 35
8.3. Presenting SCTs, inclusion proofs and STHs . . . . . . . 33 8.3. Presenting SCTs, inclusion proofs and STHs . . . . . . . 35
8.4. Presenting SCTs only . . . . . . . . . . . . . . . . . . 34 8.4. Presenting SCTs only . . . . . . . . . . . . . . . . . . 36
8.5. transparency_info TLS Extension . . . . . . . . . . . . . 34 8.5. transparency_info TLS Extension . . . . . . . . . . . . . 36
9. Certification Authorities . . . . . . . . . . . . . . . . . . 34 9. Certification Authorities . . . . . . . . . . . . . . . . . . 36
9.1. Transparency Information X.509v3 Extension . . . . . . . 34 9.1. Transparency Information X.509v3 Extension . . . . . . . 36
9.1.1. OCSP Response Extension . . . . . . . . . . . . . . . 34 9.1.1. OCSP Response Extension . . . . . . . . . . . . . . . 36
9.1.2. Certificate Extension . . . . . . . . . . . . . . . . 35 9.1.2. Certificate Extension . . . . . . . . . . . . . . . . 37
9.2. TLS Feature Extension . . . . . . . . . . . . . . . . . . 35 9.2. TLS Feature Extension . . . . . . . . . . . . . . . . . . 37
10. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 10. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.1. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 35 10.1. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 37
10.2. TLS Client . . . . . . . . . . . . . . . . . . . . . . . 36 10.2. TLS Client . . . . . . . . . . . . . . . . . . . . . . . 38
10.2.1. Receiving SCTs . . . . . . . . . . . . . . . . . . . 36 10.2.1. Receiving SCTs . . . . . . . . . . . . . . . . . . . 38
10.2.2. Reconstructing the TBSCertificate . . . . . . . . . 36 10.2.2. Reconstructing the TBSCertificate . . . . . . . . . 38
10.2.3. Validating SCTs . . . . . . . . . . . . . . . . . . 37 10.2.3. Verifying the redactedSubjectAltName extension . . . 39
10.2.4. Validating inclusion proofs . . . . . . . . . . . . 37 10.2.4. Validating SCTs . . . . . . . . . . . . . . . . . . 39
10.2.5. Evaluating compliance . . . . . . . . . . . . . . . 38 10.2.5. Validating inclusion proofs . . . . . . . . . . . . 40
10.2.6. TLS Feature Extension . . . . . . . . . . . . . . . 38 10.2.6. Evaluating compliance . . . . . . . . . . . . . . . 40
10.2.7. Handling of Non-compliance . . . . . . . . . . . . . 38 10.2.7. TLS Feature Extension . . . . . . . . . . . . . . . 40
10.3. Monitor . . . . . . . . . . . . . . . . . . . . . . . . 38 10.2.8. Handling of Non-compliance . . . . . . . . . . . . . 41
10.4. Auditing . . . . . . . . . . . . . . . . . . . . . . . . 39 10.3. Monitor . . . . . . . . . . . . . . . . . . . . . . . . 41
10.4.1. Verifying an inclusion proof . . . . . . . . . . . . 40 10.4. Auditing . . . . . . . . . . . . . . . . . . . . . . . . 42
10.4.2. Verifying consistency between two STHs . . . . . . . 41 10.4.1. Verifying an inclusion proof . . . . . . . . . . . . 43
10.4.3. Verifying root hash given entries . . . . . . . . . 42 10.4.2. Verifying consistency between two STHs . . . . . . . 43
11. Algorithm Agility . . . . . . . . . . . . . . . . . . . . . . 43 10.4.3. Verifying root hash given entries . . . . . . . . . 44
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 11. Algorithm Agility . . . . . . . . . . . . . . . . . . . . . . 45
12.1. TLS Extension Type . . . . . . . . . . . . . . . . . . . 43 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
12.2. Hash Algorithms . . . . . . . . . . . . . . . . . . . . 43 12.1. TLS Extension Type . . . . . . . . . . . . . . . . . . . 46
12.3. Signature Algorithms . . . . . . . . . . . . . . . . . . 43 12.2. Hash Algorithms . . . . . . . . . . . . . . . . . . . . 46
12.4. SCT Extensions . . . . . . . . . . . . . . . . . . . . . 44 12.3. Signature Algorithms . . . . . . . . . . . . . . . . . . 46
12.5. STH Extensions . . . . . . . . . . . . . . . . . . . . . 44 12.4. SCT Extensions . . . . . . . . . . . . . . . . . . . . . 46
12.6. Object Identifiers . . . . . . . . . . . . . . . . . . . 44 12.5. STH Extensions . . . . . . . . . . . . . . . . . . . . . 47
12.6.1. Log ID Registry 1 . . . . . . . . . . . . . . . . . 45 12.6. Object Identifiers . . . . . . . . . . . . . . . . . . . 47
12.6.2. Log ID Registry 2 . . . . . . . . . . . . . . . . . 45 12.6.1. Log ID Registry 1 . . . . . . . . . . . . . . . . . 47
13. Security Considerations . . . . . . . . . . . . . . . . . . . 45 12.6.2. Log ID Registry 2 . . . . . . . . . . . . . . . . . 47
13.1. Misissued Certificates . . . . . . . . . . . . . . . . . 45 13. Security Considerations . . . . . . . . . . . . . . . . . . . 48
13.2. Detection of Misissue . . . . . . . . . . . . . . . . . 46 13.1. Misissued Certificates . . . . . . . . . . . . . . . . . 48
13.3. Avoiding Overly Redacting Domain Name Labels . . . . . . 46 13.2. Detection of Misissue . . . . . . . . . . . . . . . . . 48
13.4. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 46 13.3. Avoiding Overly Redacting Domain Name Labels . . . . . . 48
13.5. Deterministic Signatures . . . . . . . . . . . . . . . . 47 13.4. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 49
13.6. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . 47 13.5. Deterministic Signatures . . . . . . . . . . . . . . . . 49
13.7. Threat Analysis . . . . . . . . . . . . . . . . . . . . 47 13.6. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . 50
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 50
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 14.1. Ensuring Effective Redaction . . . . . . . . . . . . . . 50
15.1. Normative References . . . . . . . . . . . . . . . . . . 48 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50
15.2. Informative References . . . . . . . . . . . . . . . . . 49 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
Appendix A. Supporting v1 and v2 simultaneously . . . . . . . . 51 16.1. Normative References . . . . . . . . . . . . . . . . . . 51
16.2. Informative References . . . . . . . . . . . . . . . . . 52
Appendix A. Supporting v1 and v2 simultaneously . . . . . . . . 54
1. Introduction 1. Introduction
Certificate transparency aims to mitigate the problem of misissued Certificate transparency aims to mitigate the problem of misissued
certificates by providing append-only logs of issued certificates. certificates by providing append-only logs of issued certificates.
The logs do not need to be trusted because they are publicly The logs do not need to be trusted because they are publicly
auditable. Anyone may verify the correctness of each log and monitor auditable. Anyone may verify the correctness of each log and monitor
when new certificates are added to it. The logs do not themselves when new certificates are added to it. The logs do not themselves
prevent misissue, but they ensure that interested parties prevent misissue, but they ensure that interested parties
(particularly those named in certificates) can detect such (particularly those named in certificates) can detect such
skipping to change at page 10, line 30 skipping to change at page 11, line 25
If a log accepts a submission, it will return a Signed Certificate If a log accepts a submission, it will return a Signed Certificate
Timestamp (SCT) (see Section 5.6). The submitter SHOULD validate the Timestamp (SCT) (see Section 5.6). The submitter SHOULD validate the
returned SCT as described in Section 10.2 if they understand its returned SCT as described in Section 10.2 if they understand its
format and they intend to use it directly in a TLS handshake or to format and they intend to use it directly in a TLS handshake or to
construct a certificate. If the submitter does not need the SCT (for construct a certificate. If the submitter does not need the SCT (for
example, the certificate is being submitted simply to make it example, the certificate is being submitted simply to make it
available in the log), it MAY validate the SCT. available in the log), it MAY validate the SCT.
3.1. Certificates 3.1. Certificates
Any entity can submit a certificate (Section 6.1) to a log. Since Any entity can submit a certificate (Section 6.1) to a log. Since it
certificates may not be accepted by TLS clients unless logged, it is is anticipated that TLS clients will reject certificates that are not
expected that certificate owners or their CAs will usually submit logged, it is expected that certificate issuers and subjects will be
them. strongly motivated to submit them.
3.2. Precertificates 3.2. Precertificates
Alternatively, (root as well as intermediate) CAs may preannounce a CAs may preannounce a certificate prior to issuance by submitting a
certificate prior to issuance by submitting a precertificate precertificate (Section 6.2) that the log can use to create an entry
(Section 6.2) that the log can use to create an entry that will be that will be valid against the issued certificate. The CA MAY
valid against the issued certificate. The CA MAY incorporate the incorporate the returned SCT in the issued certificate. Examples of
returned SCT in the issued certificate. Examples of situations where situations where the returned SCT is not incorporated into the issued
the returned SCT is not incorporated into the issued certificate certificate would be when a CA sends the precertificate to multiple
would be when a CA sends the precertificate to multiple logs, but logs, but only incorporates the SCTs that are returned first, or the
only incorporates the SCTs that are returned first, or the CA is CA is using domain name redaction (Section 4.2) and intends to use
using domain name redaction (Section 4.2) and intends to use another another mechanism to publish SCTs (such as an OCSP response
mechanism to publish SCTs (such as an OCSP response (Section 9.1.1) (Section 9.1.1) or the TLS extension (Section 8.5)).
or the TLS extension (Section 8.5)).
A precertificate is a CMS [RFC5652] "signed-data" object that A precertificate is a CMS [RFC5652] "signed-data" object that
conforms to the following requirements: conforms to the following requirements:
o It MUST be DER encoded. o It MUST be DER encoded.
o "SignedData.encapContentInfo.eContentType" MUST be the OID o "SignedData.encapContentInfo.eContentType" MUST be the OID
1.3.101.78. 1.3.101.78.
o "SignedData.encapContentInfo.eContent" MUST contain a o "SignedData.encapContentInfo.eContent" MUST contain a
TBSCertificate [RFC5280], which MAY redact certain domain name TBSCertificate [RFC5280] that will be identical to the
labels that will be present in the issued certificate (see TBSCertificate in the issued certificate, except that:
Section 4.2) and MUST NOT contain any SCTs, but which will be
otherwise identical to the TBSCertificate in the issued * the Transparency Information (Section 9.1) extension MUST be
certificate. omitted.
* the subjectAltName [RFC5280] extension MUST be omitted when the
CA is using domain name redaction (Section 4.2).
o "SignedData.signerInfos" MUST contain a signature from the same o "SignedData.signerInfos" MUST contain a signature from the same
(root or intermediate) CA that will ultimately issue the (root or intermediate) CA that will ultimately issue the
certificate. This signature indicates the CA's intent to issue certificate. This signature indicates the CA's intent to issue
the certificate. This intent is considered binding (i.e. the certificate. This intent is considered binding (i.e.
misissuance of the precertificate is considered equivalent to misissuance of the precertificate is considered equivalent to
misissuance of the certificate). (Note that, because of the misissuance of the certificate). (Note that, because of the
structure of CMS, the signature on the CMS object will not be a structure of CMS, the signature on the CMS object will not be a
valid X.509v3 signature and so cannot be used to construct a valid X.509v3 signature and so cannot be used to construct a
certificate from the precertificate). certificate from the precertificate).
o "SignedData.certificates" SHOULD be omitted. o "SignedData.certificates" SHOULD be omitted.
4. Private Domain Name Labels 4. Private Domain Name Labels
Some regard some DNS domain name labels within their registered Some regard certain DNS domain name labels within their registered
domain space as private and security sensitive. Even though these domain space as private and security sensitive. Even though these
domains are often only accessible within the domain owner's private domains are often only accessible within the domain owner's private
network, it's common for them to be secured using publicly trusted network, it's common for them to be secured using publicly trusted
TLS server certificates. We define a mechanism to allow these TLS server certificates. We define a mechanism (see Section 4.2) to
private labels to not appear in public logs. allow these private labels to not appear in public logs, while still
retaining most of the security benefits that accrue from using
Certificate Transparency mechanisms.
4.1. Wildcard Certificates 4.1. Wildcard Certificates
A certificate containing a DNS-ID [RFC6125] of "*.example.com" could A certificate containing a DNS-ID [RFC6125] of "*.example.com" could
be used to secure the domain "topsecret.example.com", without be used to secure the domain "topsecret.example.com", without
revealing the string "topsecret" publicly. revealing the string "topsecret" publicly.
Since TLS clients only match the wildcard character to the complete Since TLS clients only match the wildcard character to the complete
leftmost label of the DNS domain name (see Section 6.4.3 of leftmost label of the DNS domain name (see Section 6.4.3 of
[RFC6125]), a different approach is needed when more than one of the [RFC6125]), a different approach is needed when any label other than
leftmost labels in a DNS-ID are considered private (e.g. the leftmost label in a DNS-ID is considered private (e.g.
"top.secret.example.com"). Also, wildcard certificates are "top.secret.example.com"). Also, wildcard certificates are
prohibited in some cases, such as Extended Validation Certificates prohibited in some cases, such as Extended Validation Certificates
[EVSSLGuidelines]. [EVSSLGuidelines].
4.2. Redaction of Domain Name Labels 4.2. Redaction of Domain Name Labels
4.2.1. Redacting Labels in Precertificates 4.2.1. Redacting Labels in Precertificates
When creating a precertificate, the CA MAY substitute one or more When creating a precertificate, the CA MAY omit the subjectAltName
labels in each DNS-ID and CN-ID [RFC6125] with a corresponding number extension. Instead, the CA MUST include a redactedSubjectAltName
of "?" labels. Every label to the left of a "?" label MUST also be (Section 4.2.2) extension that contains, in a redacted form, the same
redacted. For example, if a certificate contains a DNS-ID of identities that will be included in the certificate's subjectAltName
"top.secret.example.com", then the corresponding DNS-ID in the extension.
precertificate could contain "?.?.example.com" instead, but not
"top.?.example.com" instead.
Wildcard "*" labels MUST NOT be redacted. However, if the complete Wildcard "*" labels MUST NOT be redacted, but one or more non-
leftmost label of a DNS-ID or CN-ID is "*", it is considered redacted wildcard labels in each DNS-ID [RFC6125] can each be replaced with a
for the purposes of determining if the label to the right may be redacted label as follows:
redacted. For example, if a certificate contains a DNS-ID of
"*.top.secret.example.com", then the corresponding DNS-ID in the
precertificate could contain "*.?.?.example.com" instead, but not
"?.?.?.example.com" instead.
4.2.2. Redacted Labels Certificate Extension REDACT(label) = prefix || BASE32(index || LABELHASH(keyid || label))
When a precertificate contains one or more "?" labels, a non-critical "label" is the case-sensitive label to be redacted.
extension (OID 1.3.101.77, whose extnValue OCTET STRING contains an
ASN.1 SEQUENCE OF INTEGERs) MUST be added to the corresponding
certificate. The purpose of this extension is to enable TLS clients
to reconstruct the TBSCertificate component of the precertificate
from the certificate, as described in Section 10.2.2.
Each INTEGER MUST have a value of zero or more. The first INTEGER "prefix" is the "?" character (ASCII value 63).
indicates the total number of "?" labels in the precertificate's
first DNS-ID; the second INTEGER does the same for the "||" denotes length-encoded concatenation. Each concatenated value
precertificate's second DNS-ID; etc. The last INTEGER does the same is preceded by a single byte that contains the length (in bytes) of
for the precertificate's zero or more CN-IDs. There MUST NOT be more that value.
INTEGERs than there are DNS-IDs (plus one, if any CN-IDs are
present); if there are fewer INTEGERs than this, the shortfall is "BASE32" is the Base 32 Encoding function (section 6 of [RFC4648]).
made up by implicitly repeating the last INTEGER. Pad characters MUST NOT be appended to the encoded data.
"index" is the 1 byte index of a hash function in Section 12.2. The
value 255 is reserved.
"LABELHASH" is the hash function identified by "index".
"keyid" is the keyIdentifier from the Subject Key Identifier
extension (section 4.2.1.2 of [RFC5280]), excluding the ASN.1 OCTET
STRING tag and length bytes.
4.2.2. redactedSubjectAltName Certificate Extension
The redactedSubjectAltName extension is a non-critical extension (OID
1.3.101.77) that is identical in structure to the subjectAltName
extension, except that dNSName identities MAY contain redacted labels
(see Section 4.2.1).
When used, the redactedSubjectAltName extension MUST be present in
both the precertificate and the corresponding certificate.
This extension informs TLS clients of the dNSNames that were redacted
and the degree of redaction, while minimizing the complexity of
TBSCertificate reconstruction (as described in Section 10.2.2).
Hashing the redacted labels allows the legitimate domain owner to
identify whether or not each redacted label correlates to a label
they know of.
4.3. Using a Name-Constrained Intermediate CA 4.3. Using a Name-Constrained Intermediate CA
An intermediate CA certificate or intermediate CA precertificate that An intermediate CA certificate or intermediate CA precertificate that
contains the critical or non-critical Name Constraints [RFC5280] contains the Name Constraints [RFC5280] extension MAY be logged in
extension MAY be logged in place of end-entity certificates issued by place of end-entity certificates issued by that intermediate CA, as
that intermediate CA, as long as all of the following conditions are long as all of the following conditions are met:
met:
o there MUST be a non-critical extension (OID 1.3.101.76, whose o there MUST be a non-critical extension (OID 1.3.101.76, whose
extnValue OCTET STRING contains ASN.1 NULL data (0x05 0x00)). extnValue OCTET STRING contains ASN.1 NULL data (0x05 0x00)).
This extension is an explicit indication that it is acceptable to This extension is an explicit indication that it is acceptable to
not log certificates issued by this intermediate CA. not log certificates issued by this intermediate CA.
o permittedSubtrees MUST specify one or more dNSNames. o permittedSubtrees MUST specify one or more dNSNames.
o excludedSubtrees MUST specify the entire IPv4 and IPv6 address o excludedSubtrees MUST specify the entire IPv4 and IPv6 address
ranges. ranges.
Below is an example Name Constraints extension that meets these Below is an example Name Constraints extension that meets these
conditions: conditions:
skipping to change at page 15, line 44 skipping to change at page 17, line 9
accepted by the log. accepted by the log.
"precertificate_chain" is a vector of 1 or more additional "precertificate_chain" is a vector of 1 or more additional
certificates required to verify "pre_certificate". The first certificates required to verify "pre_certificate". The first
certificate MUST certify "pre_certificate". Each following certificate MUST certify "pre_certificate". Each following
certificate MUST directly certify the one preceding it. The final certificate MUST directly certify the one preceding it. The final
certificate MUST be a trust anchor accepted by the log. certificate MUST be a trust anchor accepted by the log.
5.3. Log ID 5.3. Log ID
Each log is uniquely identified by an OID. A log's operator MUST Each log is identified by an OID, which is specified in the log's
either allocate the OID themselves or request an OID from one of the metadata and which MUST NOT be used to identify any other log. A
two Log ID Registries (see Section 12.6.1 and Section 12.6.2). The log's operator MUST either allocate the OID themselves or request an
OID is specified in the log's metadata. Various data structures OID from one of the two Log ID Registries (see Section 12.6.1 and
include the DER encoding of this OID, excluding the ASN.1 tag and Section 12.6.2). Various data structures include the DER encoding of
length bytes, in an opaque vector: this OID, excluding the ASN.1 tag and length bytes, in an opaque
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.
5.4. TransItem Structure 5.4. TransItem Structure
Various data structures are encapsulated in the "TransItem" structure Various data structures are encapsulated in the "TransItem" structure
to ensure that the type and version of each one is identified in a to ensure that the type and version of each one is identified in a
common fashion: common fashion:
enum { enum {
reserved(0), reserved(0),
x509_entry_v2(1), precert_entry_v2(2), x509_entry_v2(1), precert_entry_v2(2),
x509_sct_v2(3), precert_sct_v2(4), x509_sct_v2(3), precert_sct_v2(4),
tree_head_v2(5), signed_tree_head_v2(6), tree_head_v2(5), signed_tree_head_v2(6),
consistency_proof_v2(7), inclusion_proof_v2(8), consistency_proof_v2(7), inclusion_proof_v2(8),
skipping to change at page 28, line 25 skipping to change at page 30, line 25
Note that more than one case can be true, in which case the Note that more than one case can be true, in which case the
returned data is their concatenation. It is also possible for returned data is their concatenation. It is also possible for
none to be true, in which case the front-end MUST return an empty none to be true, in which case the front-end MUST return an empty
response. response.
Outputs: Outputs:
inclusion: A base64 encoded "TransItem" of type inclusion: A base64 encoded "TransItem" of type
"inclusion_proof_v2" whose "inclusion_path" array of Merkle "inclusion_proof_v2" whose "inclusion_path" array of Merkle
Tree nodes proves the inclusion of the chosen certificate in Tree nodes proves the inclusion of the chosen certificate in
the selected STH. the returned STH.
sth: A base64 encoded "TransItem" of type "signed_tree_head_v2", sth: A base64 encoded "TransItem" of type "signed_tree_head_v2",
signed by this log. signed by this log.
consistency: A base64 encoded "TransItem" of type consistency: A base64 encoded "TransItem" of type
"consistency_proof_v2" that proves the consistency of the "consistency_proof_v2" that proves the consistency of the
requested STH and the returned STH. requested STH and the returned STH.
Note that no signature is required for the "inclusion" or Note that no signature is required for the "inclusion" or
"consistency" outputs as they are used to verify inclusion in and "consistency" outputs as they are used to verify inclusion in and
skipping to change at page 34, line 12 skipping to change at page 36, line 12
"sth" is the encapsulated data structure from an STH that was signed "sth" is the encapsulated data structure from an STH that was signed
by the same log as "sct". by the same log as "sct".
"inclusion_proof" is the encapsulated data structure from an "inclusion_proof" is the encapsulated data structure from an
inclusion proof that corresponds to "sct" and can be used to compute inclusion proof that corresponds to "sct" and can be used to compute
the root in "sth". the root in "sth".
8.4. Presenting SCTs only 8.4. Presenting SCTs only
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 10.2.4) and reduces load on protect the client's privacy (see Section 10.2.5) and reduces load on
log servers. However, if a TLS server is unable to obtain an log servers. However, if a TLS server is unable to obtain an
inclusion proof and STH that correspond to an SCT, then it MUST inclusion proof and STH that correspond to an SCT, then it MUST
include "TransItem" structures of type "x509_sct_v2" or include "TransItem" structures of type "x509_sct_v2" or
"precert_sct_v2" in the "TransItemList". "precert_sct_v2" in the "TransItemList".
8.5. transparency_info TLS Extension 8.5. transparency_info TLS Extension
Provided that a TLS client includes the "transparency_info" extension Provided that a TLS client includes the "transparency_info" extension
type in the ClientHello, the TLS server SHOULD include the type in the ClientHello, the TLS server SHOULD include the
"transparency_info" extension in the ServerHello with "transparency_info" extension in the ServerHello with
skipping to change at page 36, line 27 skipping to change at page 38, line 27
Maximum Chain Length The longest chain submission the log is willing Maximum Chain Length The longest chain submission the log is willing
to accept, if the log chose to limit it. to accept, if the log chose to limit it.
STH Frequency Count The maximum number of STHs the log may produce STH Frequency Count The maximum number of STHs the log may produce
in any period equal to the "Maximum Merge Delay" (see in any period equal to the "Maximum Merge Delay" (see
Section 5.8). Section 5.8).
Final STH If a log has been closed down (i.e. no longer accepts new 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 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 client should know the final valid STH in the log to ensure no new
entries can be added without detection. entries can be added without detection. The final STH should be
provided in the form of a TransItem of type 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.
10.2. TLS Client 10.2. TLS Client
10.2.1. Receiving SCTs 10.2.1. Receiving SCTs
TLS clients receive SCTs alongside or in certificates. TLS clients TLS clients receive SCTs alongside or in certificates. TLS clients
MUST implement all of the three mechanisms by which TLS servers may MUST implement all of the three mechanisms by which TLS servers may
skipping to change at page 36, line 50 skipping to change at page 38, line 51
support the "transparency_info" TLS extension SHOULD include it in support the "transparency_info" TLS extension SHOULD include it in
ClientHello messages, with empty "extension_data". TLS clients may ClientHello messages, with empty "extension_data". TLS clients may
also receive inclusion proofs in addition to SCTs, which should be also receive inclusion proofs in addition to SCTs, which should be
checked once the SCTs are validated. checked once the SCTs are validated.
10.2.2. Reconstructing the TBSCertificate 10.2.2. Reconstructing the TBSCertificate
To reconstruct the TBSCertificate component of a precertificate from To reconstruct the TBSCertificate component of a precertificate from
a certificate, TLS clients should: a certificate, TLS clients should:
o Remove the Redacted Labels extension described in Section 4.2.2 o Remove the Transparency Information extension described in
o Replace leftmost labels of each DNS-ID with "?", based on the Section 9.1.
INTEGER value corresponding to that DNS-ID in the extension.
A certificate with redacted labels where one of the redacted labels o If the redactedSubjectAltName extension (Section 4.2.2) is
is "*" MUST NOT be considered compliant. present:
* TLS clients MUST verify it against the subjectAltName extension
according to Section 10.2.3.
* Once verified, remove the subjectAltName extension from the
TBSCertificate.
If the SCT checked is for a Precertificate (where the "type" of the If the SCT checked is for a Precertificate (where the "type" of the
"TransItem" is "precert_sct_v2"), then the client SHOULD also remove "TransItem" is "precert_sct_v2"), then the client SHOULD also remove
embedded v1 SCTs, identified by OID 1.3.6.1.4.1.11129.2.4.2 (See embedded v1 SCTs, identified by OID 1.3.6.1.4.1.11129.2.4.2 (See
Section 3.3. of [RFC6962]), in the process of reconstructing the Section 3.3. of [RFC6962]), in the process of reconstructing the
TBSCertificate. That is to allow embedded v1 and v2 SCTs to co-exist TBSCertificate. That is to allow embedded v1 and v2 SCTs to co-exist
in a certificate (See Appendix A). in a certificate (See Appendix A).
10.2.3. Validating SCTs 10.2.3. Verifying the redactedSubjectAltName extension
If the redactedSubjectAltName extension is present, TLS clients MUST
check that the subjectAltName extension is present, that the
subjectAltName extension contains the same number of identities as
the redactedSubjectAltName extension, and that each identity in the
subjectAltName extension has a matching identity at the same position
in the redactedSubjectAltName extension. Two identities are matching
if either:
o The two identities are identical; or,
o Both identities are DNS names, have the same number of labels, and
each label in the subjectAltName identity has a matching label at
the same position in the redactedSubjectAltName identity. Two DNS
labels are matching if either:
* The two labels are identical; or,
* Neither label is "*" and the label from the
redactedSubjectAltName identity is equal to REDACT(label from
subjectAltName identity) (Section 4.2.1).
If any of these checks fail, the certificate MUST NOT be considered
compliant.
10.2.4. Validating SCTs
In addition to normal validation of the server certificate and its In addition to normal validation of the server certificate and its
chain, TLS clients SHOULD validate each received SCT for which they chain, TLS clients SHOULD validate each received SCT for which they
have the corresponding log's metadata. To validate an SCT, a TLS have the corresponding log's metadata. To validate an SCT, a TLS
client computes the signature input from the SCT data and the client computes the signature input from the SCT data and the
corresponding certificate, and then verifies the signature using the corresponding certificate, and then verifies the signature using the
corresponding log's public key. TLS clients MUST NOT consider valid corresponding log's public key. TLS clients MUST NOT consider valid
any SCT whose timestamp is in the future. any SCT whose timestamp is in the future.
Before considering any SCT to be invalid, the TLS client MUST attempt Before considering any SCT to be invalid, the TLS client MUST attempt
to validate it against the server certificate and against each of the to validate it against the server certificate and against each of the
zero or more suitable name-constrained intermediates (Section 4.3) in zero or more suitable name-constrained intermediates (Section 4.3) in
the chain. These certificates may be evaluated in the order they the chain. These certificates may be evaluated in the order they
appear in the chain, or, indeed, in any order. appear in the chain, or, indeed, in any order.
10.2.4. Validating inclusion proofs 10.2.5. Validating inclusion proofs
After validating a received SCT, a TLS client MAY request a After validating a received SCT, a TLS client MAY request a
corresponding inclusion proof (if one is not already available) and corresponding inclusion proof (if one is not already available) and
then verify it. An inclusion proof can be requested directly from a then verify it. An inclusion proof can be requested directly from a
log using "get-proof-by-hash" (Section 6.5) or "get-all-by-hash" log using "get-proof-by-hash" (Section 6.5) or "get-all-by-hash"
(Section 6.6), but note that this will disclose to the log which TLS (Section 6.6), but note that this will disclose to the log which TLS
server the client has been communicating with. server the client has been communicating with.
Alternatively, if the TLS client has received an inclusion proof (and Alternatively, if the TLS client has received an inclusion proof (and
an STH) alongside the SCT, it can proceed to verifying the inclusion an STH) alongside the SCT, it can proceed to verifying the inclusion
skipping to change at page 38, line 11 skipping to change at page 40, line 39
TLS clients SHOULD also verify each received inclusion proof (see TLS clients SHOULD also verify each received inclusion proof (see
Section 10.4.1) for which they have the corresponding log's metadata, Section 10.4.1) for which they have the corresponding log's metadata,
to audit the log and gain confidence that the certificate is logged. to audit the log and gain confidence that the certificate is logged.
If the TLS client holds an STH that predates the SCT, it MAY, in the If the TLS client holds an STH that predates the SCT, it MAY, in the
process of auditing, request a new STH from the log (Section 6.3), process of auditing, request a new STH from the log (Section 6.3),
then verify it by requesting a consistency proof (Section 6.4). Note then verify it by requesting a consistency proof (Section 6.4). Note
that if the TLS client uses "get-all-by-hash", then it will already that if the TLS client uses "get-all-by-hash", then it will already
have the new STH. have the new STH.
10.2.5. Evaluating compliance 10.2.6. Evaluating compliance
To be considered compliant, a certificate MUST be accompanied by at To be considered compliant, a certificate MUST be accompanied by at
least one valid SCT. A certificate not accompanied by any valid SCTs least one valid SCT. A certificate not accompanied by any valid SCTs
MUST NOT be considered compliant by TLS clients. MUST NOT be considered compliant by TLS clients.
10.2.6. TLS Feature Extension 10.2.7. TLS Feature Extension
If any certificate in a chain includes the transparency_info If any certificate in a chain includes the transparency_info
(Section 8.5) TLS extension identifier in the TLS Feature [RFC7633] (Section 8.5) TLS extension identifier in the TLS Feature [RFC7633]
certificate extension, then CT compliance (using any of the certificate extension, then CT compliance (using any of the
mechanisms from Section 8) is required. mechanisms from Section 8) is required.
TLS clients MUST treat certificates which fail this requirement as 10.2.8. Handling of Non-compliance
non-compliant.
10.2.7. Handling of Non-compliance
If a TLS server presents a certificate chain that is non-compliant, If a TLS server presents a certificate chain that is non-compliant,
there are two possibilities. and the use of a compliant certificate is mandated by an explicit
security policy, application protocol specification, the TLS Feature
o In the case that use of TLS with a valid certificate is mandated extension or any other means, the TLS client MUST refuse the
by explicit security policy, application protocol specification, connection.
or other means, the TLS client MUST refuse the connection.
o If the use of TLS with a valid certificate is optional, the TLS
client MAY accept the connection but MUST NOT treat the
certificate as valid.
10.3. Monitor 10.3. 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 needs to, at least, inspect every new entry in each log it A monitor needs to, at least, inspect every new entry in each log it
watches. It may also want to keep copies of entire logs. In order watches. It may also want to keep copies of entire logs. In order
skipping to change at page 43, line 25 skipping to change at page 45, line 48
not aware of a hash algorithm change. not aware of a hash algorithm change.
Allowing multiple signature or hash algorithms for a log would Allowing multiple signature or hash algorithms for a log would
require that all data structures support it and would significantly require that all data structures support it and would significantly
complicate client implementation, which is why it is not supported by complicate client implementation, which is why it is not supported by
this document. this document.
If it should become necessary to deprecate an algorithm used by a If it should become necessary to deprecate an algorithm used by a
live log, then the log should be frozen as specified in Section 10.1 live log, then the log should be frozen as specified in Section 10.1
and a new log should be started. Certificates in the frozen log that and a new log should be started. Certificates in the frozen log that
have not yet expired and require new SCTs should be submitted to the have not yet expired and require new SCTs SHOULD be submitted to the
new log and the SCTs from that log used instead. new log and the SCTs from that log used instead.
12. IANA Considerations 12. IANA Considerations
12.1. TLS Extension Type 12.1. TLS Extension Type
IANA is asked to allocate an RFC 5246 ExtensionType value for the IANA is asked to allocate an RFC 5246 ExtensionType value for the
"transparency_info" TLS extension. IANA should update this extension "transparency_info" TLS extension. IANA should update this extension
type to point at this document. type to point at this document.
skipping to change at page 45, line 47 skipping to change at page 48, line 25
that the log has misbehaved, which will be discovered when the SCT is that the log has misbehaved, which will be discovered when the SCT is
audited. A signed timestamp is not a guarantee that the certificate audited. A signed timestamp is not a guarantee that the certificate
is not misissued, since appropriate monitors might not have checked is not misissued, since appropriate monitors might not have checked
the logs or the CA might have refused to revoke the certificate. the logs or the CA might have refused to revoke the certificate.
In addition, if TLS clients will not accept unlogged certificates, In addition, if TLS clients will not accept unlogged certificates,
then site owners will have a greater incentive to submit certificates then site owners will have a greater incentive to submit certificates
to logs, possibly with the assistance of their CA, increasing the to logs, possibly with the assistance of their CA, increasing the
overall transparency of the system. overall transparency of the system.
[I-D.ietf-trans-threat-analysis] provides a more detailed threat
analysis of the Certificate Transparency architecture.
13.1. Misissued Certificates 13.1. Misissued Certificates
Misissued certificates that have not been publicly logged, and thus Misissued certificates that have not been publicly logged, and thus
do not have a valid SCT, are not considered compliant (so TLS clients do not have a valid SCT, are not considered compliant. Misissued
may decide, for example, to reject them). Misissued certificates certificates that do have an SCT from a log will appear in that
that do have an SCT from a log will appear in that public log within public log within the Maximum Merge Delay, assuming the log is
the Maximum Merge Delay, assuming the log is operating correctly. operating correctly. Thus, the maximum period of time during which a
Thus, the maximum period of time during which a misissued certificate misissued certificate can be used without being available for audit
can be used without being available for audit is the MMD. is the MMD.
13.2. Detection of Misissue 13.2. Detection of Misissue
The logs do not themselves detect misissued certificates; they rely The logs do not themselves detect misissued certificates; they rely
instead on interested parties, such as domain owners, to monitor them instead on interested parties, such as domain owners, to monitor them
and take corrective action when a misissue is detected. and take corrective action when a misissue is detected.
13.3. Avoiding Overly Redacting Domain Name Labels 13.3. Avoiding Overly Redacting Domain Name Labels
Redaction of domain name labels carries the same risks as the use of Redaction of domain name labels carries the same risks as the use of
wildcards (See Section 7.2 of [RFC6125], for example). If the wildcards (See Section 7.2 of [RFC6125], for example). If the
entirety of the domain space below the unredacted part of a domain entirety of the domain space below the unredacted part of a domain
name is not controlled by a single entity (e.g. "?.com", "?.co.uk" name is not registered by a single domain owner (e.g.
and other public suffixes [Public.Suffix.List]), then the domain name "REDACT(label).com", "REDACT(label).co.uk" and other public suffixes
may be considered by clients to be overly redacted. [Public.Suffix.List]), then the domain name may be considered by
clients to be overly redacted.
CAs should take care to avoid overly redacting domain names in CAs should take care to avoid overly redacting domain names in
precertificates. It is expected that monitors will treat precertificates. It is expected that monitors will treat
precertificates that contain overly redacted domain names as precertificates that contain overly redacted domain names as
potentially misissued. TLS clients MAY consider a certificate to be potentially misissued. TLS clients MAY consider a certificate to be
non-compliant if the reconstructed TBSCertificate (Section 10.2.2) non-compliant if the reconstructed TBSCertificate (Section 10.2.2)
contains any overly redacted domain names. contains any overly redacted domain names.
13.4. Misbehaving Logs 13.4. Misbehaving Logs
skipping to change at page 47, line 32 skipping to change at page 50, line 15
o Clients that gossip STHs or report back SCTs can be tracked or o Clients that gossip STHs or report back SCTs can be tracked or
traced if a log was to produce multiple STHs or SCTs with the same traced if a log was to produce multiple STHs or SCTs with the same
timestamp and data but different signatures. timestamp and data but different signatures.
13.6. Multiple SCTs 13.6. Multiple SCTs
By offering multiple SCTs, each from a different log, TLS servers By offering multiple SCTs, each from a different log, TLS servers
reduce the effectiveness of an attack where a CA and a log collude reduce the effectiveness of an attack where a CA and a log collude
(see Section 8.1). (see Section 8.1).
13.7. Threat Analysis 14. Privacy Considerations
[I-D.ietf-trans-threat-analysis] provides a more detailed threat 14.1. Ensuring Effective Redaction
analysis of the Certificate Transparency architecture.
14. Acknowledgements Although the domain name redaction mechanism (Section 4.2) removes
the need for private labels to appear in logs, it does not guarantee
that this will never happen. Anyone who encounters a certificate
could choose to submit it to one or more logs, thereby rendering the
redaction futile. Therefore, domain owners are advised to take the
following steps to minimize the likelihood that their private labels
will become known outside their closed communities:
The authors would like to thank Erwann Abelea, Robin Alden, Al o Avoid registering private labels in public DNS.
Cutter, Francis Dupont, Adam Eijdenberg, Stephen Farrell, Daniel Kahn
Gillmor, Paul Hadfield, Brad Hill, Jeff Hodges, Paul Hoffman, Jeffrey o Avoid using private labels that are predictable (e.g. "www").
Hutzelman, Kat Joyce, Stephen Kent, SM, Alexey Melnikov, Linus
Nordberg, Chris Palmer, Trevor Perrin, Pierre Phaneuf, Melinda Shore, CAs are advised to carefully consider each request to redact a label.
Ryan Sleevi, Martin Smith, Carl Wallace and Paul Wouters for their When a CA believes that redacting a particular label would be futile,
valuable contributions. we advise rejecting the redaction request. TLS clients may have
policies that forbid redaction, so redaction should only be used when
it's absolutely necessary and likely to be effective.
15. Acknowledgements
The authors would like to thank Erwann Abelea, Robin Alden, Andrew
Ayer, Al Cutter, Francis Dupont, Adam Eijdenberg, Stephen Farrell,
Daniel Kahn Gillmor, Paul Hadfield, Brad Hill, Jeff Hodges, Paul
Hoffman, Jeffrey Hutzelman, Kat Joyce, Stephen Kent, SM, Alexey
Melnikov, Linus Nordberg, Chris Palmer, Trevor Perrin, Pierre
Phaneuf, Melinda Shore, Ryan Sleevi, Martin Smith, Carl Wallace and
Paul Wouters for their valuable contributions.
A big thank you to Symantec for kindly donating the OIDs from the A big thank you to Symantec for kindly donating the OIDs from the
1.3.101 arc that are used in this document. 1.3.101 arc that are used in this document.
15. References 16. References
15.1. Normative References 16.1. Normative References
[DSS] National Institute of Standards and Technology, "Digital [DSS] National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", FIPS 186-3, June 2009, Signature Standard (DSS)", FIPS 186-3, June 2009,
<http://csrc.nist.gov/publications/fips/fips186-3/ <http://csrc.nist.gov/publications/fips/fips186-3/
fips_186-3.pdf>. fips_186-3.pdf>.
[FIPS.180-4] [FIPS.180-4]
National Institute of Standards and Technology, "Secure National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-4, March 2012, Hash Standard", FIPS PUB 180-4, March 2012,
<http://csrc.nist.gov/publications/fips/fips180-4/ <http://csrc.nist.gov/publications/fips/fips180-4/
skipping to change at page 49, line 38 skipping to change at page 52, line 38
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature
Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
2013, <http://www.rfc-editor.org/info/rfc6979>. 2013, <http://www.rfc-editor.org/info/rfc6979>.
[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, <http://www.rfc-editor.org/info/rfc7633>. October 2015, <http://www.rfc-editor.org/info/rfc7633>.
15.2. Informative References 16.2. Informative References
[Chromium.Log.Policy] [Chromium.Log.Policy]
The Chromium Projects, "Chromium Certificate Transparency The Chromium Projects, "Chromium Certificate Transparency
Log Policy", 2014, <http://www.chromium.org/Home/ Log Policy", 2014, <http://www.chromium.org/Home/
chromium-security/certificate-transparency/log-policy>. chromium-security/certificate-transparency/log-policy>.
[Chromium.Policy] [Chromium.Policy]
The Chromium Projects, "Chromium Certificate The Chromium Projects, "Chromium Certificate
Transparency", 2014, <http://www.chromium.org/Home/ Transparency", 2014, <http://www.chromium.org/Home/
chromium-security/certificate-transparency>. chromium-security/certificate-transparency>.
 End of changes. 44 change blocks. 
201 lines changed or deleted 265 lines changed or added

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