Public Notary Transparency D. Mandelberg Internet Draft S. Kent Intended status: Standards Track BBN Technologies Expires: November 2016 May 24, 2016 Certificate Transparency (CT) Browser Requirements draft-dseomn-trans-browsers-01.txt Abstract This document describes the requirements for browsers in the Certificate Transparency (CT) system, focusing on the Web PKI context. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on November 24, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Mandelberg & Kent Expires November 24, 2016 [Page 1] Internet-Draft CT Browser Requirements May 2016 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction...................................................2 1.1. Requirements Language.....................................4 2. Requirements for CT-enabled Browsers...........................4 3. Requirements for Vendors of CT-enabled Browsers................5 4. Security Considerations........................................6 5. IANA Considerations............................................6 6. References.....................................................7 6.1. Normative References......................................7 6.2. Informative References....................................7 7. Acknowledgments................................................8 Appendix A. SCT Syntax Verification...............................9 Appendix B. Matching an SCT to a Certificate.....................10 1. Introduction Certificate transparency (CT) is a set of mechanisms designed to deter, detect, and facilitate remediation of certificate mis- issuance. Mis-issuance refers to violations of either semantic or syntactic constraints associated with certificates [attack-model]. The CT system comprises 6 types elements: logs, Monitors, Auditors, CT-aware Certification Authorities (CAs), CT-aware TLS servers, and CT-aware TLS Clients. Browsers that are CT-aware represent one type of TLS Client; they represent the primary example of a CT-aware TLS Client in the (initial) CT design. This document establishes requirements for browsers that claim compliance with the CT architecture [Architecture]. It also describes requirements for (CT- aware) browser vendors, because these vendors need to supply additional information to browsers to enable certain CT capabilities. Browsers do not directly detect mis-issuance nor do they remediate it. However, they may play a role in deterring mis-issuance, if they discriminate against certificates that are not logged. They also may assist in detecting certain forms of misbehavior by CT logs [Gossip]. A (CT-aware) browser benefits from CT if it rejects a mis-issued certificate, i.e., treats the certificate as invalid. A browser is protected from accepting a mis-issued certificate if that Mandelberg & Kent Expires November 24, 2016 [Page 2] Internet-Draft CT Browser Requirements May 2016 certificate is revoked, and if the browser checks the revocation status of the certificate. (A browser also is protected if the browser vendor "blacklists" a certificate or a CA as noted in Section 1 of [Architecture].) A browser also benefits from CT if the client validates a Signed Certificate Timestamp (SCT) [6962-bis] associated with a certificate, and rejects the certificate if the SCT is invalid. Error! Reference source not found. illustrates the relationship between browsers and the other elements of the CT system. +---------+ | Subject |<********* +---------+ * ^ * * * v * +-----+ +---------+ * | Log |<--->| Browser | * | | +---------+ * | | ^ ^ * | | * # * | | * v * | | * +---------+ * | | * | Auditor | * | | * +---------+ * | | v * | | +----------------+ * | |<***>| Browser Vendor |<** +-----+ +----------------+ ^ * v +---------+ | Monitor | +---------+ Legend: <---> Interface defined by CT <***> Interface out of scope for CT <###> Interface proposed by [Gossip]; not yet part of CT standards Figure 1 Browser and Browser Vendor Interfaces Mandelberg & Kent Expires November 24, 2016 [Page 3] Internet-Draft CT Browser Requirements May 2016 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Requirements for CT-enabled Browsers A CT-enabled browser incorporates the following capabilities with respect to processing SCTs. 1. It SHOULD signal to a TLS server (Subject) its ability to process the TLS extension "signed_certificate_timestamp". It does so by sending a ClientHello extension of this type, with empty "extension_data". 2. The browser MUST be able to process one or more SCTs delivered via the TLS handshake using the TLS extension noted above in 1. 3. The browser MUST be able to process one or more SCTs delivered via an X.509 certificate from a TLS server as part of a certificate-authenticated TLS session. The SCTs are conveyed in a certificate using the PrecertificateSCTList extension (OID 1.3.6.1.4.1.11129.2.4.2) [CA-subject]. 4. The browser MUST be able to process one or more SCTs delivered via an OCSP response, conveyed using the "CertificateSCTList" extension (OID 1.3.6.1.4.1.11129.2.4.5) [CA-subject]. A browser processes an SCT by performing the following actions: 1. The syntax of the SCT MUST be verified as specified in Appendix A. 2. If the SCT is not contained in a certificate (#3 above), the SCT MUST be matched to the certificate transmitted by the TLS server. Matching is performed as described in Appendix B of this document. 3. The signature of the SCT MUST be verified using the public key of the indicated log, combined with log metadata provisioned by the browser vendor (see Section 3 below). If no metadata for the log is available to the browser, the SCT is ignored. If none of the SCTs associated with a certificate can be verified due to lack of metadata, the certificate MAY be treated as invalid, at the discretion of the browser vendor or as a result of a user-selected configuration parameter. A browser vendor MAY establish a threshold number of SCTs that MUST be verified to accept a certificate (for which SCTs have been conveyed). Mandelberg & Kent Expires November 24, 2016 [Page 4] Internet-Draft CT Browser Requirements May 2016 If an SCT is conveyed for a TLS server in any of the ways noted above and it fails validation, the browser MUST consider the certificate for the server to be invalid and proceed accordingly. It is RECOMMENDED that a CT-enabled browser NOT reject a TLS session simply because no SCT is conveyed. (This recommendation can be removed when the IETF publishes an RFC describing an incremental deployment strategy for CT that avoids the backward compatibility problem that would arise if browsers reject certificates w/o SCTs.) However, A TLS client that is a browser MAY discriminate against a certificate presented for a web site if the certificate is not accompanied by an SCT, e.g., providing an indication of this via the user interface. The details of such discrimination are outside the scope of this specification. However, such discrimination SHOULD NOT cause the certificate to be treated as revoked/invalid, until such time as a (backwards compatible) incremental deployment strategy that allows for certificate rejection is specified and approved by the IETF. Note that the presence of one or more (validated) SCTs is not a guarantee that a certificate has been logged. To have high confidence that a certificate has been logged, a browser would have to verify that a log entry exists for the certificate. This requires acquisition of additional data from each log that supplied an SCT for this certificate, i.e., an inclusion proof (see Section 4.5 of [6962-bis]). Directly requesting an inclusion proof for a certificate from a log discloses to that log that the browser is interested in the certificate in question. This would disclose which web sites the browser user was visiting, a potential privacy concern for many users. Also, the data acquisition and processing might pose an unacceptable burden for browsers, and thus may not be performed in realtime anyway. Thus, a browser SHOULD NOT fetch inclusion proofs directly from a log. However, a browser MAY fetch inclusion proofs via other (not standardized) mechanisms that provide privacy deemed sufficient by the browser user. 3. Requirements for Vendors of CT-enabled Browsers In order to perform the SCT processing functions described in Section 2, a browser requires access to certain log metadata. A default set of such metadata SHOULD be provided by the browser vendor. (A browser vendor MAY allow a user to augment or modify this metadata.) This metadata consists of the following information for each log. 1. The log ID. Mandelberg & Kent Expires November 24, 2016 [Page 5] Internet-Draft CT Browser Requirements May 2016 2. The digital signature algorithm and hash algorithm used by the log to sign an SCT. 3. The pubic key used to verify SCT signatures generated by the log. 4. The final STH of the log, if the log has been closed down. 5. (OPTIONAL) Any other log metadata (as specified in Section 9.1 of [6962-bis]), at the discretion of the browser vendor. Additional metadata MAY be provided by a browser vendor. The means by which the log metadata is provisioned by a vendor to instances of its browsers is outside the scope of this specification. However, there's a potential circular dependency in provisioning of this information, if the provisioning channel relies on the same PKI that CT protects. Browser vendors are encouraged to develop mechanisms (not subject to standardization) to avoid such a dependency. In addition to providing certain log metadata, it is RECOMMENDED that browser vendors provision additional information supportive of CT. 1. A browser vendor SHOULD operate an Auditor to detect log misbehavior. When a vendor detects repeated misbehavior by a log, it SHOULD remove the log from the list of those available in its browsers. 2. A browser vendor SHOULD maintain a list of CAs that fail to revoke certificates when requested by a Subject that has provided evidence of mis-issuance by the CA. The vendor SHOULD provide an interface to enable Subjects to submit such information to the vendor, as input to this process. The vendor SHOULD then provision this blacklist of CAs to its browsers to enable them to reject certificates issued under the CAs, to support the remediation function of CT [threat-model]. 4. Security Considerations CT is a system created to improve security for X.509 public key certificates, especially in the Web PKI context. An attack analysis [threat-model] examines the types of attacks that can be mounted against CT, to effect mis-issuance, and how CT addresses (or fails to address) each type of attack. Readers of this document are referred to that document for a thorough discussion of the security aspects of CT. 5. IANA Considerations Mandelberg & Kent Expires November 24, 2016 [Page 6] Internet-Draft CT Browser Requirements May 2016 6. References 6.1. Normative References [Merkle] Merkle, R. C. (1988). "A Digital Signature Based on a Conventional Encryption Function." Advances in Cryptology - CRYPTO '87. Lecture Notes in Computer Science 293. p. 369 [6962-bis] Laurie, B., Langley, A., Kasper, E., Messeri, E., and R. Stradling, "Certificate Transparency," draft-ietf-trans- rfc6962-bis-10 (work in progress), October 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 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. [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension," RFC 6961, June 2013. 6.2. Informative References [attack-model] Kent, S., "Attack Model and Threat for Certificate Transparency," draft-ietf-trans-threat-analysis-03 (work in progress), October 2015. [Architecture] Kent, S., Mandelberg, D., and Seo, K., "Certificate Transparency (CT) System Architecture," draft-kent-trans- architecture-01 (work in progress), November, 2015. [Gossip] Nordberg, L., Gillmor, D., and Ritter, T., "Gossiping in CT," draft-ietf-trans-gossip-01 (work in progress), October 2015. [CA-subject] TBD. Mandelberg & Kent Expires November 24, 2016 [Page 7] Internet-Draft CT Browser Requirements May 2016 7. Acknowledgments Some of the text included in this document was produced by B. Laurie, A. Langley, E. Messeri, and R. Stradling in earlier versions of [6962-bis]. It has been extracted and edited for use here. Mandelberg & Kent Expires November 24, 2016 [Page 8] Internet-Draft CT Browser Requirements May 2016 Appendix A. SCT Syntax Verification Before a TLS client can check if an SCT is valid for a particular certificate, it must ensure that the SCT is syntactically valid: 1. When the raw data of the SCT is parsed as a struct SignedCertificateTimestamp from Section 5.3 of [6962-bis], there MUST be no parse errors. Additionally, there MUST NOT be any data remaining at the end of the raw SCT which is not part of the struct SignedCertificateTimestamp. 2. This document specifies the validation procedure for an SCT with an sct_version equal to v2. If the sct_version is not equal to v2 and the TLS client supports the specified version, the SCT may be processed according to the rules of whichever document specifies the procedures for that version. If the version is not supported, the client MUST consider the SCT to be invalid. 3. If the timestamp is in the future, the client MUST consider the SCT to be invalid. Mandelberg & Kent Expires November 24, 2016 [Page 9] Internet-Draft CT Browser Requirements May 2016 Appendix B. Matching an SCT to a Certificate When a TLS client receives an SCT via one of the mechanisms described in Appendix B of [Architecture], the client needs to match the SCT to a certificate in the certificate chain. For an SCT embedded in a certificate, the matching is trivial: the SCT belongs to the certificate in which it is embedded. In either of the other cases, the current SCT format does not contain sufficient information to enable this matching. Authors' Addresses David Mandelberg Email: david@mandelberg.org Stephen Kent BBN Technologies 10 Moulton St. Cambridge, MA 02138 US Email: kent@bbn.com Mandelberg & Kent Expires May 19, 2016 [Page 10]