< draft-ietf-trans-rfc6962-bis-06.txt   draft-ietf-trans-rfc6962-bis-07.txt >
skipping to change at page 1, line 13 skipping to change at page 1, line 13
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: September 10, 2015 E. Messeri Expires: September 10, 2015 E. Messeri
Google Google
R. Stradling R. Stradling
Comodo Comodo
March 9, 2015 March 9, 2015
Certificate Transparency Certificate Transparency
draft-ietf-trans-rfc6962-bis-06 draft-ietf-trans-rfc6962-bis-07
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 2, line 40 skipping to change at page 2, line 40
2.1.4. Signatures . . . . . . . . . . . . . . . . . . . . . 9 2.1.4. Signatures . . . . . . . . . . . . . . . . . . . . . 9
3. Log Format and Operation . . . . . . . . . . . . . . . . . . 9 3. Log Format and Operation . . . . . . . . . . . . . . . . . . 9
3.1. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Private Domain Name Labels . . . . . . . . . . . . . . . 12 3.2. Private Domain Name Labels . . . . . . . . . . . . . . . 12
3.2.1. Wildcard Certificates . . . . . . . . . . . . . . . . 12 3.2.1. Wildcard Certificates . . . . . . . . . . . . . . . . 12
3.2.2. Redacting Domain Name Labels in Precertificates . . . 12 3.2.2. Redacting Domain Name Labels in Precertificates . . . 12
3.2.3. Using a Name-Constrained Intermediate CA . . . . . . 13 3.2.3. Using a Name-Constrained Intermediate CA . . . . . . 13
3.3. Structure of the Signed Certificate Timestamp . . . . . . 14 3.3. Structure of the Signed Certificate Timestamp . . . . . . 14
3.4. Including the Signed Certificate Timestamp in the TLS 3.4. Including the Signed Certificate Timestamp in the TLS
Handshake . . . . . . . . . . . . . . . . . . . . . . . . 15 Handshake . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.1. TLS Extension . . . . . . . . . . . . . . . . . . . . 17 3.4.1. TLS Extension . . . . . . . . . . . . . . . . . . . . 16
3.4.2. X.509v3 Extension . . . . . . . . . . . . . . . . . . 17
3.5. Merkle Tree . . . . . . . . . . . . . . . . . . . . . . . 17 3.5. Merkle Tree . . . . . . . . . . . . . . . . . . . . . . . 17
3.6. Signed Tree Head . . . . . . . . . . . . . . . . . . . . 18 3.6. Signed Tree Head . . . . . . . . . . . . . . . . . . . . 18
4. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 19 4. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 19
4.1. Add Chain to Log . . . . . . . . . . . . . . . . . . . . 21 4.1. Add Chain to Log . . . . . . . . . . . . . . . . . . . . 21
4.2. Add PreCertChain to Log . . . . . . . . . . . . . . . . . 22 4.2. Add PreCertChain to Log . . . . . . . . . . . . . . . . . 22
4.3. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 22 4.3. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 22
4.4. Retrieve Merkle Consistency Proof between Two Signed Tree 4.4. Retrieve Merkle Consistency Proof between Two Signed Tree
Heads . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Heads . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5. Retrieve Merkle Inclusion Proof from Log by Leaf Hash . . 23 4.5. Retrieve Merkle Inclusion Proof from Log by Leaf Hash . . 23
4.6. Retrieve Merkle Inclusion Proof, Signed Tree Head and 4.6. Retrieve Merkle Inclusion Proof, Signed Tree Head and
skipping to change at page 15, line 45 skipping to change at page 15, line 45
"signed_entry" is the "leaf_certificate" (in the case of an "signed_entry" is the "leaf_certificate" (in the case of an
X509ChainEntry) or is the TBSCertificate (in the case of a X509ChainEntry) or is the TBSCertificate (in the case of a
PrecertChainEntryV2), as described above. PrecertChainEntryV2), as described above.
"extensions" are future extensions to SignedCertificateTimestamp v2. "extensions" are future extensions to SignedCertificateTimestamp v2.
Currently, no extensions are specified. Currently, no extensions are specified.
3.4. Including the Signed Certificate Timestamp in the TLS Handshake 3.4. Including the Signed Certificate Timestamp in the TLS Handshake
The SCT data corresponding to at least one certificate in the chain The SCT data corresponding to at least one certificate in the chain
from at least one log must be included in the TLS handshake, either from at least one log must be included in the TLS handshake by using
by using an X509v3 certificate extension as described below, by using one or more of the mechanisms listed below. Three mechanisms are
a TLS extension (Section 7.4.1.4 of [RFC5246]) with type provided because they have different tradeoffs. TLS clients MUST
"signed_certificate_timestamp", or by using Online Certificate Status implement all three mechanisms. TLS servers MUST present SCTs using
Protocol (OCSP) Stapling (also known as the "Certificate Status at least one of the three mechanisms.
Request" TLS extension; see [RFC6066]), where the OCSP response
includes a non-critical extension with OID 1.3.6.1.4.1.11129.2.4.5
(see [RFC2560]) and body:
SignedCertificateTimestampList ::= OCTET STRING
in the singleExtensions component of the SingleResponse pertaining to o A TLS extension (Section 7.4.1.4 of [RFC5246]) with type
the end-entity certificate. "signed_certificate_timestamp" (see Section 3.4.1). This
mechanism allows TLS servers to participate in CT without the
cooperation of CAs, unlike the other two mechanisms. It also
allows SCTs to be updated on the fly.
At least one SCT MUST be included. Server operators MAY include more o An Online Certificate Status Protocol (OCSP) [RFC6960] response
than one SCT. extension (see Section 3.4.2.1), where the OCSP response is
provided in the "certificate_status" TLS extension (Section 8 of
[RFC6066]), also known as OCSP stapling. This mechanism is
already widely (but not universally) implemented. It also allows
SCTs to be updated on the fly.
Similarly, a certification authority MAY submit a precertificate to o An X509v3 certificate extension (see Section 3.4.2.2). This
more than one log, and all obtained SCTs can be directly embedded in mechanism allows the use of unmodified TLS servers, but, because
the issued certificate, by encoding the the included SCTs cannot be changed without re-issuing the
SignedCertificateTimestampList structure as an ASN.1 OCTET STRING and certificate, increases the risk that the certificate will be
inserting the resulting data in the TBSCertificate as a non-critical refused if any of the SCTs become invalid.
X.509v3 certificate extension (OID 1.3.6.1.4.1.11129.2.4.2). Upon
receiving the certificate, clients can reconstruct the original
TBSCertificate to verify the SCT signature.
The contents of the ASN.1 OCTET STRING embedded in an OCSP extension TLS servers SHOULD send SCTs from multiple logs in case one or more
or X509v3 certificate extension are as follows: logs are not acceptable to the TLS client (for example, if a log has
been struck off for misbehavior, has had a key compromise or is not
known to the TLS client). Multiple SCTs are combined into an SCT
list as follows:
opaque SerializedSCT<1..2^16-1>; opaque SerializedSCT<1..2^16-1>;
struct { struct {
SerializedSCT sct_list <1..2^16-1>; SerializedSCT sct_list <1..2^16-1>;
} SignedCertificateTimestampList; } SignedCertificateTimestampList;
Here, "SerializedSCT" is an opaque byte string that contains the Here, "SerializedSCT" is an opaque byte string that contains the
serialized SCT structure. This encoding ensures that TLS clients can serialized SCT structure. This encoding ensures that TLS clients can
decode each SCT individually (i.e., if there is a version upgrade, decode each SCT individually (i.e., if there is a version upgrade,
out-of-date clients can still parse old SCTs while skipping over new out-of-date clients can still parse old SCTs while skipping over new
SCTs whose versions they don't understand). SCTs whose versions they don't understand).
Likewise, SCTs can be embedded in a TLS extension. See below for
details.
TLS clients MUST implement all three mechanisms. Servers MUST
implement at least one of the three mechanisms. Note that existing
TLS servers can generally use the certificate extension mechanism
without modification.
TLS servers SHOULD send SCTs from multiple logs in case one or more
logs are not acceptable to the client (for example, if a log has been
struck off for misbehavior, has had a key compromise or is not known
to the client).
The three mechanisms are provided because they have different
tradeoffs. Embedding the SCTs in the certificate allows the use of
unmodified TLS servers, but, because they cannot be changed without
re-issuing the certificate, increases the risk that the certificate
will be refused if the SCTs become invalid. OCSP Stapling is already
widely (but not universally) implemented, and provides a mechanism by
which TLS servers that already support it can serve SCTs that are
generated on the fly. Finally, the TLS extension permits TLS servers
to participate in CT without the cooperation of CAs, unlike the other
two mechanisms. It also allows SCTs to be updated on the fly.
3.4.1. TLS Extension 3.4.1. TLS Extension
The SCT can be sent during the TLS handshake using a TLS extension One or more SCTs can be sent during the TLS handshake using a TLS
with type "signed_certificate_timestamp". extension with type "signed_certificate_timestamp".
Clients that support the extension SHOULD send a ClientHello TLS clients that support the extension SHOULD send a ClientHello
extension with the appropriate type and empty "extension_data". extension with the appropriate type and empty "extension_data".
Servers MUST only send SCTs in this TLS extension to clients who have TLS servers MUST only send SCTs in this TLS extension to TLS clients
indicated support for the extension in the ClientHello, in which case that have indicated support for the extension in the ClientHello, in
the SCTs are sent by setting the "extension_data" to a which case the SCTs are sent by setting the "extension_data" to a
"SignedCertificateTimestampList". "SignedCertificateTimestampList".
Session resumption uses the original session information: clients Session resumption uses the original session information: TLS clients
SHOULD include the extension type in the ClientHello, but if the SHOULD include the extension type in the ClientHello, but if the
session is resumed, the server is not expected to process it or session is resumed, the TLS server is not expected to process it or
include the extension in the ServerHello. include the extension in the ServerHello.
3.4.2. X.509v3 Extension
One or more SCTs can be embedded in an X.509v3 extension that is
included in a certificate or an OCSP response. Since RFC5280
requires the "extnValue" field (an OCTET STRING) of each X.509v3
extension to include the DER encoding of an ASN.1 value, we cannot
embed a "SignedCertificateTimestampList" directly. Instead, we have
to wrap it inside an additional OCTET STRING (see below), which we
then put into the "extnValue" field.
3.4.2.1. OCSP Response Extension
A certification authority may embed one or more SCTs in OCSP
responses pertaining to the end-entity certificate, by including a
non-critical "singleExtensions" extension with OID
1.3.6.1.4.1.11129.2.4.5 whose "extnValue" contains:
CertificateSCTList ::= OCTET STRING
"CertificateSCTList" contains a "SignedCertificateTimestampList"
whose SCTs all have the "x509_entry" "LogEntryType".
3.4.2.2. Certificate Extension
A certification authority that has submitted a precertificate to one
or more logs may embed the obtained SCTs in the "TBSCertificate" that
will be signed to produce the certificate, by including a non-
critical X.509v3 extension with OID 1.3.6.1.4.1.11129.2.4.2 whose
"extnValue" contains:
PrecertificateSCTList ::= OCTET STRING
"PrecertificateSCTList" contains a "SignedCertificateTimestampList"
whose SCTs all have the "precert_entry_V2" "LogEntryType".
Upon receiving the certificate, clients can reconstruct the original
"TBSCertificate" to verify the SCT signatures.
3.5. Merkle Tree 3.5. Merkle Tree
The hashing algorithm for the Merkle Tree Hash is specified in the The hashing algorithm for the Merkle Tree Hash is specified in the
log's metadata. log's metadata.
Structure of the Merkle Tree input: Structure of the Merkle Tree input:
enum { v1(0), v2(1), (255) } enum { v1(0), v2(1), (255) }
LeafVersion; LeafVersion;
skipping to change at page 33, line 36 skipping to change at page 33, line 36
fips-180-4.pdf>. fips-180-4.pdf>.
[HTML401] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01 [HTML401] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01
Specification", World Wide Web Consortium Recommendation Specification", World Wide Web Consortium Recommendation
REC-html401-19991224, December 1999, REC-html401-19991224, December 1999,
<http://www.w3.org/TR/1999/REC-html401-19991224>. <http://www.w3.org/TR/1999/REC-html401-19991224>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003. Version 2.1", RFC 3447, February 2003.
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006. JavaScript Object Notation (JSON)", RFC 4627, July 2006.
skipping to change at page 34, line 29 skipping to change at page 34, line 26
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
Extension Definitions", RFC 6066, January 2011. Extension Definitions", RFC 6066, January 2011.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011. Security (TLS)", RFC 6125, March 2011.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, June 2013.
11.2. Informative References 11.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/
 End of changes. 16 change blocks. 
62 lines changed or deleted 80 lines changed or added

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