Internet DRAFT - draft-dseomn-trans-browsers
draft-dseomn-trans-browsers
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
<TBD>
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]
