Certificate Transparency
draft-ietf-trans-rfc6962-bis-19
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 9162.
|
|
|---|---|---|---|
| Authors | Ben Laurie , Adam Langley , Emilia Kasper , Eran Messeri , Rob Stradling | ||
| Last updated | 2016-09-25 (Latest revision 2016-08-31) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Consensus: Waiting for Write-Up | |
| Associated WG milestone |
|
||
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 9162 (Experimental) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-trans-rfc6962-bis-19
quot;Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<http://www.rfc-editor.org/info/rfc5652>.
Laurie, et al. Expires March 4, 2017 [Page 49]
Internet-Draft Certificate Transparency August 2016
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<http://www.rfc-editor.org/info/rfc6066>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <http://www.rfc-editor.org/info/rfc6125>.
[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, DOI 10.17487/RFC6960, June 2013,
<http://www.rfc-editor.org/info/rfc6960>.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
Multiple Certificate Status Request Extension", RFC 6961,
DOI 10.17487/RFC6961, June 2013,
<http://www.rfc-editor.org/info/rfc6961>.
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
Algorithm (DSA) and Elliptic Curve Digital Signature
Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
2013, <http://www.rfc-editor.org/info/rfc6979>.
[RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS)
Feature Extension", RFC 7633, DOI 10.17487/RFC7633,
October 2015, <http://www.rfc-editor.org/info/rfc7633>.
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension", RFC 7924,
DOI 10.17487/RFC7924, July 2016,
<http://www.rfc-editor.org/info/rfc7924>.
15.2. Informative References
[Chromium.Log.Policy]
The Chromium Projects, "Chromium Certificate Transparency
Log Policy", 2014, <http://www.chromium.org/Home/chromium-
security/certificate-transparency/log-policy>.
Laurie, et al. Expires March 4, 2017 [Page 50]
Internet-Draft Certificate Transparency August 2016
[Chromium.Policy]
The Chromium Projects, "Chromium Certificate
Transparency", 2014, <http://www.chromium.org/Home/
chromium-security/certificate-transparency>.
[CrosbyWallach]
Crosby, S. and D. Wallach, "Efficient Data Structures for
Tamper-Evident Logging", Proceedings of the 18th USENIX
Security Symposium, Montreal, August 2009,
<http://static.usenix.org/event/sec09/tech/full_papers/
crosby.pdf>.
[EVSSLGuidelines]
CA/Browser Forum, "Guidelines For The Issuance And
Management Of Extended Validation Certificates", 2007,
<https://cabforum.org/wp-content/uploads/
EV_Certificate_Guidelines.pdf>.
[I-D.ietf-trans-gossip]
Nordberg, L., Gillmor, D., and T. Ritter, "Gossiping in
CT", draft-ietf-trans-gossip-03 (work in progress), July
2016.
[I-D.ietf-trans-threat-analysis]
Kent, S., "Attack and Threat Model for Certificate
Transparency", draft-ietf-trans-threat-analysis-08 (work
in progress), August 2016.
[JSON.Metadata]
The Chromium Projects, "Chromium Log Metadata JSON
Schema", 2014, <http://www.certificate-transparency.org/
known-logs/log_list_schema.json>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<http://www.rfc-editor.org/info/rfc6962>.
Appendix A. Supporting v1 and v2 simultaneously
Certificate Transparency logs have to be either v1 (conforming to
[RFC6962]) or v2 (conforming to this document), as the data
structures are incompatible and so a v2 log could not issue a valid
v1 SCT.
CT clients, however, can support v1 and v2 SCTs, for the same
certificate, simultaneously, as v1 SCTs are delivered in different
TLS, X.509 and OCSP extensions than v2 SCTs.
Laurie, et al. Expires March 4, 2017 [Page 51]
Internet-Draft Certificate Transparency August 2016
v1 and v2 SCTs for X.509 certificates can be validated independently.
For precertificates, v2 SCTs should be embedded in the TBSCertificate
before submission of the TBSCertificate (inside a v1 precertificate,
as described in Section 3.1. of [RFC6962]) to a v1 log so that TLS
clients conforming to [RFC6962] but not this document are oblivious
to the embedded v2 SCTs. An issuer can follow these steps to produce
an X.509 certificate with embedded v1 and v2 SCTs:
o Create a CMS precertificate as described in Section 3.2 and submit
it to v2 logs.
o Embed the obtained v2 SCTs in the TBSCertificate, as described in
Section 9.1.2.
o Use that TBSCertificate to create a v1 precertificate, as
described in Section 3.1. of [RFC6962] and submit it to v1 logs.
o Embed the v1 SCTs in the TBSCertificate, as described in
Section 3.3. of [RFC6962].
o Sign that TBSCertificate (which now contains v1 and v2 SCTs) to
issue the final X.509 certificate.
Authors' Addresses
Ben Laurie
Google UK Ltd.
Email: benl@google.com
Adam Langley
Google Inc.
Email: agl@google.com
Emilia Kasper
Google Switzerland GmbH
Email: ekasper@google.com
Eran Messeri
Google UK Ltd.
Email: eranm@google.com
Laurie, et al. Expires March 4, 2017 [Page 52]
Internet-Draft Certificate Transparency August 2016
Rob Stradling
Comodo CA, Ltd.
Email: rob.stradling@comodo.com
Laurie, et al. Expires March 4, 2017 [Page 53]