Web PKI OPPS B. Wilson
Internet Draft Digicert
Intended status: Informational S. Chokhani
Expires: April 2014 Cygnacom
R. Alden
Comodo
October 18, 2013
Browser processing of server certificates
draft-wilson-wpkops-browser-processing-00.txt
Abstract
This is one of a set of documents to define the operation of the Web
PKI. It describes common variations in browser behavior related to
processing server certificates.
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). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on ??.
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). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
Wilson, et al. Expires April 18, 2014 [Page 1]
Internet-Draft Browser processing of server certificates October 2013
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 18, 2014.
Copyright Notice
Copyright (c) 2013 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
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction...................................................3
1.1. Definitions...............................................3
1.2. Scope.....................................................4
1.3. Document Organization.....................................5
2. Certification Path Development.................................6
2.1. Basic Requirements........................................6
2.2. Additional Requirements...................................6
2.3. Browser Observations......................................6
3. Certification Path Validation..................................7
3.1. Basic Requirements (based on RFC 5280)....................7
3.2. Additional Requirements...................................7
3.3. Browser Observations......................................8
3.3.1. Name Constraints.....................................8
3.3.2. Validity Period......................................8
3.3.3. Areas for Future Work................................9
4. SERVER CERTIFICATE PROCESSING..................................9
4.1. Subject Names............................................10
4.2. Wildcard character.......................................11
4.3. Key Usage Extension......................................11
4.4. Extended Key Usage.......................................12
5. Browser Human Interface (Visual) Indicators...................12
5.1. Visual indicators........................................12
5.2. Positive visual indicators...............................12
5.3. Negative visual indicators...............................12
Wilson, et al. Expires April 18, 2014 [Page 2]
Internet-Draft Browser processing of server certificates October 2013
5.4. Message boxes, dialog boxes and error pages..............12
5.5. Certificate viewers......................................13
5.6. Certification Path Development and Validation Indication.13
5.7. Configurables............................................14
6. IANA Considerations...........................................14
7. Security Considerations.......................................14
8. Normative References..........................................14
1. Introduction
This document defines the current processing behaviors of browsers
with respect to SSL/TLS session establishment between a server and a
browser, including signature verification, certificate parsing, chain
processing, revocation checking, and other processes described in RFC
5280 and the SSL/TLS protocol.
The information presented in this document is based on user
experience and should not be construed as exhaustive. In other
words, it is based on observed behavior and is not based on any
comprehensive testing. The product vendors and reviewers are
encouraged to provide additional information that sheds light on the
observations made in this document or to provide additional
observations.
This document does not address future changes to the implemented
trust model.
1.1. Definitions
PKI terminology is as defined in RFC 5280. Other definitions are
defined below for interpretation of this document.
Blacklisting - A concept where a browser does not trust a public key
in the blacklist. A trust anchor, intermediate CA or TLS Server
public key can be included in the blacklist. When a public key
appears in the black list, the browser should not trust that public
key regardless of where the public key appears in the certification
path (be it trust anchor, CA certificate or the TLS Server
certificate). Some browsers support the blacklisting of public keys.
Since blacklisting is a revocation mechanism, discussion of
blacklisting is outside the scope of this document.
Wilson, et al. Expires April 18, 2014 [Page 3]
Internet-Draft Browser processing of server certificates October 2013
Bypassable error - A behavior in which the browser detects an
abnormal condition and asks the user whether to proceed with (i.e.
click-through to) the SSL/TLS connection.
Fatal error - A behavior in which the browser detects an abnormal
condition and halts (or technically cannot complete) session
negotiation and drops the connection or otherwise blocks the user
from continuing (also referred to as "hard fail").
Internationalized Name - The Punycode-encoded ASCII representation of
Unicode characters prefaced with the ASCII Compatible Encoding (ACE)
prefix, xn--.
Name mismatch - A condition detected by a browser in which no name in
the common name or subject alternative name for the subject in the
certificate matches the hostname sought by the client (i.e. the
client's reference identity - usually a Fully Qualified Domain Name -
is not in the certificate).
Pinned - A condition in which the association between two or more
aspects of the entity-public-key relationship (e.g. server name,
public key, CA, certificate) are configured and set in the browser
before initiation of a TCP connection.
Stapled - A condition in which information related to the server's
certificate (e.g. OCSP response) is delivered by the server to the
client as part of the SSL/TLS handshake, and not by direct
communication with the issuing CA. Not all browsers request stapled
responses. Since OCSP stapling is directly related to revocation,
discussion of OCSP stapling is outside the scope of this document.
Visual indicator - A behavior in which the browser changes the
color(s) and/or intensity of pixels on a screen in the browser chrome
to indicate a changed condition. Visual indicators also include
error pages, pop-up dialogs, and warning messages.
Wildcard character - An asterisk - * (Unicode 2A).
1.2. Scope
The scope of this document excludes revocation checking. Revocation
checking is addressed in another document.
The scope of the initial version of this document excludes the
browser behavior for client authentication TLS. For example, a
legitimate client certificate may not be presented or selected under
Wilson, et al. Expires April 18, 2014 [Page 4]
Internet-Draft Browser processing of server certificates October 2013
certain circumstances. One case in point is when the browser and the
TLS Server have different trust anchors.
The scope of the initial version of this document excludes dealing
with the following lesser-used X.509 certificate extensions: issuer
alternative name; subject directory attribute; policy constraint;
inhibit any policy; and subject information access.
In addition, due to revocation checking being out of scope, the
discussion of the following extensions is out of scope: CRL
Distribution Point; Freshest CRL; and OCSP field in the Authority
Information Access extension. Discussion of OCSP stapling is outside
the scope of this document.
The initial focus of this paper is on the following browsers and
platforms:
| | IExplorer | Firefox | Opera | Chrome | Safari |
| Windows XP | X | X | X | X | X |
| Windows 7+ | X | X | X | X | X |
| Mac OS X | N/A | X | N/A | X | X |
| Linux | N/A | X | X | X | N/A |
Additional platforms such as Android will be added.
1.3. Document Organization
This Section 1 has provided the introduction.
Section 2 describes the requirements for certification path
development in order to establish trust in the server public key.
Section 2 also contains the nuances of the popular browsers in terms
of their ability to meet these requirements and security implications
of these nuances.
Section 3 describes requirements for certification path validation in
order to establish trust in the server public key. Section 3 also
contains the nuances of the popular browsers in terms of their
ability to meet these requirements and security implications of these
nuances.
Section 4 describes the requirements for processing the Server
certificate. Section 4 also contains the nuances of the popular
browsers in terms of their ability to meet these requirements and
security implications of these nuances.
Wilson, et al. Expires April 18, 2014 [Page 5]
Internet-Draft Browser processing of server certificates October 2013
Section 5 describes the browser user interface indicators.
Section 6 lists IANA Considerations.
Section 7 summarizes Security Considerations discussed throughout
this document.
Section 8 contains references.
2. Certification Path Development
2.1. Basic Requirements
This section lists the resources that a browser should be able to use
for the development of certification path.
A browser should only use its trust anchor store to determine the
trust anchor for a Server's certification path.
A browser should be able to use its local cache of certificates for
certification path development.
A browser should be able to use the certificates sent by the TLS
Server in the TLS handshake for certification path development.
A browser should be able to use the caIssuers field in the Authority
Information Access extension in order to build the certification
path. Specifically, the browser should be able to use unsecure HTTP
and unsecure LDAP method. The browser should be able to handle HTTP
single certificate payload and multiple certificate payload as
described in RFC 5280. The browser should be able to handle LDAP
pointer to caCertificate and crossCertificatePair attribute as
described in RFC 5280.
2.2. Additional Requirements
None
2.3. Browser Observations
We have observed that Firefox on any of the platforms listed in the
scope section does not use caIssuers field in the Authority
Information Access extension. This may result in undesired effect of
rejecting a valid certificate since a path to the certificate was not
Wilson, et al. Expires April 18, 2014 [Page 6]
Internet-Draft Browser processing of server certificates October 2013
built. When a path cannot be built, Firefox gives a negative visual
indication as a bypassable error as described in Section 5.6.
Inputs are sought from the working group participants and vendors to
identify additional sources of certificates and additional
exceptions.
3. Certification Path Validation
3.1. Basic Requirements (based on RFC 5280)
A browser should only use one or more trust anchors from its trust
anchor store for certification path validation.
A browser should perform certification path validation in accordance
with Section 6 of RFC 5280.
3.2. Additional Requirements
The public exponent for all RSA keys in SSL/TLS certificates must be
an odd number and cannot be "1."
None of the browsers check the public exponent to verify that it is
odd and it is not one.
After December 31, 2013, all public RSA keys must be at least 2048
bits.
Currently, if an RSA key size is less than 900 bits, Opera presents
the user with a negative visual indicator and a bypassable dialog.
If the RSA key size is greater 900 bits but less than 1,000 bits it
removes the padlock indicator.
Microsoft allows manual configuration of minimum key lengths by
editing the registry, using a certificate utility or other
mechanisms. See http://support.microsoft.com/kb/2661254. Thus, IE
and Chrome on Windows platform can enforce the 2,048 bit requirement.
It is not known if Firefox on Windows or other browsers listed in the
scope section address the 2,048 bit key size requirement.
Wilson, et al. Expires April 18, 2014 [Page 7]
Internet-Draft Browser processing of server certificates October 2013
3.3. Browser Observations
3.3.1. Name Constraints
We have observed that Safari does not process name constraints.
Thus, if the name constraints extension is non-critical, Safari
provides no visual indicator of any anomaly. If the name constraint
is critical, Safari will reject the certification path due to an
unrecognized critical extension, but will give the user a choice to
proceed with the connection.
The following additional observations are made with respect to name
constraint violations:
. Microsoft IE on Windows platforms enforces name constraints (in
both the CN and in the Subject Alternative Name), but gives the
user a choice to proceed with the connection.
. Firefox on all platforms enforces name constraints (in both the CN
and in the Subject Alternative Name) and does not permit the user
to proceed.
. Chrome on the Windows platform enforces name constraints (in both
the CN and in the Subject Alternative Name), and does not permit
the user to proceed.
. Chrome on Mac OSX seems to follow the behavior of Safari in not
recognizing critical extension and does not permit the user to
proceed.
. Chrome on Linux enforces name constraints in the Subject
Alternative Name and does not enforce the name constraint on the
CN. Furthermore, in the case of name constraint failure on Linux,
Chrome gives the user a choice to proceed with the connection.
3.3.2. Validity Period
The browser may display a warning indicating that a certificate in
the certification path is outside of its validity interval or
expired. The user may be given the choice to proceed to the content.
The trust indicator may be suppressed. In some cases, there may be
no warning, but the trust indicator is simply suppressed.
Wilson, et al. Expires April 18, 2014 [Page 8]
Internet-Draft Browser processing of server certificates October 2013
When the browser detects that the current system time is beyond the
validity period of a certificate in the certification path, a warning
is displayed. Some browsers indicate that a certificate has expired
and present a bypassable error asking whether or not to proceed or
allowing the user to view the certificate with a certificate viewer.
Some browsers also alert the user to the possibility that the error
is not caused by an expired certificate, but by incorrect system
time, and display the system time. For example, "Your computer's
clock currently indicates it is Monday, October 14, 2013, 4:00 AM.
Does this look right? If not, you should correct the error and
refresh this page."
We plan to enhance this section with additional and more complete
information in terms of validity period for certificates in the
certification path (i.e., handling expired certificates).
3.3.3. Areas for Future Work
Future work will include a review of the basic constraints extension.
We also plan to discuss how pinning interplays with certification
path development and validation. Some browsers support the pinning
of public keys.
Most browsers perform certificate policy extension processing
appropriately. We have not examined if the policy mapping, inhibit
any policy, and policy constraints extensions are processed
correctly. Most browsers as a result of certificate policies
extension processing provide a visual indication when they detect
that all the certificates in the certification path contains the
correct policy OID for Extended Validation. We plan to quantify this
characteristics for the browsers listed in the scope section.
Inputs are sought from the working group participants and vendors to
identify additional path validation rules and additional exceptions.
4. Server certificate processing
This section focuses on how the browsers use Server certificates.
While some of these checks should be part of certification path
validation, these checks are discussed here as part of TLS Server
certificate processing in order to emphasis how the browsers use the
information in TLS Server certificates.
Wilson, et al. Expires April 18, 2014 [Page 9]
Internet-Draft Browser processing of server certificates October 2013
4.1. Subject Names
SSL/TLS certificates contain at least one subject name to bind the
public key in the certificate with the server that possesses
corresponding private key. The subject name appears in the subject
alternative name extension as dNSName name type and often in the
common name field. The latter practice of using the common name was
deprecated by RFC 2818. A browser processes the subject name in the
certificate to determine whether it matches the expected server name.
Browsers are known to successfully connect with servers whose DNS
name appears in the Subject CN only and when subject alternative name
extension is absent. As discussed earlier, the enforcement of name
constraint on the DNS name appearing in CN varies with the browser.
Browser processing of internationalized names in subject names of
certificates allow browsers to either process the Internationalized
Name back into Unicode or display the Internationalized Name in ASCII
as xn--.
In addition to the use of names for SSL/TLS processing, certificate
distinguished name fields may provide further identification of the
subject through domain-component naming and X.500 naming (e.g.
country, organization, etc.). When name constraints are used on the
DN, the entire subject distinguished name (not just the CN) needs to
pass the name constraints.
Section 3.1 of RFC 2818 states that in the case of a certificate name
mismatch, a browser "MUST either notify the user (clients MAY give
the user the opportunity to continue with the connection in any case)
or terminate the connection with a bad certificate error."
Typical browser behavior will provide a message box that reads,
"Security Error: Domain Name Mismatch" with treatment as a bypassable
error with options such as "View Certificate," "OK" or "Cancel."
Some browsers still prioritize common name processing over subject
alternative name processing even though use of the common name has
been deprecated. Another scenario is when the common name is not one
of the names listed as a subject alternative name. When either of
these occur, a browser might throw a domain name mismatch even though
the name to be used for the SSL/TLS session is in either the common
name field or the subject alternative name of the certificate but not
in both.
Most browsers display a warning, but allow the user to proceed to
viewing the contents of the web site.
Wilson, et al. Expires April 18, 2014 [Page 10]
Internet-Draft Browser processing of server certificates October 2013
Some systems, such as Keychain Access in Apple OS X, allow the user
to override certificate name mismatches by explicitly trusting a
certificate for a particular domain name that is not contained in the
certificate.
4.2. Wildcard character
Some browsers support a wildcard character in the leftmost position.
We plan to quantify wildcard behaviors for the browsers listed above
in the scope section.
4.3. Key Usage Extension
The browsers should use the server public key for key encryption, key
agreement or digital signature verification depending on the TLS
cipher suite selected. Below are a few examples:
. TLS_RSA_WITH_AES_128_CBC_SHA: The Server key is used for encrypting
the master secret and thus, the Server certificate should have the
key encipherment bit set if the Server certificate contains the key
usage extension.
. TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: The Server key is used for
authentication of ephemeral DH key thus, the Server certificate
should have the digital signature bit set if the Server certificate
contains the key usage extension.
. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: The Server key is used for
authentication of ephemeral DH key thus, the Server certificate
should have the digital signature bit set if the Server certificate
contains the key usage extension.
. TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA: The Server key is used for
ECDH key agreement/exchange. Thus, the Server certificate should
have the key agreement bit set if the Server certificate contains
the key usage extension.
We plan to add information how the browsers adhere to these
requirements.
Wilson, et al. Expires April 18, 2014 [Page 11]
Internet-Draft Browser processing of server certificates October 2013
4.4. Extended Key Usage
If the extended key usage extension is present in the Server
certificate, it should have one of the following OIDs: Server
Authentication or anyExtendedKeyUsage.
We plan to add information how the browsers adhere to this
requirement.
5. Browser Human Interface (Visual) Indicators
This section describes the typical kinds of browser/OS behaviors when
processing SSL/TLS certificates.
5.1. Visual indicators
The most commonly used visual indicator of SSL/TLS security is the
padlock icon. Variations of the icon include the closed padlock, the
open padlock, and the padlock superimposed with a red slash or X.
5.2. Positive visual indicators
Commonly used visual indicators that are considered positive
indications of web site authentication or security are a closed
padlock icon, use of the color green, and the display of additional
information about issuer or subject of the certificate.
Some of these indicators are called EV indicators because of their
use when displaying a website that presents an Extended Validation
certificate to the browser.
5.3. Negative visual indicators
Visual indicators used by browsers to convey warnings include use of
the color red, a slash (/) or X across a positive indicator (a red
slash or X across the padlock icon and/or the "https"), a message
box, or the removal of a positive indicator (e.g. removal of the
padlock).
5.4. Message boxes, dialog boxes and error pages
A message box is generally used not just as negative indicator, but
also to convey more context-specific guidance to the end user. They
can provide warnings or explain why an SSL/TLS connection cannot be
Wilson, et al. Expires April 18, 2014 [Page 12]
Internet-Draft Browser processing of server certificates October 2013
completed. Dialog boxes are used when the browser encounters an
uncertain environmental condition (for gray areas where the security
threat is not black or white). Some dialog boxes provide a simple
binary choice (a) proceed or (b) "get me out of here." This type of
browser behavior can be referred to as a "single bypassable error."
Other dialog boxes can exhibit more complex behavior, such as
multiple branches, additional nested bypassable errors, helpful
information, and decisions to be made by the user.
An error page is another mechanism used by browsers to provide
certificate-related information to users.
Some error messages provide an option to view the certificate.
Clicking on the offer launches the browser's certificate viewer.
5.5. Certificate viewers
Most browsers provide a means to examine the SSL/TLS certificate of
the web site and the chain of certificates leading up to the root
certificate. Some browsers block viewing the certificate in
circumstances determined by the browser to be insecure.
5.6. Certification Path Development and Validation Indication
If the certification path cannot be validated, some browsers will
alert the user about the inability to complete the server's
certificate chain.
Most browsers will provide a warning when a certificate is signed by
an unknown CA. The warning usually states that an unknown authority
issued the certificate. Additional warnings include that if the user
has connected to the site previously without errors, it may mean an
attacker is trying to impersonate the site and intercept confidential
communications. Users are advised not to continue unless they are
sure.
With some browsers, this error can be bypassed for the session or the
user can explicitly trust the certificate permanently. When a
certification path fails because the issuer is not in the
certificate/key store, most browsers will still allow the user to
explicitly trust the certificate or the issuing CA. The number of
steps required to explicitly trust an untrusted certificate vary from
browser to browser.
Wilson, et al. Expires April 18, 2014 [Page 13]
Internet-Draft Browser processing of server certificates October 2013
5.7. Configurables
Most browsers provide the ability to configure certain certificate-
related behaviors. In Mozilla Firefox a user can change some options
using Tools -> Options -> Advanced -> Certificates or by typing
"about:config" in the address window and editing security
preferences. Changes in Microsoft's Internet Explorer settings can
be made under Tools -> Internet options -> Advanced -> Security or by
editing the registry. In Apple OS X, configuration changes are
performed by accessing preferences for certificates in the Keychain,
but since the only configurations available are related to revocation
checking (CRLs and OCSP), they are outside the scope of this draft.
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
The operations described above exhibit several vulnerabilities that
could adversely affect the reliability of the authentication and
security provided by SSL/TLS certificates. These vulnerabilities
have been discussed throughout this RFC and are summarized below:
These items will be provided when the draft becomes more stable.
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu,
"Internet X.509 Public Key Infrastructure Certificate Policy and
Certification Practices Framework", RFC 3647, Nov 2003.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile", RFC 5280,
May 2008.
[RFC6797] Hodges, J., Jackson, C., and Barth, A., "HTTP Strict
Transport Security (HSTS)", RFC 6797, November 2012.
[W3C-WSC] Web Security Context: User Interface Guidelines, W3C
Recommendation 12 August 2010.
Wilson, et al. Expires April 18, 2014 [Page 14]
Internet-Draft Browser processing of server certificates October 2013
Authors' Addresses
Ben Wilson
Email: ben@digicert.com
Santosh Chokhani
Email: schokhani@cygnacom.com
Robin Alden
Email: robin@comodo.com
Wilson, et al. Expires April 18, 2014 [Page 15]