draft-ietf-trans-rfc6962-bis-17.txt   draft-ietf-trans-rfc6962-bis-18.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: January 22, 2017 E. Messeri Expires: January 28, 2017 E. Messeri
Google Google
R. Stradling R. Stradling
Comodo Comodo
July 21, 2016 July 27, 2016
Certificate Transparency Certificate Transparency
draft-ietf-trans-rfc6962-bis-17 draft-ietf-trans-rfc6962-bis-18
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 January 22, 2017. This Internet-Draft will expire on January 28, 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 41 skipping to change at page 2, line 41
3. Submitters . . . . . . . . . . . . . . . . . . . . . . . . . 11 3. Submitters . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Certificates . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Certificates . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Precertificates . . . . . . . . . . . . . . . . . . . . . 11 3.2. Precertificates . . . . . . . . . . . . . . . . . . . . . 11
4. Private Domain Name Labels . . . . . . . . . . . . . . . . . 12 4. Private Domain Name Labels . . . . . . . . . . . . . . . . . 12
4.1. Wildcard Certificates . . . . . . . . . . . . . . . . . . 12 4.1. Wildcard Certificates . . . . . . . . . . . . . . . . . . 12
4.2. Redaction of Domain Name Labels . . . . . . . . . . . . . 13 4.2. Redaction of Domain Name Labels . . . . . . . . . . . . . 13
4.2.1. Redacting Labels in Precertificates . . . . . . . . . 13 4.2.1. Redacting Labels in Precertificates . . . . . . . . . 13
4.2.2. redactedSubjectAltName Certificate Extension . . . . 13 4.2.2. redactedSubjectAltName Certificate Extension . . . . 13
4.3. Using a Name-Constrained Intermediate CA . . . . . . . . 14 4.3. Using a Name-Constrained Intermediate CA . . . . . . . . 14
5. Log Format and Operation . . . . . . . . . . . . . . . . . . 15 5. Log Format and Operation . . . . . . . . . . . . . . . . . . 15
5.1. Accepting Submissions . . . . . . . . . . . . . . . . . . 15 5.1. Accepting Submissions . . . . . . . . . . . . . . . . . . 16
5.2. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 16 5.2. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 16
5.3. Log ID . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.3. Log ID . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.4. TransItem Structure . . . . . . . . . . . . . . . . . . . 17 5.4. TransItem Structure . . . . . . . . . . . . . . . . . . . 18
5.5. Merkle Tree Leaves . . . . . . . . . . . . . . . . . . . 19 5.5. Merkle Tree Leaves . . . . . . . . . . . . . . . . . . . 19
5.6. Signed Certificate Timestamp (SCT) . . . . . . . . . . . 19 5.6. Signed Certificate Timestamp (SCT) . . . . . . . . . . . 20
5.7. Merkle Tree Head . . . . . . . . . . . . . . . . . . . . 21 5.7. Merkle Tree Head . . . . . . . . . . . . . . . . . . . . 21
5.8. Signed Tree Head (STH) . . . . . . . . . . . . . . . . . 21 5.8. Signed Tree Head (STH) . . . . . . . . . . . . . . . . . 21
5.9. Merkle Consistency Proofs . . . . . . . . . . . . . . . . 23 5.9. Merkle Consistency Proofs . . . . . . . . . . . . . . . . 23
5.10. Merkle Inclusion Proofs . . . . . . . . . . . . . . . . . 23 5.10. Merkle Inclusion Proofs . . . . . . . . . . . . . . . . . 23
5.11. Shutting down a log . . . . . . . . . . . . . . . . . . . 24 5.11. Shutting down a log . . . . . . . . . . . . . . . . . . . 24
6. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 24 6. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 24
6.1. Add Chain to Log . . . . . . . . . . . . . . . . . . . . 26 6.1. Add Chain to Log . . . . . . . . . . . . . . . . . . . . 26
6.2. Add PreCertChain to Log . . . . . . . . . . . . . . . . . 27 6.2. Add PreCertChain to Log . . . . . . . . . . . . . . . . . 27
6.3. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 27 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
skipping to change at page 12, line 13 skipping to change at page 12, line 13
1.3.101.78. 1.3.101.78.
o "SignedData.encapContentInfo.eContent" MUST contain a o "SignedData.encapContentInfo.eContent" MUST contain a
TBSCertificate [RFC5280] that will be identical to the TBSCertificate [RFC5280] that will be identical to the
TBSCertificate in the issued certificate, except that: TBSCertificate in the issued certificate, except that:
* the Transparency Information (Section 9.1) extension MUST be * the Transparency Information (Section 9.1) extension MUST be
omitted. omitted.
* the subjectAltName [RFC5280] extension MUST be omitted when the * the subjectAltName [RFC5280] extension MUST be omitted when the
CA is using domain name redaction (Section 4.2). redactedSubjectAltName (Section 4.2.2) extension is present.
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).
skipping to change at page 13, line 10 skipping to change at page 13, line 10
the leftmost label in a DNS-ID is 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 omit the subjectAltName When creating a precertificate, the CA MAY omit the subjectAltName
extension. Instead, the CA MUST include a redactedSubjectAltName extension, even if it intends to include the extension in the final
(Section 4.2.2) extension that contains, in a redacted form, the same certificate. If omitting the subjectAltName extension, the CA MUST
identities that will be included in the certificate's subjectAltName include a redactedSubjectAltName (Section 4.2.2) extension that
extension. contains, in a redacted form, the same entries that will be included
in the certificate's subjectAltName extension.
Wildcard "*" labels MUST NOT be redacted, but one or more non- Wildcard "*" labels MUST NOT be redacted, but one or more non-
wildcard labels in each DNS-ID [RFC6125] can each be replaced with a wildcard labels in each DNS-ID [RFC6125] can each be replaced with a
redacted label as follows: redacted label as follows:
REDACT(label) = prefix || BASE32(index || LABELHASH(keyid || label)) REDACT(label) = prefix || BASE32(index || _label_hash)
_label_hash = LABELHASH(keyid_len || keyid || label_len || label)
"label" is the case-sensitive label to be redacted. "label" is the case-sensitive label to be redacted.
"prefix" is the "?" character (ASCII value 63). "prefix" is the "?" character (ASCII value 63).
"||" denotes length-encoded concatenation. Each concatenated value
is preceded by a single byte that contains the length (in bytes) of
that value.
"BASE32" is the Base 32 Encoding function (section 6 of [RFC4648]).
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 "index" is the 1 byte index of a hash function in Section 12.2. The
value 255 is reserved. value 255 is reserved.
"LABELHASH" is the hash function identified by "index". "keyid_len" is the 1 byte length of the "keyid".
"keyid" is the keyIdentifier from the Subject Key Identifier "keyid" is the keyIdentifier from the Subject Key Identifier
extension (section 4.2.1.2 of [RFC5280]), excluding the ASN.1 OCTET extension (section 4.2.1.2 of [RFC5280]), excluding the ASN.1 OCTET
STRING tag and length bytes. STRING tag and length bytes.
"label_len" is the 1 byte length of the "label".
"||" denotes concatenation.
"BASE32" is the Base 32 Encoding function (section 6 of [RFC4648]).
Pad characters MUST NOT be appended to the encoded data.
"LABELHASH" is the hash function identified by "index".
4.2.2. redactedSubjectAltName Certificate Extension 4.2.2. redactedSubjectAltName Certificate Extension
The redactedSubjectAltName extension is a non-critical extension (OID The redactedSubjectAltName extension is a non-critical extension (OID
1.3.101.77) that is identical in structure to the subjectAltName 1.3.101.77) that is identical in structure to the subjectAltName
extension, except that dNSName identities MAY contain redacted labels extension, except that DNS-IDs MAY contain redacted labels (see
(see Section 4.2.1). Section 4.2.1).
When used, the redactedSubjectAltName extension MUST be present in When used, the redactedSubjectAltName extension MUST be present in
both the precertificate and the corresponding certificate. both the precertificate and the corresponding certificate.
This extension informs TLS clients of the dNSNames that were redacted This extension informs TLS clients of the DNS-ID labels that were
and the degree of redaction, while minimizing the complexity of redacted and the degree of redaction, while minimizing the complexity
TBSCertificate reconstruction (as described in Section 10.2.2). of TBSCertificate reconstruction (as described in Section 10.2.2).
Hashing the redacted labels allows the legitimate domain owner to Hashing the redacted labels allows the legitimate domain owner to
identify whether or not each redacted label correlates to a label identify whether or not each redacted label correlates to a label
they know of. they know of.
Only DNS-ID labels can be redacted using this mechanism. However,
CAs can use Name Constraints (Section 4.3) to allow DNS domain name
labels in other subjectAltName entries to not appear in logs.
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 Name Constraints [RFC5280] extension MAY be logged in contains the Name Constraints [RFC5280] extension MAY be logged in
place of end-entity certificates issued by that intermediate CA, as place of end-entity certificates issued by that intermediate CA, as
long as all of the following conditions are met: long as all of the following conditions are 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
skipping to change at page 39, line 25 skipping to change at page 39, line 25
"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. Verifying the redactedSubjectAltName extension 10.2.3. Verifying the redactedSubjectAltName extension
If the redactedSubjectAltName extension is present, TLS clients MUST If the redactedSubjectAltName extension is present, TLS clients MUST
check that the subjectAltName extension is present, that the check that the subjectAltName extension is present, that the
subjectAltName extension contains the same number of identities as subjectAltName extension contains the same number of entries as the
the redactedSubjectAltName extension, and that each identity in the redactedSubjectAltName extension, and that each entry in the
subjectAltName extension has a matching identity at the same position subjectAltName extension has a matching entry at the same position in
in the redactedSubjectAltName extension. Two identities are matching the redactedSubjectAltName extension. Two entries are matching if
if either: either:
o The two identities are identical; or, o The two entries are identical; or,
o Both identities are DNS names, have the same number of labels, and o Both entries are DNS-IDs, have the same number of labels, and each
each label in the subjectAltName identity has a matching label at label in the subjectAltName entry has a matching label at the same
the same position in the redactedSubjectAltName identity. Two DNS position in the redactedSubjectAltName entry. Two labels are
labels are matching if either: matching if either:
* The two labels are identical; or, * The two labels are identical; or,
* Neither label is "*" and the label from the * Neither label is "*" and the label from the
redactedSubjectAltName identity is equal to REDACT(label from redactedSubjectAltName entry is equal to REDACT(label from
subjectAltName identity) (Section 4.2.1). subjectAltName entry) (Section 4.2.1).
If any of these checks fail, the certificate MUST NOT be considered If any of these checks fail, the certificate MUST NOT be considered
compliant. compliant.
10.2.4. Validating SCTs 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
 End of changes. 20 change blocks. 
38 lines changed or deleted 46 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/