< draft-housley-web-pki-problems-01.txt   draft-housley-web-pki-problems-02.txt >
Internet Architecture Board R. Housley Internet Architecture Board R. Housley
Internet-Draft Vigil Security Internet-Draft Vigil Security
Intended status: Informational K. O'Donoghue Intended status: Informational K. O'Donoghue
Expires: April 3, 2016 Internet Society Expires: May 5, 2016 Internet Society
October 1, 2015 November 2, 2015
Problems with the Public Key Infrastructure (PKI) for the World Wide Web Problems with the Public Key Infrastructure (PKI) for the World Wide Web
draft-housley-web-pki-problems-01.txt draft-housley-web-pki-problems-02.txt
Abstract Abstract
This document describes the technical and non-technical problems with This document describes the technical and non-technical problems with
the current Public Key Infrastructure (PKI) used for the World Wide the current Public Key Infrastructure (PKI) used for the World Wide
Web. Some potential technical improvements are considered, and some Web. Some potential technical improvements are considered, and some
non-technical approaches to improvements are discussed. non-technical approaches to improvements are discussed.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 3, 2016. This Internet-Draft will expire on May 5, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 12 skipping to change at page 2, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Very Brief Description of the Web PKI . . . . . . . . . . . . 2 2. Very Brief Description of the Web PKI . . . . . . . . . . . . 2
3. Technical Improvements to the Web PKI . . . . . . . . . . . . 3 3. Technical Improvements to the Web PKI . . . . . . . . . . . . 3
3.1. Weak Cryptographic Algorithms or Short Public Keys . . . 3 3.1. Weak Cryptographic Algorithms or Short Public Keys . . . 3
3.2. Certificate Status Checking . . . . . . . . . . . . . . . 4 3.2. Certificate Status Checking . . . . . . . . . . . . . . . 4
3.2.1. Short-lived Certificates . . . . . . . . . . . . . . 4 3.2.1. Short-lived Certificates . . . . . . . . . . . . . . 5
3.2.2. CRL Distribution Points . . . . . . . . . . . . . . . 4 3.2.2. CRL Distribution Points . . . . . . . . . . . . . . . 5
3.2.3. Proprietary Revocation Checks . . . . . . . . . . . . 5 3.2.3. Proprietary Revocation Checks . . . . . . . . . . . . 5
3.2.4. OCSP Stapling . . . . . . . . . . . . . . . . . . . . 5 3.2.4. OCSP Stapling . . . . . . . . . . . . . . . . . . . . 5
3.3. Surprising Certificates . . . . . . . . . . . . . . . . . 6 3.3. Surprising Certificates . . . . . . . . . . . . . . . . . 6
3.3.1. Certificate Authority Authorization (CAA) . . . . . . 7 3.3.1. Certificate Authority Authorization (CAA) . . . . . . 7
3.3.2. HTTP Public Key Pinning (HPKP) . . . . . . . . . . . 7 3.3.2. HTTP Public Key Pinning (HPKP) . . . . . . . . . . . 8
3.3.3. HTTP Strict Transport Security (HSTS) . . . . . . . . 8 3.3.3. HTTP Strict Transport Security (HSTS) . . . . . . . . 8
3.3.4. DNS-Based Authentication of Named Entities (DANE) . . 8 3.3.4. DNS-Based Authentication of Named Entities (DANE) . . 9
3.3.5. Certificate Transparency . . . . . . . . . . . . . . 9 3.3.5. Certificate Transparency . . . . . . . . . . . . . . 10
3.4. Automation for Server Administrators . . . . . . . . . . 10 3.4. Automation for Server Administrators . . . . . . . . . . 10
4. Policy and Process Improvements to the Web PKI . . . . . . . 10 4. Policy and Process Improvements to the Web PKI . . . . . . . 11
4.1. Determination of the Trusted Certificate Authorities . . 10 4.1. Determination of the Trusted Certificate Authorities . . 11
4.2. Governance Structures for the Web PKI . . . . . . . . . . 12 4.2. Governance Structures for the Web PKI . . . . . . . . . . 12
5. Other Considerations for Improving the Web PKI . . . . . . . 12 5. Other Considerations for Improving the Web PKI . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16
Appendix B. IAB Members at the Time of Approval . . . . . . . . 15 Appendix B. IAB Members at the Time of Approval . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
There are many technical and non-technical problems with the current There are many technical and non-technical problems with the current
Public Key Infrastructure (PKI) used for the World Wide Web. This Public Key Infrastructure (PKI) used for the World Wide Web. This
document describes these problems, considers some potential technical document describes these problems, considers some potential technical
improvements, and discusses some non-technical approaches to improvements, and discusses some non-technical approaches to
improvements. improvements.
The Web PKI makes use of certificates as described in RFC 5280 The Web PKI makes use of certificates as described in RFC 5280
[RFC5280]. These certificates are primarily used with Transport [RFC5280]. These certificates are primarily used with Transport
Layer Security (TLS) RFC 5246 [RFC5246]. Layer Security (TLS) RFC 5246 [RFC5246].
2. Very Brief Description of the Web PKI 2. Very Brief Description of the Web PKI
These topics are to be covered in this section: Certificates are specified in [RFC5280]. Certificates contain, among
other things, a subject name and a public key, and they are digitally
signed by the Certification Authority (CA). Certificate users
require confidence that the private key associated with the certified
public key is owned by the named subject. A certificate has a
limited valid lifetime.
o Certificate bind a name or names to a public key The architectural model used in the Web PKI includes:
o Enrollment process makes sure:
* it is the right name EE: End Entity -- the subject of a certificate -- certificates are
issued to Web Servers, and certificates are also issued to
clients that need mutual authentication.
* confirms that party actually holds the private key CA: Certification Authority -- the issuer of a certificate --
issues certificates for Web Servers and clients.
o Explain the entities RA: Registration Authority -- an optional system to which a CA
delegates some management functions such as identity validation
or physical credential distribution.
CAs are responsible for indicating the revocation status of the
certificates that they issue throughout the lifetime of the
certificate. Revocation status information may be provided using the
Online Certificate Status Protocol (OCSP) [RFC2560], certificate
revocation lists (CRLs) [RFC5280], or some other mechanism. In
general, when revocation status information is provided using CRLs,
the CA is also the CRL issuer. However, a CA may delegate the
responsibility for issuing CRLs to a different entity.
The enrollment process used by a CA makes sure that the subject name
in the certificate is appropriate and that the subject actually holds
the private key. Proof of possession of the private key is often
accomplished through a challenge-response protocol.
3. Technical Improvements to the Web PKI 3. Technical Improvements to the Web PKI
Over the years, many technical improvements have been made to the Web Over the years, many technical improvements have been made to the Web
PKI. This section discusses sever problems and the technical PKI. This section discusses sever problems and the technical
problems that have been made to address them. This history sets the problems that have been made to address them. This history sets the
stage for suggestions for additional improvements in other sections stage for suggestions for additional improvements in other sections
of this document. of this document.
3.1. Weak Cryptographic Algorithms or Short Public Keys 3.1. Weak Cryptographic Algorithms or Short Public Keys
skipping to change at page 3, line 50 skipping to change at page 4, line 25
cryptographic algorithms after weakness has been discovered and cryptographic algorithms after weakness has been discovered and
widely known. Similarly, valid trust anchors and certificates widely known. Similarly, valid trust anchors and certificates
contain public keys after computational resources available to contain public keys after computational resources available to
attackers have rendered them too weak. We have seen a very attackers have rendered them too weak. We have seen a very
successful migration away from certificates that use the MD2 or MD5 successful migration away from certificates that use the MD2 or MD5
one-way hash functions. However, there are still a great number of one-way hash functions. However, there are still a great number of
certificates that use SHA-1 and 1024-bit RSA public keys, and these certificates that use SHA-1 and 1024-bit RSA public keys, and these
should be replaced. should be replaced.
Today, the algorithms and key sizes used by a CA to sign certificates Today, the algorithms and key sizes used by a CA to sign certificates
with a traditional lifespan should offer at least 128 bits of with a traditional lifespan should offer 112 to 128 bits of security.
security. SHA-256 is a widely studied one-way hash function that SHA-256 is a widely studied one-way hash function that meets this
meets this requirement. RSA with a public key of at least 2048 bits requirement. RSA with a public key of at least 2048 bits or ECDSA
or ECDSA with a public key of at least 256 bits are widely studied with a public key of at least 256 bits are widely studied digital
digital signature algorithms that meet this requirement. signature algorithms that meet this requirement.
3.2. Certificate Status Checking 3.2. Certificate Status Checking
Several years ago, many browsers do not perform certificate status Several years ago, many browsers do not perform certificate status
checks by default. That is, browsers did not check whether the checks by default. That is, browsers did not check whether the
issuing CA has revoked the certificate unless the user explicitly issuing CA has revoked the certificate unless the user explicitly
adjusted a setting to enable this feature. This check can be made by adjusted a setting to enable this feature. This check can be made by
fetching the most recent certificate revocation list (CRL) RFC 5280 fetching the most recent certificate revocation list (CRL) RFC 5280
[RFC5280], or this check can use the Online Certificate Status [RFC5280], or this check can use the Online Certificate Status
Protocol (OCSP) RFC 6960 [RFC6960]. The location of the CRL or the Protocol (OCSP) RFC 6960 [RFC6960]. The location of the CRL or the
skipping to change at page 14, line 5 skipping to change at page 14, line 28
diginotar-public-report-version-1/ diginotar-public-report-version-1/
rapport-fox-it-operation-black-tulip-v1-0.pdf>. rapport-fox-it-operation-black-tulip-v1-0.pdf>.
[LC2012] Constantin, L., "Trustwave admits issuing man-in-the- [LC2012] Constantin, L., "Trustwave admits issuing man-in-the-
middle digital certificate; Mozilla debates punishment", middle digital certificate; Mozilla debates punishment",
February 2012, February 2012,
<http://www.computerworld.com/article/2501291/internet/ <http://www.computerworld.com/article/2501291/internet/
trustwave-admits-issuing-man-in-the-middle-digital- trustwave-admits-issuing-man-in-the-middle-digital-
certificate--mozilla-debates-punishment.html>. certificate--mozilla-debates-punishment.html>.
[LE] Internet Security Research Group, "Let's Encrypt", August
2015, <https://letsencrypt.org/>.
[PHBOB] Hallam-Baker, P., "OmniBroker Publication Protocol", [PHBOB] Hallam-Baker, P., "OmniBroker Publication Protocol",
draft-hallambaker-omnipublish-00 (work in progress), May draft-hallambaker-omnipublish-00 (work in progress), May
2014. 2014.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005, RFC 4034, DOI 10.17487/RFC4034, March 2005,
<http://www.rfc-editor.org/info/rfc4034>. <http://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<http://www.rfc-editor.org/info/rfc4035>. <http://www.rfc-editor.org/info/rfc4035>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ (TLS) Protocol Version 1.2", RFC 5246,
RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <http://www.rfc-editor.org/info/rfc5246>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, DOI Extensions: Extension Definitions", RFC 6066,
10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011,
<http://www.rfc-editor.org/info/rfc6066>. <http://www.rfc-editor.org/info/rfc6066>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <http://www.rfc-editor.org/info/rfc6698>. 2012, <http://www.rfc-editor.org/info/rfc6698>.
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", RFC 6797, DOI 10.17487/ Transport Security (HSTS)", RFC 6797,
RFC6797, November 2012, DOI 10.17487/RFC6797, November 2012,
<http://www.rfc-editor.org/info/rfc6797>. <http://www.rfc-editor.org/info/rfc6797>.
[RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification [RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification
Authority Authorization (CAA) Resource Record", RFC 6844, Authority Authorization (CAA) Resource Record", RFC 6844,
DOI 10.17487/RFC6844, January 2013, DOI 10.17487/RFC6844, January 2013,
<http://www.rfc-editor.org/info/rfc6844>. <http://www.rfc-editor.org/info/rfc6844>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP", Infrastructure Online Certificate Status Protocol - OCSP",
 End of changes. 19 change blocks. 
35 lines changed or deleted 55 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/