< draft-wilson-wpkops-browser-processing-01.txt   draft-wilson-wpkops-browser-processing-02.txt >
Web PKI OPPS B. Wilson Web PKI OPPS B. Wilson
Internet Draft Digicert Internet Draft Digicert
Intended status: Informational S. Chokhani Intended status: Informational S. Chokhani
Expires: December 2014 Cygnacom Expires: January 2015 Cygnacom
R. Alden R. Alden
Comodo Comodo
June 9, 2014 July 22, 2014
Browser processing of server certificates Browser processing of server certificates
draft-wilson-wpkops-browser-processing-01.txt draft-wilson-wpkops-browser-processing-02.txt
Abstract Abstract
This is one of a set of documents to define the operation of the Web 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 PKI. It describes common variations in browser behavior related to
processing server certificates. processing server certificates.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 December 9, 2014. This Internet-Draft will expire on January 23, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 21 skipping to change at page 2, line 21
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
1.1. Definitions...............................................3 1.1. Definitions...............................................3
1.2. Scope.....................................................4 1.2. Scope.....................................................4
1.3. Document Organization.....................................5 1.3. Document Organization.....................................5
2. Certification Path Development.................................6 2. Certification Path Development.................................6
2.1. Basic Requirements........................................6 2.1. Basic Requirements........................................6
2.2. Additional Requirements...................................7 2.2. Additional Requirements...................................7
2.3. Browser/Cryptolibrary Observations........................7 2.3. Browser/Cryptolibrary Observations........................7
2.4. Security Considerations...................................7 2.4. Security Considerations...................................8
2.5. Areas for Future Work.....................................8 2.5. Areas for Future Work.....................................8
3. Certification Path Validation..................................8 3. Certification Path Validation..................................9
3.1. Basic Requirements (based on RFC 5280)....................8 3.1. Basic Requirements (based on RFC 5280)....................9
3.2. Additional Requirements...................................9 3.2. Additional Requirements..................................10
3.3. Browser Observations......................................9 3.3. Browser Observations.....................................10
3.3.1. Path Validation......................................9 3.3.1. Path Validation.....................................10
3.3.1.1. Signature Verification..........................9 3.3.1.1. Signature Verification.........................10
3.3.1.2. Name Constraints................................9 3.3.1.2. Name Constraints...............................11
3.3.2. Current Time within Validity Period.................10 3.3.2. Current Time within Validity Period.................12
3.3.3. Public Key Parameters...............................11 3.3.3. Public Key Parameters...............................12
3.3.3.1. Sizes..........................................11 3.3.3.1. Sizes..........................................12
3.3.3.2. Algorithms and Cipher Suites...................11 3.3.3.2. Algorithms and Cipher Suites...................13
3.4. Security Considerations..................................12 3.4. Security Considerations..................................13
3.5. Areas for Future Work....................................12 3.5. Areas for Future Work....................................13
4. Server certificate processing.................................12 4. Server certificate processing.................................14
4.1. Subject Names............................................13 4.1. Subject Names............................................14
4.2. Wildcard character.......................................14 4.2. Wildcard character.......................................15
4.3. Key Usage Extension......................................14 4.3. Key Usage Extension......................................16
4.4. Security Considerations..................................15 4.4. Security Considerations..................................16
4.5. Areas for Future Work....................................15 4.5. Areas for Future Work....................................16
5. Browser Human Interface (Visual) Indicators...................15 5. Browser Human Interface (Visual) Indicators...................17
5.1. Visual indicators........................................15 5.1. Visual indicators........................................17
5.2. Positive visual indicators...............................16 5.2. Positive visual indicators...............................17
5.3. Negative visual indicators...............................16 5.3. Negative visual indicators...............................17
5.4. Message boxes, dialog boxes and error pages..............16 5.4. Message boxes, dialog boxes and error pages..............18
5.5. Certificate viewers......................................16 5.5. Certificate viewers......................................18
5.6. Certification Path Development and Validation Indication.17 5.6. Certification Path Development and Validation Indication.18
5.7. Configurables............................................17 5.7. Configurables............................................19
5.8. Security Considerations..................................17 5.8. Security Considerations..................................19
5.9. Areas for Future Work....................................18 5.9. Areas for Future Work....................................19
6. IANA Considerations...........................................18 6. IANA Considerations...........................................19
7. Security Considerations.......................................18 7. Security Considerations.......................................20
8. Normative References..........................................18 8. Normative References..........................................20
1. Introduction 1. Introduction
This document reviews the current processing behaviors of This document reviews the current processing behaviors of
cryptolibraries, and the browsers they support, with respect to cryptolibraries, and the browsers they support, with respect to
SSL/TLS session establishment between a server and a browser, SSL/TLS session establishment between a server and a browser,
including signature verification, certificate parsing, chain including signature verification, certificate parsing, chain
processing, and other non-revocation-checking processes described in processing, and other non-revocation-checking processes described in
RFC 5280 and the SSL/TLS protocol. RFC 5280 and the SSL/TLS protocol.
skipping to change at page 6, line 29 skipping to change at page 6, line 29
name in a certificate and the named subject's public key are name in a certificate and the named subject's public key are
appropriately bound by a CA that chains up to the public key of a appropriately bound by a CA that chains up to the public key of a
trust anchor used by the browser. The path validation algorithm does trust anchor used by the browser. The path validation algorithm does
this by processing a sequence of certificates that support that this by processing a sequence of certificates that support that
binding. While RFC 5280 requires that browsers process certification binding. While RFC 5280 requires that browsers process certification
chains in accordance with the path validation algorithm, it does not chains in accordance with the path validation algorithm, it does not
specify a procedure by which a browser should construct that specify a procedure by which a browser should construct that
certification path. (RFC 4158 provides additional guidance on certification path. (RFC 4158 provides additional guidance on
factors to consider when building a certification path.) factors to consider when building a certification path.)
Browsers have or obtain root certificates used to identify the trust Root stores are not fixed. Not only can they be extended via
anchors for a server's certification path. Candidate trust anchors automatic download, but enterprises can add and remove roots through
are available locally in root stores (maintained by the browser, group policies, and most end users can manually add or remove root
cryptolibrary, or operating system) or via automatic download from a certificates. Browsers have or obtain root certificates used to
remote system. identify the trust anchors for a server's certification path.
Candidate trust anchors are available locally in root stores
(maintained by the browser, cryptolibrary, or operating system) or
via automatic download from a remote system. Most systems also allow
users to further adjust trust anchors with other configuration
changes, such as allowing users to enable or disable potential key
usages by checking or unchecking them for each certificate found in
the root store. For instance, Firefox provides three options
(identify websites, identify mail users, and identify software
makers), while the Apple key chain provides ten key usages to select
from, and Microsoft offers nearly fifty.
Browsers also use their local caches of certificates for Browsers also use their local caches of certificates for
certification path development. certification path development.
Browser use the certificates sent by the TLS Server in the TLS Browser use the certificates sent by the TLS Server in the TLS
handshake for certification path development. handshake for certification path development.
Some browsers use the caIssuers field in the Authority Information Some browsers use the caIssuers field in the Authority Information
Access extension of a certificate to obtain, over unsecure HTTP or Access extension of a certificate to obtain, over unsecure HTTP or
LDAP, the intermediary CA's certificate in order to build the LDAP, the intermediary CA's certificate in order to build the
certification path. Some browsers are able to process LDAP certification path. Some browsers are able to process LDAP
pointers to caCertificate or crossCertificatePair attributes and also pointers to caCertificate or crossCertificatePair attributes and also
handle HTTP single certificate payloads and multiple certificate handle HTTP single certificate payloads and multiple certificate
payloads, as described in RFC 5280. payloads, as described in RFC 5280.
Assuming that the browser has obtained a set of certificates that can
be used to form a certificate chain, section 4.2.1 of RFC 5280 sets
forth how the authorityKeyIdentifier and the subjectKeyIdentifier
standard extensions can also be used to select appropriate
certificate when multiple choices exist. Most browsers process these
extensions as part of certification path construction. Similarly,
most browsers also match the issuer name with the subject name of the
issuer's certificate as the chain is constructed up to the trust
anchor.
2.2. Additional Requirements 2.2. Additional Requirements
None None
2.3. Browser/Cryptolibrary Observations 2.3. Browser/Cryptolibrary Observations
All browsers and cryptolibraries examined were able to perform All browsers and cryptolibraries examined were able to perform
certificate path validation when the server presented the browser certificate path validation when the server presented the browser
with a properly ordered certificate chain, where the first certificate with a properly ordered certificate chain--where the first certificate
was the end entity's "leaf" certificate, followed by the issuer CA's was the end entity's "leaf" certificate, followed by the issuer CA's
certificate. However, because a misconfigured server might present a certificate. However, because a misconfigured server might present a
root certificate in the middle of a chain, some cryptolibraries are root certificate in the middle of a chain, some cryptolibraries are
able to construct certificate paths by re-ordering certificates able to construct certificate paths by re-ordering certificates
presented by a server. (There are free tools available to test presented by a server. (There are free tools available to test
whether a server is presenting a complete and well-ordered chain.) whether a server is presenting a complete and well-ordered chain.)
Also, however, some servers are misconfigured and only provide the Also, however, some servers are misconfigured and only provide the
leaf certificate and not a necessary intermediate CA certificate. In leaf certificate and not a necessary intermediate CA certificate. In
these cases, a browser is unable to determine whether the certificate these cases, a browser is unable to determine whether the certificate
skipping to change at page 7, line 39 skipping to change at page 8, line 19
intermediate CAs every time. intermediate CAs every time.
Some leaf certificates have a caIssuers field in the Authority Some leaf certificates have a caIssuers field in the Authority
Information Access extension. The purpose of the caIssuers field is Information Access extension. The purpose of the caIssuers field is
to provide a URI pointer to the Intermediate CA's certificate. All to provide a URI pointer to the Intermediate CA's certificate. All
browsers except for Firefox are able to use the caIssuers AIA to browsers except for Firefox are able to use the caIssuers AIA to
obtain the intermediate certificate and construct a chain. Because obtain the intermediate certificate and construct a chain. Because
NSS does not process the caIssuers AIA, Mozilla Firefox is unable to NSS does not process the caIssuers AIA, Mozilla Firefox is unable to
construct a chain. When a path cannot be built, Firefox presents a construct a chain. When a path cannot be built, Firefox presents a
negative visual indication as a bypassable error as described in negative visual indication as a bypassable error as described in
Section 5.6. However, Chrome, which uses NSS, has an http-fetching Section 5.6. It is the authors' understanding that the Mozilla
ability it uses to obtain missing intermediate CA certificates. community intentionally chose this behavior instead of processing the
caIssuers AIA because Firefox will alert server administrators about
defective chains and they can install missing CA certificates absent
from certificate chains. However, Chrome, which uses NSS, has chosen
to implement its own http-fetching ability to obtain missing
intermediate CA certificates.
2.4. Security Considerations 2.4. Security Considerations
A browser's inability to create a path to a trust anchor leads to A browser's inability to create a path to a trust anchor leads to
uncertainty on the part of end users and may leave them more uncertainty on the part of end users and may leave them more
vulnerable to man-in-the-middle attacks because they are unable to vulnerable to man-in-the-middle attacks because they are unable to
determine whether the public key presented corresponds to the key determine whether the public key presented corresponds to the key
pair of the server that they intend to reach. pair of the server that they intend to reach.
2.5. Areas for Future Work 2.5. Areas for Future Work
Inputs are sought from the working group participants and vendors to Inputs are sought from the working group participants and vendors to
identify additional methods used and to gain understanding on browser identify additional methods used and to gain understanding on browser
handling of misconfigured server-provided chains when an intermediate handling of misconfigured server-provided chains when an intermediate
CA certificate is available locally to the client. CA certificate is available locally to the client.
3. Certification Path Validation 3. Certification Path Validation
3.1. Basic Requirements (based on RFC 5280) 3.1. Basic Requirements (based on RFC 5280)
A browser should only use one or more trust anchors from its root Browsers use one or more trust anchors from their root stores for
store for certification path validation. certification path validation.
A browser should perform certification path validation in accordance
with Section 6 of RFC 5280, including verifying that the signature on
the certificate, issuer name, policies, and extensions match given
parameters.
Much has been written on the process of signature verification, which The primary mechanism used to perform certification path validation
requires processing the tbsCertificate and signatureValue fields in accordance with Section 6 of RFC 5280 is verifying the signature
using the signature algorithm and issuer public key to verify that on the certificate. Much has been written on the process of
the certificate was properly signed. A browser should be able to signature verification, which requires processing the tbsCertificate
perform the signature verification process using a variety of and signatureValue fields using the signature algorithm and issuer
signature algorithms. public key to verify that the certificate was properly signed. DSA,
RSA, and ECDSA are common digital signature algorithms used to sign
certificates in conjunction with hashing algorithms such as MD5,
RIPEMD-160, SHA-1, SHA-256, SHA-384, SHA-512, and Whirlpool. Thus, a
browser might need to be able to perform the signature verification
process using a variety of signature and hashing algorithms.
A browser should correctly process the following extensions: The following extensions described in RFC 5280 are also relevant to
certification path validation:
- basicConstraints extension, including the enforcement of path . The basicConstraints extension indicates whether the
length constraint based on pathLength field in the certificate is for a CA or an end entity, and if for a CA, it
basicConstraints extension. can include a path length constraint intended to limit the
maximum depth for the certification path from the certificate
(i.e. the allowed number of subordinate CA levels between it and
an end entity certificate). Presumably, a browser would check
whether the issuer's certificate included the basicConstraints
extension where CA=true and whether the certification path
complied with any path length constraint in the basicConstraints
extension.
- Key usage extension to ensure that the intermediate CA . The key usage extension is a bit string of 9 bits (0 through 8)
certificates have the certificate signing bit set. that indicates the intended key usage. When Bit 5 is enabled,
it indicates that the public key in the intermediate CA
certificate may be used to validate signatures on certificates.
Presumably a browser would examine whether a CA's certificate
signing bit was set.
The name constraints extension in a CA certificate should be honored . The name constraints extension is a multi-valued field in a CA
by processing the subject DN and subject alternative names in certificate that indicates the intended scope of certificates,
certificates issued by the CA. (Section 4.2.1.10 and Section 6 of in terms of name spaces, that are either allowed or prohibited
RFC 5280.) to be issued by that CA. This directive is honored by the
browser processing the subject DN and subject alternative names
in certificates issued by the CA and determining whether the
domain names in those subject fields fall within any stated
restriction (e.g. a permitted or an excluded name subtree).
(See Section 4.2.1.10 and Section 6 of RFC 5280.)
3.2. Additional Requirements 3.2. Additional Requirements
None.
3.3. None. Browser Observations 3.3. Browser Observations
3.3.1. Path Validation 3.3.1. Path Validation
As mentioned in Section 2.3, online tools can be used to ensure that As mentioned in Section 2.3, online tools can be used to ensure that
servers are presenting complete, well-ordered chains, and this should servers are presenting complete, well-ordered chains, and server
be done to ensure the most efficient certificate path processing. administrators should do this to ensure the most efficient
However, when a misconfigured server delivers a shuffled group of certificate path processing. When a misconfigured server delivers a
certificates, some platforms are unable to perform certification path shuffled group of certificates, some platforms are unable to perform
validation, while other platforms are able to perform validation certification path validation, while other platforms are able to
because they implement a more robust path-building process. perform validation because they implement a more robust path-building
process.
3.3.1.1. Signature Verification 3.3.1.1. Signature Verification
A number of anomalous conditions arise with signature verification A number of anomalous conditions arise with signature verification
processing: the signature might be plainly erroneous, the signature processing - the signature might be plainly erroneous, the signature
algorithm might be incorrect, or the browser might not be able to algorithm might be incorrect, the browser might not be able to
process the algorithm. process the algorithm, or the browser might disallow the certificate
because its signature or hashing algorithm is too weak or susceptible
to compromise.
When a browser encounters a signature error, it presents an error When a browser encounters a signature error, it presents an error
message such as "invalid signature," "invalid certificate", or message such as "invalid signature," "invalid certificate", or
"problem with certificate." Browsers exhibit a variety of differing "problem with certificate." Browsers exhibit a variety of differing
behaviors. For example, Firefox, Chrome, and Opera exhibit a blocking behaviors. For example, Firefox, Chrome, and Opera exhibit a blocking
behavior that prevents the user from proceeding to the site. Opera behavior that prevents the user from proceeding to the site. Opera
offers a choice between "Back to safety" or "Help me understand". offers a choice between "Back to safety" or "Help me understand".
Firefox and Chrome offer "try again" and "reload," as respective Firefox and Chrome offer "try again" and "reload," as respective
options. However, Safari and Chrome on OS X and Internet Explorer on options. However, Safari and Chrome on OS X and Internet Explorer on
Windows all allow the user to click through this signature validation Windows all allow the user to click through this signature validation
problem as a Bypassable Error. problem as a Bypassable Error.
Some browsers are able to detect certificates that are signed with
MD5 and block their use. For instance, Chrome provides this message,
"The site's security certificate is signed using a weak signature
algorithm!" Opera's notice states, "Invalid Server Certificate" and
offers "Back to Safety" and "Help Me Understand." Similarly, other
browsers present notices similar to those in the preceding paragraph.
3.3.1.2. Name Constraints 3.3.1.2. Name Constraints
We have observed that Chrome and Safari on Mac OSX do not process We have observed that Chrome and Safari on Mac OSX do not process
name constraints. When name constraints are present and marked name constraints. When name constraints are present and marked
critical, Chrome presents a message stating, "Something is critical, Chrome presents a message stating, "Something is
interfering with your secure connection." However, if the name interfering with your secure connection ...." However, if the name
constraints extension is not marked "critical"," then both Chrome and constraints extension is not marked "critical", then both Chrome and
Safari allow the connection to proceed with no visual indicator of Safari allow the connection to proceed with no visual indicator of
any anomaly. If the name constraint is critical, Safari will reject any anomaly. If the name constraint is critical, Safari will reject
the certification path due to an unrecognized critical extension the certification path due to an unrecognized critical extension
(even if the subject DN or the subject alternative name is allowed by (even if the subject DN or the subject alternative name is allowed by
the name constraint rule), but it gives the user a choice to proceed the name constraint rule), but it gives the user a choice to proceed
with the connection. Chrome on Mac OS X blocks the user with a with the connection. Chrome on Mac OS X blocks the user with a
"reload" button for all name constraints marked critical. "reload" button for all name constraints marked critical.
The following additional observations are made with respect to name The following additional observations are made with respect to name
constraints: constraints:
- Microsoft IE on Windows platforms enforces name constraints (in . Microsoft IE on Windows platforms enforces name constraints (in
both the CN and in the Subject Alternative Name), but gives the both the CN and in the Subject Alternative Name), but gives the
user a choice to proceed with the connection. user a choice to proceed with the connection.
- Firefox on all platforms enforces name constraints (in both the CN . Firefox on all platforms enforces name constraints (in both the CN
and in the Subject Alternative Name) and does not permit the user and in the Subject Alternative Name) and does not permit the user
to proceed. to proceed.
- Chrome on the Windows platform enforces name constraints (in both . Chrome on the Windows platform enforces name constraints (in both
the CN and in the Subject Alternative Name), and does not permit the CN and in the Subject Alternative Name), and does not permit
the user to proceed. the user to proceed.
- Chrome on Linux enforces name constraints in the Subject . Chrome on Linux enforces name constraints in the Subject
Alternative Name and does not enforce the name constraint on the Alternative Name and does not enforce the name constraint on the
CN. Furthermore, in the case of name constraint failure on Linux, CN. Furthermore, in the case of name constraint failure on Linux,
Chrome gives the user a choice to proceed with the connection. Chrome gives the user a choice to proceed with the connection.
3.3.2. Current Time within Validity Period 3.3.2. Current Time within Validity Period
Most, if not all, browsers properly evaluate whether an end entity Most, if not all, browsers properly evaluate whether an end entity
certificate is within its stated validity period. The browser may certificate is within its stated validity period. The browser may
display a warning indicating that a certificate in the certification display a warning indicating that a certificate in the certification
path is outside of its validity interval or expired. The user may be path is outside of its validity interval or expired. The user may be
skipping to change at page 12, line 8 skipping to change at page 13, line 32
MD5, have already been sunsetted, there is the potential that MD5, have already been sunsetted, there is the potential that
certificates could still be signed using those algorithms. At the certificates could still be signed using those algorithms. At the
same time, use of Diffie-Hellman Ephemeral keys has been suggested as same time, use of Diffie-Hellman Ephemeral keys has been suggested as
one way to provide forward secrecy, and elliptic curve cryptography one way to provide forward secrecy, and elliptic curve cryptography
is a recommended way to shorten bit lengths of keys. With the is a recommended way to shorten bit lengths of keys. With the
various permutations and combinations of parameters for these various permutations and combinations of parameters for these
algorithms, browser capabilities for the more common ones should be algorithms, browser capabilities for the more common ones should be
examined. examined.
3.4. Security Considerations 3.4. Security Considerations
Allowing weak cryptography increases the risk that intercepted Potential threats to communications security to be considered include
communications will be decrypted. whether allowing weak cryptography increases the risk that
intercepted communications will be decrypted, and whether an
An inability to handle unexpected certificate data may cause a inability to handle unexpected certificate data might cause a browser
browser to fail in an insecure way. For example, software failure to fail in an insecure way, for example, software failure that allows
might allow a connection to proceed without encryption, or worse, a connection to proceed without encryption or enables other system
enable system misuse by malware that exploits the vulnerability. misuse, e.g., a buffer overflow due to excessive data in a
certificate payload.
3.5. Areas for Future Work 3.5. Areas for Future Work
Future work will include additional review of algorithm support. Future work will include additional review of algorithm support.
We also plan to discuss how pinning interplays with certification We also plan to discuss how pinning interplays with certification
path development and validation. Some browsers support the pinning path development and validation. Some browsers support the pinning
of public keys. of public keys.
Most browsers perform certificate policy extension processing Most browsers perform certificate policy extension processing
appropriately. We have not examined if the policy mapping, inhibit appropriately. We have not examined if the policy mapping, inhibit
any policy, and policy constraints extensions are processed any policy, and policy constraints extensions are processed
skipping to change at page 14, line 25 skipping to change at page 16, line 6
certificate. certificate.
4.2. Wildcard character 4.2. Wildcard character
Most browsers support a wildcard character in the leftmost position. Most browsers support a wildcard character in the leftmost position.
For the browsers listed above in the scope section, we plan to For the browsers listed above in the scope section, we plan to
examine wildcard behaviors when the wildcard character is placed in examine wildcard behaviors when the wildcard character is placed in
positions other than the leftmost position, or when it alone is positions other than the leftmost position, or when it alone is
located to the immediate left of a top level domain. located to the immediate left of a top level domain.
4.3. Key Usage Extension 4.3. Key Usage Extension
The browsers should use the server public key for key encryption, key A server's public key can be used for key encryption, key agreement,
agreement or digital signature verification depending on the TLS or digital signature verification depending on the TLS cipher suite
cipher suite selected. Below are a few examples: selected. Below are a few examples:
- TLS_RSA_WITH_AES_128_CBC_SHA: The Server key is used for encrypting . 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 the master secret and thus, the Server certificate should have the
key encipherment bit set if the Server certificate contains the key key encipherment bit set if the Server certificate contains the key
usage extension. usage extension.
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: The Server key is used for . TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: The Server key is used for
authentication of ephemeral DH key thus, the Server certificate authentication of ephemeral DH key thus, the Server certificate
should have the digital signature bit set if the Server certificate should have the digital signature bit set if the Server certificate
contains the key usage extension. contains the key usage extension.
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: The Server key is used for . TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: The Server key is used for
authentication of ephemeral DH key thus, the Server certificate authentication of ephemeral DH key thus, the Server certificate
should have the digital signature bit set if the Server certificate should have the digital signature bit set if the Server certificate
contains the key usage extension. contains the key usage extension.
- TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA: The Server key is used for . TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA: The Server key is used for
ECDH key agreement/exchange. Thus, the Server certificate should ECDH key agreement/exchange. Thus, the Server certificate should
have the key agreement bit set if the Server certificate contains have the key agreement bit set if the Server certificate contains
the key usage extension. the key usage extension.
4.4. Security Considerations 4.4. Security Considerations
An inability to detect and report an improper match between the An inability to detect and report an improper match between the
client's reference identifier (server name) and the subject name in client's reference identifier (server name) and the subject name in
the certificate (a presented identifier) could enable the misuse of a the certificate (a presented identifier) could enable the misuse of a
certificate for man-in-the-middle server authentication. For certificate for man-in-the-middle server authentication. For
example, an attacker could use a certificate surreptitiously with a example, an attacker could use a certificate surreptitiously with a
skipping to change at page 19, line 8 skipping to change at page 20, line 36
Certification Path Building", RFC 4158, September 2005. Certification Path Building", RFC 4158, September 2005.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, Certificate and Certificate Revocation List (CRL) Profile", RFC 5280,
May 2008. May 2008.
[RFC6797] Hodges, J., Jackson, C., and Barth, A., "HTTP Strict [RFC6797] Hodges, J., Jackson, C., and Barth, A., "HTTP Strict
Transport Security (HSTS)", RFC 6797, November 2012. Transport Security (HSTS)", RFC 6797, November 2012.
[W3C-WSC] Web Security Context: User Interface Guidelines, W3C [W3C-WSC] Web Security Context: User Interface Guidelines, W3C
Recommendation 12 August 2010. Recommendation 12 August 2010.
Authors' Addresses Authors' Addresses
Ben Wilson Ben Wilson
Email: ben@digicert.com Email: ben@digicert.com
Santosh Chokhani Santosh Chokhani
Email: schokhani@cygnacom.com Email: schokhani@cygnacom.com
 End of changes. 35 change blocks. 
102 lines changed or deleted 156 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/