Internet DRAFT - draft-kseo-trans-ca-subject
draft-kseo-trans-ca-subject
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
<TBD>
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
<TBD>
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]
