Public Notary Transparency K. Seo Internet Draft D. Mandelberg Intended status: Standards Track S. Kent Expires: November 2016 BBN Technologies May 24, 2016 Certificate Transparency (CT) Certification Authority and Subject Requirements draft-kseo-trans-ca-subject-01.txt Abstract This document describes the requirements for Certification Authorities (CAs) and Subjects that elect to participate as elements of 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. Seo, et al. Expires November 24, 2016 [Page 1] Internet-DraftCT Certification Authority and Subject Requirements May 2016 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 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.....................................3 2. Requirements for a CT-aware Certification Authority (CA).......3 2.1. Interaction with a Log....................................4 2.1.1. Logging a (pre-)certificate..........................4 2.1.2. Name-redacted pre-certificates.......................4 2.1.3. Which and How Many Logs to Use.......................5 2.2. Verification of Logging...................................5 2.3. Monitoring................................................5 2.4. Remediation...............................................6 3. Requirements for CT-aware Subjects (TLS web servers)...........6 3.1. Logging a Certificate.....................................7 3.2. Verification of Logging...................................7 3.3. Monitoring................................................8 3.4. Remediation...............................................8 4. Security Considerations........................................8 5. IANA Considerations............................................9 6. References.....................................................9 6.1. Normative References......................................9 6.2. Informative References....................................9 7. Acknowledgments...............................................10 1. Introduction Certificate Transparency (CT) is a set of mechanisms designed to deter, detect, and facilitate remediation of certificate mis- issuance [Architecture]. Mis-issuance of certificates by CAs motivates the development of CT. This document describes the requirements for Certification Authorities (CAs) and Subjects that elect to participate as elements of the Certificate Transparency (CT) system, focusing on the Web PKI context. Seo, et al. Expires November 24, 2016 [Page 2] Internet-DraftCT Certification Authority and Subject 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 a CT-aware Certification Authority (CA) A CT-aware CA logs the certificates that it issues. It may benefit from CT since relying parties may have greater confidence in the validity of such certificates because they are available to be observed by Monitors [Monitor-Auditor]. CAs also are the CT elements primarily responsible for remediation, i.e., by revoking mis-issued certificates. A CT-aware CA MUST submit a certificate (or a pre-certificate [6962- bis]) to one or more logs selected by the CA. A CT-aware CA submits a pre-certificate to a log when it issues a name redacted certificate (see Section 4.2 of [6962-bis]), or when it wants to embed a Signed Certificate Timestamp (SCT) (see Section 5.6 of [6962-bis]) in a certificate that it issues. A CA operating an OCSP server MAY elect to provide SCTs to its Subjects via an OCSP extension (see Section 8.1.1 of [6962-bis]). Figure 1 illustrates interactions between a CA and other elements of the CT system. +-----+ +----+ +---------+ | Log |<----->| CA |<***>| Monitor | +-----+ +----+ +---------+ ^ * v +---------+ | Subject | +---------+ Legend: <---> Interface defined by CT <***> Interface out of scope for CT Figure 1 Interactions between CA and other elements of CT system Seo, et al. Expires November 24, 2016 [Page 3] Internet-DraftCT Certification Authority and Subject Requirements May 2016 2.1. Interaction with a Log Most certificates submitted to logs are expected to be end-entity certificates, each associated with the Subject (TLS Server) that it represents. This includes wildcard certificates, which are EE certificates that will match a set of Subject names. These are attractive to a Subject because a single certificate can be used to represent multiple servers (in subdomains of a single domain name). CT-aware CAs MAY issue wildcard certificates, if such issuance is consistent with the Certificate Practice Statement of the CA. In addition to logging EE certificates, a CA that issues name- constrained CA certificates MAY elect to log them (see Section 4.3 of [6962-bis]). 2.1.1. Logging a (pre-)certificate A CA MAY interact with a log to submit a (pre-)certificate to create a log entry (see Section 3 of [6962-bis]). The pre-certificate capability is offered to facilitate rapid deployment of CT. It has the advantage that web sites need not make any software changes to acquire one or more SCTs, because the SCTs are embedded in the certificate itself. There is, however, a downside of embedding SCTs in certificates. If a log that provided an SCT is compromised or otherwise becomes not acceptable to browsers and Monitors, the certificate associated with that SCT will have to be re-issued with a replacement SCT. Thus, in the long term, the options of conveying an SCT via the TLS handshake or in an OCSP response (e.g., "stapled" into the handshake [RFC6961]), are preferred. However, transmission of an SCT via the TLS handshake requires changes to web site software to acquire and insert SCTs. Transmission via an OCSP response requires that either browsers fetch such responses (which appears not to be the norm), or that a web site passes the OCSP data via the TLS handshake (and that the OCSP signer be prepared to generate this modified form of response). 2.1.2. Name-redacted pre-certificates A CA may submit a "name-redacted" pre-certificate to a log. A name- redacted pre-certificate includes one or more "?" labels in lieu of DNS name components. Name-redaction is a feature of CT designed to enable an organization to log certificates without revealing all of the DNS name components in the certificate that will be matched to the log entry. This is an attractive feature for organizations that want to benefit from CT without revealing internal server names as a side effect of logging. An end-entity certificate that is to be treated as logged via this mechanism MUST contain a critical Seo, et al. Expires November 24, 2016 [Page 4] Internet-DraftCT Certification Authority and Subject Requirements May 2016 (X.509v3) extension that indicates which labels have been redacted in the log entry. This extension is needed to enable TLS clients and Monitors to match a received certificate against the corresponding log entry in an unambiguous fashion. See Section 4.2 of [6962-bis] for a detailed description of name-redaction in the CT context. 2.1.3. Which and How Many Logs to Use The CT architecture does not mandate a specific number of SCTs that should be associated with a certificate. Browsers and Monitors MAY establish requirements for the minimum number of associated SCTs in different contexts, but such requirements are outside the scope of the CT architecture. The implication of this is that it is up to the CA to determine which and how many logs to use for a given certificate. In selecting an appropriate set of logs, a CA is trying to anticipate which logs will be acceptable to the TLS clients (browsers) that will process SCTs. CAs MAY track the sets of logs that browser vendors configure into their products to ensure appropriate log coverage. A CA also may accept suggestions for logs from the Subjects it serves. The CT architecture does not specify interfaces or protocols for communication between CT-aware CAs and browser vendors or Subjects to acquire this information. 2.2. Verification of Logging A CA SHOULD verify the SCT that has been returned for a certificate or pre-certificate. (A CA might submit certificates or pre- certificates to multiple logs, with the intent to use only a subset of the returned SCTs. In this case the CA need not verify SCTs that is does not elect to use.) It is RECOMMENDED that a CA verify that a pre-certificate or certificate that it has submitted has, in fact, been logged. To perform this verification, the CA waits for an interval dictated by the Maximum Merge Delay (MMD) associated with the log, and then requests both a Signed Tree Head (STH) and an inclusion proof (Section 6.6 of [6962-bis]). The CA SHOULD then verify the inclusion proof returned by the log, as described in Section 9.4.1 of [6962-bis]. 2.3. Monitoring It is RECOMMENDED that a CT-aware CA operate a Monitor on behalf of its clients. In this context the CA has most of the reference information needed to perform the Monitor function (see [Monitor- Auditor]). (For Subjects who use only the one CA, the CA has all of the information needed; for Subjects who use multiple CAs for the same DNS names, each CA would need reference information for all of Seo, et al. Expires November 24, 2016 [Page 5] Internet-DraftCT Certification Authority and Subject Requirements May 2016 the legitimate certificates issued by all of the other CAs.) When a CA detects a log entry that conflicts with a certificate that it issued (and that has not otherwise been authorized by the appropriate Subject), the Monitor SHOULD alert the affected Subject, so that the Subject can request revocation of the mis-issued certificate. The interface used by a CT-aware CA to inform the Subject is not specified by this document. 2.4. Remediation When a CA is notified that the CA has mis-issued a certificate, the CA SHOULD verify that the reporting entity is authorized to make this request and that the certificate in question has been mis- issued. If authorization and mis-issuance are verified, the CA SHOULD revoke and replace the mis-issued certificate. How the CA verifies the authorization of the reporting entity is outside the scope of the CT architecture. (If the entity that notified the CA is the Subject of the mis-issued certificate, the Subject should be able to provide evidence that it is the legitimate holder of another certificate for the name in question.) 3. Requirements for CT-aware Subjects (TLS web servers) Certificate Subjects are major beneficiaries of CT, since legitimate certificates issued to them are protected by CT mechanisms. Detection of mis-issuance by a Monitor is supported if a bogus/erroneous certificate is logged, and if the Subject has arranged to have its (legitimate) certificates tracked by one or more Monitors. (Ideally, the Subject or its CA logged the legitimate certificates, but that is not strictly required for a mis-issued certificate to be detected by a Monitor.) A Subject is responsible for requesting revocation (to effect remediation) when it is alerted to mis-issuance of a certificate with a Subject or Subject Alternative names associated with the Subject. Alerting is performed by the Monitor function, but a Subject may act as a self-Monitor. Finally, Subjects are responsible for conveying SCTs [6962-bis] to browsers, e.g., transmitting them using a TLS handshake extension, via an OCSP extension, or via embedding in the certificate for the web site. (See Section 7 of [6962-bis] for details on SCT transmission.) Figure 2 illustrates interactions between a Subject and other elements of the CT system. Seo, et al. Expires November 24, 2016 [Page 6] Internet-DraftCT Certification Authority and Subject Requirements May 2016 +----+ | CA | +----+ ^ * v +-----+ +----------+ +---------+ | Log |<--->| Subject |<****| Monitor | +-----+ +----------+ +---------+ ^ ^ * * * * v v +---------+ +----------------+ | Browser | | Browser Vendor | +---------+ +----------------+ Legend: <---> Interface defined by CT <***> Interface out of scope for CT Figure 2 Interactions between Subject and other elements of CT 3.1. Logging a Certificate A CT-aware Subject (e.g., a web site operator) MAY submit its certificate(s) to a log, and acquire an SCT for each certificate it submits, using the add-chain log interface (see Section 6.1 of [6962-bis]). There are three reasons for a Subject to log its own certificate(s): (1) its CA did not embed an SCT in the certificate(s) it issued to the Subject, (2) the Subject wants to acquire SCTs from additional logs, or (3) the Subject wants the flexibility offered by conveying SCTs (from logs of its choosing) in the TLS handshake (including via OCSP). Section 7 of [6962-bis] describes the requirements imposed on Subjects (TLS Servers) for delivery of SCTs to CT-enabled TLS clients. 3.2. Verification of Logging When a Subject has acquired an SCT, it SHOULD perform the same checks described for a CA (see Section 2.2 above), to verify that the log has created an entry for each submitted certificate. Seo, et al. Expires November 24, 2016 [Page 7] Internet-DraftCT Certification Authority and Subject Requirements May 2016 3.3. Monitoring It is RECOMMENDED that every CT-aware Subject either perform self- monitoring, or become a client of a third-party Monitor (see [Monitor-Auditor] for details). In the self-monitoring context, log entries of interest are ones that contain a Subject or Subject Alternative Name (SAN) associated with the Subject's web site(s). (Name-constrained CA certificates and wildcard certificates also have to be examined to detect certificates that would match the end- entity certificates associated with a Subject's web sites.) Whenever a certificate of interest is detected, the Subject compares it with the public key information associated with the Subject's certificate(s). If there is a mismatch, this indicates that this logged certificate was mis-issued. The means by which a Subject determines which set of logs to watch is outside the scope of the CT specifications. Although the CT architecture does not limit the number of logs that may exist, it is anticipated that there will be a small number of logs that are widely used. If this model is adopted, the metadata for these logs will be available from browser vendors [Browsers], and thus should be available to Subjects that elect to act as their own Monitors. 3.4. Remediation If certificate mis-issuance is detected by or reported to the Subject, the Subject contacts the CA that issued the certificate (using the Issuer name in the certificate), and requests revocation of the mis-issued certificate, to resolve the problem. (The means by which a Subject determines how to contact a CA based on the issuer name is outside the scope of this specification.) The Subject may also contact browser vendors and ask that they put the certificate on a blacklist of mis-issued certificates or put the issuing CA's certificate on a bad-CA-list. 4. Security Considerations CT is a system created to improve security for X.509 public key certificates, especially in the Web PKI context. The attack analysis in [draft-trans-threat-analysis] 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. That analysis is based on the architecture described in [Architecture], and thus readers of this document are referred to that one for a thorough discussion of the security aspects of CT. Briefly, CT logs represent a viable means of deterring semantic mis-issuance of certificates. Monitors are an effective way to detect semantic mis-issuance of Seo, et al. Expires November 24, 2016 [Page 8] Internet-DraftCT Certification Authority and Subject Requirements May 2016 logged certificates [Monitor-Auditor]. The CT architecture enables certificate Subjects to request revocation of mis-issued certificates, thus remedying such mis-issuance. Residual vulnerabilities exist with regard to some forms of log and Monitor misbehavior, because the architecture does not include normative means of detecting such behavior. The current design also does not ensure the ability of Monitors to detect syntactic mis-issuance of certificates. This is because provisions for asserting the type of certificate being issued, for inclusion in an SCT, have not been standardized. 5. IANA Considerations 6. References 6.1. Normative References [6962-bis] Laurie, B., Langley, A., Kasper, E., Messeri, E., and R. Stradling, "Certificate Transparency," draft-ietf-trans- rfc6962-bis-11 (work in progress), November 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension," RFC 6961, June 2013. 6.2. Informative References [Architecture] Kent, S., Mandelberg, D., and K. Seo, "Certificate Transparency (CT) System Architecture," draft-kent-trans- architecture-01 (work in progress), November 2015. [draft-trans-threat-analysis] Kent, S., "Attack Model and Threat for Certificate Transparency," draft-ietf-trans-threat- analysis-03 (work in progress), October 2015. [Monitor-Auditor] Kent, S., Mandelberg, D., and K. Seo, "Certificate Transparency (CT) Requirements for Monitors and Auditors," draft-kent-trans-monitor-auditor-00 (work in progress), November 2015. Seo, et al. Expires November 24, 2016 [Page 9] Internet-DraftCT Certification Authority and Subject Requirements May 2016 [Browsers] Mandelberg, D. and S. Kent, "Certificate Transparency (CT) Browser Requirements," draft-dseomn-trans-browsers-00 (work in progress), November 2015. 7. Acknowledgments Seo, et al. Expires November 24, 2016 [Page 10] Internet-DraftCT Certification Authority and Subject Requirements May 2016 Authors' Addresses Karen Seo Email: kseo@alum.mit.edu David Mandelberg Email: david@mandelberg.org Stephen Kent BBN Technologies 10 Moulton St. Cambridge, MA 02138 US Email: kent@bbn.com Seo, et al. Expires November 24, 2016 [Page 11]