idnits 2.17.1 draft-wilson-wpkops-browser-processing-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 377 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 280 has weird spacing: '...how the autho...' == Line 514 has weird spacing: '...s. See http:...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 22, 2014) is 3560 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 815, but no explicit reference was found in the text == Unused Reference: 'RFC3647' is defined on line 818, but no explicit reference was found in the text == Unused Reference: 'RFC 4158' is defined on line 822, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 826, but no explicit reference was found in the text == Unused Reference: 'RFC6797' is defined on line 831, but no explicit reference was found in the text == Unused Reference: 'W3C-WSC' is defined on line 834, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Web PKI OPPS B. Wilson 3 Internet Draft Digicert 4 Intended status: Informational S. Chokhani 5 Expires: January 2015 Cygnacom 6 R. Alden 7 Comodo 8 July 22, 2014 10 Browser processing of server certificates 11 draft-wilson-wpkops-browser-processing-02.txt 13 Abstract 15 This is one of a set of documents to define the operation of the Web 16 PKI. It describes common variations in browser behavior related to 17 processing server certificates. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 23, 2015. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction...................................................3 54 1.1. Definitions...............................................3 55 1.2. Scope.....................................................4 56 1.3. Document Organization.....................................5 57 2. Certification Path Development.................................6 58 2.1. Basic Requirements........................................6 59 2.2. Additional Requirements...................................7 60 2.3. Browser/Cryptolibrary Observations........................7 61 2.4. Security Considerations...................................8 62 2.5. Areas for Future Work.....................................8 63 3. Certification Path Validation..................................9 64 3.1. Basic Requirements (based on RFC 5280)....................9 65 3.2. Additional Requirements..................................10 66 3.3. Browser Observations.....................................10 67 3.3.1. Path Validation.....................................10 68 3.3.1.1. Signature Verification.........................10 69 3.3.1.2. Name Constraints...............................11 70 3.3.2. Current Time within Validity Period.................12 71 3.3.3. Public Key Parameters...............................12 72 3.3.3.1. Sizes..........................................12 73 3.3.3.2. Algorithms and Cipher Suites...................13 74 3.4. Security Considerations..................................13 75 3.5. Areas for Future Work....................................13 76 4. Server certificate processing.................................14 77 4.1. Subject Names............................................14 78 4.2. Wildcard character.......................................15 79 4.3. Key Usage Extension......................................16 80 4.4. Security Considerations..................................16 81 4.5. Areas for Future Work....................................16 82 5. Browser Human Interface (Visual) Indicators...................17 83 5.1. Visual indicators........................................17 84 5.2. Positive visual indicators...............................17 85 5.3. Negative visual indicators...............................17 86 5.4. Message boxes, dialog boxes and error pages..............18 87 5.5. Certificate viewers......................................18 88 5.6. Certification Path Development and Validation Indication.18 89 5.7. Configurables............................................19 90 5.8. Security Considerations..................................19 91 5.9. Areas for Future Work....................................19 92 6. IANA Considerations...........................................19 93 7. Security Considerations.......................................20 94 8. Normative References..........................................20 96 1. Introduction 98 This document reviews the current processing behaviors of 99 cryptolibraries, and the browsers they support, with respect to 100 SSL/TLS session establishment between a server and a browser, 101 including signature verification, certificate parsing, chain 102 processing, and other non-revocation-checking processes described in 103 RFC 5280 and the SSL/TLS protocol. 105 The information presented in this document is based on user 106 experience and should not be construed as exhaustive. In other 107 words, it is based on observed behavior and is not based on any 108 comprehensive testing. The product vendors and reviewers are 109 encouraged to provide additional information that sheds light on the 110 observations made in this document or to provide additional 111 observations. 113 This document does not address future changes to the implemented 114 trust model. 116 1.1. Definitions 118 PKI terminology is as defined in RFC 5280. Other definitions are 119 defined below for interpretation of this document. 121 Behavior - The observed action or activity of a browser based on a 122 set of conditions or circumstances. 124 Blacklist - A group, set, or list of data objects created to 125 explicitly prevent them from being used because they are unsafe or 126 obsolete. 128 Block - A behavior in which the browser detects an abnormal condition 129 and halts (or technically cannot complete) session negotiation and 130 drops the connection or otherwise blocks the user from continuing. 132 Bypassable error - A behavior in which the browser detects an 133 abnormal condition and asks the user whether to proceed with (i.e. 134 click-through to) the SSL/TLS connection. 136 Fail open - A behavior in which the browser is unable to successfully 137 complete a certificate-checking process, but provides the content. 139 Internationalized Name - The Punycode-encoded ASCII representation of 140 Unicode characters prefaced with the ASCII Compatible Encoding (ACE) 141 prefix, xn--. 143 Name mismatch - A condition detected by a browser in which no name in 144 the common name or subject alternative name for the subject in the 145 certificate matches the hostname sought by the client (i.e. the 146 client's reference identity - usually a Fully Qualified Domain Name - 147 is not in the certificate). 149 Pinned - A condition in which the association between two or more 150 aspects of the entity-public-key relationship (e.g. server name, 151 public key, CA, certificate) are configured and set in the browser 152 before initiation of a TCP connection. 154 Stapled - A condition in which information related to the server's 155 certificate (e.g. OCSP response) is delivered by the server to the 156 client as part of the SSL/TLS handshake, and not by direct 157 communication with the issuing CA. Not all browsers request stapled 158 responses. Since OCSP stapling is directly related to revocation, 159 discussion of OCSP stapling is outside the scope of this document. 161 Visual indicator - A behavior in which the browser changes the 162 color(s) and/or intensity of pixels on a screen in the browser chrome 163 to indicate a changed condition. Visual indicators also include 164 error pages, pop-up dialogs, and warning messages. 166 Wildcard character - An asterisk - * (Unicode 2A). 168 1.2. Scope 169 The scope of this document excludes revocation checking. Revocation 170 checking is addressed in another document. 172 This document currently treats as out-of-scope browser behavior for 173 client authentication TLS. In a future version it might address 174 behavior when a legitimate client certificate is not selected or 175 presented under certain circumstances, such as when the browser and 176 the TLS Server have different trust anchors. 178 This document also does not address lesser-used X.509 certificate 179 extensions: issuer alternative name; subject directory attribute; 180 policy constraint; inhibit any policy; and subject information 181 access. 183 Also, because revocation checking is out of scope, the discussion of 184 the following extensions is out of scope: CRL Distribution Point; 185 Freshest CRL; and OCSP field in the Authority Information Access 186 extension. OCSP stapling support is addressed in another document. 188 This document reviews some of the certificate-processing features of 189 the following cryptolibraries: Network Security Services (NSS), in 190 two code sets, Classic (NSS-Classic) and PKIX (NSS-PKIX); Microsoft 191 Crypto API (MS-CAPI); OpenSSL; and Apple's Cryptographic, 192 Certificate, Key, and Trust Services (A-CKTS). Thus, it examines the 193 behavior of Internet Explorer, on Windows 7/8 relying on MS-CAPI; 194 Mozilla Firefox, relying on NSS; Apple Safari, relying on A-CKTS; and 195 Opera and Google Chrome, relying on MS-CAPI, A-CKTS, or NSS, as the 196 case may be. 198 Mobile platforms, such as Android, iOS, and Windows Mobile, are also 199 addressed as information becomes available. 201 1.3. Document Organization 202 This Section 1 provides a brief introduction to the non-revocation- 203 checking processes implemented in cryptolibraries and by browsers. 205 Section 2 describes the requirements for certification path 206 development in order to establish trust in the server public key. 207 Section 2 also contains the nuances of cryptolibraries and popular 208 browsers, in terms of their ability to meet these requirements and 209 security implications of these nuances. 211 Section 3 describes requirements for certification path validation in 212 order to establish trust in the server public key. Section 3 also 213 contains the nuances of cryptolibraries and popular browsers in terms 214 of their ability to meet these requirements and security implications 215 of these nuances. 217 Section 4 describes the requirements for processing the Server 218 certificate. Section 4 also contains the nuances of cryptolibraries 219 and popular browsers in terms of their ability to meet these 220 requirements and security implications of these nuances. 222 Section 5 describes the browser user interface indicators. 224 Section 6 lists IANA Considerations. 226 Section 7 summarizes Security Considerations discussed throughout 227 this document. 229 Section 8 contains references. 231 2. Certification Path Development 233 2.1. Basic Requirements 234 This section discusses sources of certificate information that are 235 available to browsers to assist in certification path development, as 236 described in RFC 5280. The purpose of X.509 path validation is to 237 ensure that the subject distinguished name or subject alternative 238 name in a certificate and the named subject's public key are 239 appropriately bound by a CA that chains up to the public key of a 240 trust anchor used by the browser. The path validation algorithm does 241 this by processing a sequence of certificates that support that 242 binding. While RFC 5280 requires that browsers process certification 243 chains in accordance with the path validation algorithm, it does not 244 specify a procedure by which a browser should construct that 245 certification path. (RFC 4158 provides additional guidance on 246 factors to consider when building a certification path.) 248 Root stores are not fixed. Not only can they be extended via 249 automatic download, but enterprises can add and remove roots through 250 group policies, and most end users can manually add or remove root 251 certificates. Browsers have or obtain root certificates used to 252 identify the trust anchors for a server's certification path. 253 Candidate trust anchors are available locally in root stores 254 (maintained by the browser, cryptolibrary, or operating system) or 255 via automatic download from a remote system. Most systems also allow 256 users to further adjust trust anchors with other configuration 257 changes, such as allowing users to enable or disable potential key 258 usages by checking or unchecking them for each certificate found in 259 the root store. For instance, Firefox provides three options 260 (identify websites, identify mail users, and identify software 261 makers), while the Apple key chain provides ten key usages to select 262 from, and Microsoft offers nearly fifty. 264 Browsers also use their local caches of certificates for 265 certification path development. 267 Browser use the certificates sent by the TLS Server in the TLS 268 handshake for certification path development. 270 Some browsers use the caIssuers field in the Authority Information 271 Access extension of a certificate to obtain, over unsecure HTTP or 272 LDAP, the intermediary CA's certificate in order to build the 273 certification path. Some browsers are able to process LDAP 274 pointers to caCertificate or crossCertificatePair attributes and also 275 handle HTTP single certificate payloads and multiple certificate 276 payloads, as described in RFC 5280. 278 Assuming that the browser has obtained a set of certificates that can 279 be used to form a certificate chain, section 4.2.1 of RFC 5280 sets 280 forth how the authorityKeyIdentifier and the subjectKeyIdentifier 281 standard extensions can also be used to select appropriate 282 certificate when multiple choices exist. Most browsers process these 283 extensions as part of certification path construction. Similarly, 284 most browsers also match the issuer name with the subject name of the 285 issuer's certificate as the chain is constructed up to the trust 286 anchor. 288 2.2. Additional Requirements 289 None 291 2.3. Browser/Cryptolibrary Observations 292 All browsers and cryptolibraries examined were able to perform 293 certificate path validation when the server presented the browser 294 with a properly ordered certificate chain--where the first certificate 295 was the end entity's "leaf" certificate, followed by the issuer CA's 296 certificate. However, because a misconfigured server might present a 297 root certificate in the middle of a chain, some cryptolibraries are 298 able to construct certificate paths by re-ordering certificates 299 presented by a server. (There are free tools available to test 300 whether a server is presenting a complete and well-ordered chain.) 302 Also, however, some servers are misconfigured and only provide the 303 leaf certificate and not a necessary intermediate CA certificate. In 304 these cases, a browser is unable to determine whether the certificate 305 chains to a trusted root. In these cases, the browsers indicate that 306 the site, the connection, or the server is untrusted. Some warning 307 messages indicate that the certificate was not issued by a trusted 308 CA. 310 Some browsers are able to store intermediate CA certificates 311 permanently or in cache, so they do not need to obtain the 312 intermediate CAs every time. 314 Some leaf certificates have a caIssuers field in the Authority 315 Information Access extension. The purpose of the caIssuers field is 316 to provide a URI pointer to the Intermediate CA's certificate. All 317 browsers except for Firefox are able to use the caIssuers AIA to 318 obtain the intermediate certificate and construct a chain. Because 319 NSS does not process the caIssuers AIA, Mozilla Firefox is unable to 320 construct a chain. When a path cannot be built, Firefox presents a 321 negative visual indication as a bypassable error as described in 322 Section 5.6. It is the authors' understanding that the Mozilla 323 community intentionally chose this behavior instead of processing the 324 caIssuers AIA because Firefox will alert server administrators about 325 defective chains and they can install missing CA certificates absent 326 from certificate chains. However, Chrome, which uses NSS, has chosen 327 to implement its own http-fetching ability to obtain missing 328 intermediate CA certificates. 330 2.4. Security Considerations 331 A browser's inability to create a path to a trust anchor leads to 332 uncertainty on the part of end users and may leave them more 333 vulnerable to man-in-the-middle attacks because they are unable to 334 determine whether the public key presented corresponds to the key 335 pair of the server that they intend to reach. 337 2.5. Areas for Future Work 338 Inputs are sought from the working group participants and vendors to 339 identify additional methods used and to gain understanding on browser 340 handling of misconfigured server-provided chains when an intermediate 341 CA certificate is available locally to the client. 343 3. Certification Path Validation 345 3.1. Basic Requirements (based on RFC 5280) 346 Browsers use one or more trust anchors from their root stores for 347 certification path validation. 349 The primary mechanism used to perform certification path validation 350 in accordance with Section 6 of RFC 5280 is verifying the signature 351 on the certificate. Much has been written on the process of 352 signature verification, which requires processing the tbsCertificate 353 and signatureValue fields using the signature algorithm and issuer 354 public key to verify that the certificate was properly signed. DSA, 355 RSA, and ECDSA are common digital signature algorithms used to sign 356 certificates in conjunction with hashing algorithms such as MD5, 357 RIPEMD-160, SHA-1, SHA-256, SHA-384, SHA-512, and Whirlpool. Thus, a 358 browser might need to be able to perform the signature verification 359 process using a variety of signature and hashing algorithms. 361 The following extensions described in RFC 5280 are also relevant to 362 certification path validation: 364 . The basicConstraints extension indicates whether the 365 certificate is for a CA or an end entity, and if for a CA, it 366 can include a path length constraint intended to limit the 367 maximum depth for the certification path from the certificate 368 (i.e. the allowed number of subordinate CA levels between it and 369 an end entity certificate). Presumably, a browser would check 370 whether the issuer's certificate included the basicConstraints 371 extension where CA=true and whether the certification path 372 complied with any path length constraint in the basicConstraints 373 extension. 375 . The key usage extension is a bit string of 9 bits (0 through 8) 376 that indicates the intended key usage. When Bit 5 is enabled, 377 it indicates that the public key in the intermediate CA 378 certificate may be used to validate signatures on certificates. 379 Presumably a browser would examine whether a CA's certificate 380 signing bit was set. 382 . The name constraints extension is a multi-valued field in a CA 383 certificate that indicates the intended scope of certificates, 384 in terms of name spaces, that are either allowed or prohibited 385 to be issued by that CA. This directive is honored by the 386 browser processing the subject DN and subject alternative names 387 in certificates issued by the CA and determining whether the 388 domain names in those subject fields fall within any stated 389 restriction (e.g. a permitted or an excluded name subtree). 390 (See Section 4.2.1.10 and Section 6 of RFC 5280.) 392 3.2. Additional Requirements 393 None. 395 3.3. Browser Observations 397 3.3.1. Path Validation 399 As mentioned in Section 2.3, online tools can be used to ensure that 400 servers are presenting complete, well-ordered chains, and server 401 administrators should do this to ensure the most efficient 402 certificate path processing. When a misconfigured server delivers a 403 shuffled group of certificates, some platforms are unable to perform 404 certification path validation, while other platforms are able to 405 perform validation because they implement a more robust path-building 406 process. 408 3.3.1.1. Signature Verification 410 A number of anomalous conditions arise with signature verification 411 processing - the signature might be plainly erroneous, the signature 412 algorithm might be incorrect, the browser might not be able to 413 process the algorithm, or the browser might disallow the certificate 414 because its signature or hashing algorithm is too weak or susceptible 415 to compromise. 417 When a browser encounters a signature error, it presents an error 418 message such as "invalid signature," "invalid certificate", or 419 "problem with certificate." Browsers exhibit a variety of differing 420 behaviors. For example, Firefox, Chrome, and Opera exhibit a blocking 421 behavior that prevents the user from proceeding to the site. Opera 422 offers a choice between "Back to safety" or "Help me understand". 423 Firefox and Chrome offer "try again" and "reload," as respective 424 options. However, Safari and Chrome on OS X and Internet Explorer on 425 Windows all allow the user to click through this signature validation 426 problem as a Bypassable Error. 428 Some browsers are able to detect certificates that are signed with 429 MD5 and block their use. For instance, Chrome provides this message, 430 "The site's security certificate is signed using a weak signature 431 algorithm!" Opera's notice states, "Invalid Server Certificate" and 432 offers "Back to Safety" and "Help Me Understand." Similarly, other 433 browsers present notices similar to those in the preceding paragraph. 435 3.3.1.2. Name Constraints 437 We have observed that Chrome and Safari on Mac OSX do not process 438 name constraints. When name constraints are present and marked 439 critical, Chrome presents a message stating, "Something is 440 interfering with your secure connection ...." However, if the name 441 constraints extension is not marked "critical", then both Chrome and 442 Safari allow the connection to proceed with no visual indicator of 443 any anomaly. If the name constraint is critical, Safari will reject 444 the certification path due to an unrecognized critical extension 445 (even if the subject DN or the subject alternative name is allowed by 446 the name constraint rule), but it gives the user a choice to proceed 447 with the connection. Chrome on Mac OS X blocks the user with a 448 "reload" button for all name constraints marked critical. 450 The following additional observations are made with respect to name 451 constraints: 453 . Microsoft IE on Windows platforms enforces name constraints (in 454 both the CN and in the Subject Alternative Name), but gives the 455 user a choice to proceed with the connection. 457 . Firefox on all platforms enforces name constraints (in both the CN 458 and in the Subject Alternative Name) and does not permit the user 459 to proceed. 461 . Chrome on the Windows platform enforces name constraints (in both 462 the CN and in the Subject Alternative Name), and does not permit 463 the user to proceed. 465 . Chrome on Linux enforces name constraints in the Subject 466 Alternative Name and does not enforce the name constraint on the 467 CN. Furthermore, in the case of name constraint failure on Linux, 468 Chrome gives the user a choice to proceed with the connection. 470 3.3.2. Current Time within Validity Period 472 Most, if not all, browsers properly evaluate whether an end entity 473 certificate is within its stated validity period. The browser may 474 display a warning indicating that a certificate in the certification 475 path is outside of its validity interval or expired. The user may be 476 given the choice to proceed to the content. The trust indicator may 477 be suppressed. In some cases, there may be no warning, but the trust 478 indicator is simply suppressed. 480 When the browser detects that the current system time is beyond the 481 validity period of a certificate in the certification path, a warning 482 is displayed. Some browsers indicate that a certificate has expired 483 and present a bypassable error asking whether or not to proceed or 484 allowing the user to view the certificate with a certificate viewer. 485 Some browsers also alert the user to the possibility that the error 486 is not caused by an expired certificate, but by incorrect system 487 time, and display the system time. For example, "Your computer's 488 clock currently indicates it is Monday, October 14, 2013, 4:00 AM. 489 Does this look right? If not, you should correct the error and 490 refresh this page." 492 We plan to enhance this section with additional and more complete 493 information in terms of validity period for certificates in the 494 certification path (i.e., handling expired CA certificates). 496 3.3.3. Public Key Parameters 498 3.3.3.1. Sizes 500 The public exponent for all RSA keys in SSL/TLS certificates must be 501 an odd number and cannot be "1" (because with RSA, when e=1, the 502 cipher text is equal to the plaintext). 504 Since December 31, 2013, has passed, all public RSA keys should be at 505 least 2048 bits. 507 Currently, if an RSA key size is less than 900 bits, Opera presents 508 the user with a negative visual indicator and a bypassable dialog. 509 If the RSA key size is greater 900 bits but less than 1,000 bits it 510 removes the padlock indicator. 512 Microsoft allows manual configuration of minimum key lengths by 513 editing the registry, using a certificate utility or other 514 mechanisms. See http://support.microsoft.com/kb/2661254. Thus, IE 515 and Chrome on Windows platform can enforce the 2,048 bit requirement. 516 It is not known if Firefox on Windows or other browsers listed in the 517 scope section address the 2,048 bit key size requirement. 519 3.3.3.2. Algorithms and Cipher Suites 521 Concerns about algorithms and cipher suites have increased over the 522 last several years as new vulnerabilities have been reported in the 523 media. [Examples to be given by cross-reference] This added attention 524 has increased focus on the abilities of browsers to block older, 525 insecure cryptographic methods while at the same time being able to 526 handle and process newer, more secure ones. For instance, Microsoft 527 has announced the deprecation of SHA1 and a 1-January-2017 sunset 528 date of its use in Windows. While other algorithms, like MD4 and 529 MD5, have already been sunsetted, there is the potential that 530 certificates could still be signed using those algorithms. At the 531 same time, use of Diffie-Hellman Ephemeral keys has been suggested as 532 one way to provide forward secrecy, and elliptic curve cryptography 533 is a recommended way to shorten bit lengths of keys. With the 534 various permutations and combinations of parameters for these 535 algorithms, browser capabilities for the more common ones should be 536 examined. 538 3.4. Security Considerations 539 Potential threats to communications security to be considered include 540 whether allowing weak cryptography increases the risk that 541 intercepted communications will be decrypted, and whether an 542 inability to handle unexpected certificate data might cause a browser 543 to fail in an insecure way, for example, software failure that allows 544 a connection to proceed without encryption or enables other system 545 misuse, e.g., a buffer overflow due to excessive data in a 546 certificate payload. 548 3.5. Areas for Future Work 550 Future work will include additional review of algorithm support. 552 We also plan to discuss how pinning interplays with certification 553 path development and validation. Some browsers support the pinning 554 of public keys. 556 Most browsers perform certificate policy extension processing 557 appropriately. We have not examined if the policy mapping, inhibit 558 any policy, and policy constraints extensions are processed 559 correctly. Most browsers, as a result of certificate policies 560 extension processing, provide a visual indication when they detect 561 that all the certificates in the certification path contain the 562 correct policy OID for Extended Validation. We plan to quantify 563 further the characteristics for the browsers listed in the scope 564 section. 566 Inputs are sought from the working group participants and vendors to 567 identify additional path validation rules and additional exceptions. 569 4. Server certificate processing 570 This section focuses on how the browsers use names and key usages in 571 Server certificates. While many of these checks are part of 572 certification path validation, these checks are discussed here as 573 part of TLS Server certificate processing in order to emphasize how 574 the browsers use the information in TLS Server certificates. 576 4.1. Subject Names 577 SSL/TLS certificates contain at least one subject name to bind the 578 public key in the certificate with the server that possesses 579 corresponding private key. The subject name appears in the subject 580 alternative name extension as dNSName name type and often in the 581 common name field. The latter practice of using the common name was 582 deprecated by RFC 2818. A browser processes the subject name in the 583 certificate to determine whether it matches the expected server name. 584 (As discussed above, the enforcement of name constraints on the DNS 585 name appearing in certificates varies among browsers.) Browsers are 586 known to successfully connect with servers whose DNS name appears in 587 the Subject CN only and when subject alternative name extension is 588 absent. Current browsers also work if the CN field is blank and the 589 certificate only has the name in the subject alternative name 590 extension. However, of some interest, is confusion over the 591 processing semantics with regard to the "O" and "OU" fields in the 592 subject name. How should subject name be populated when the 593 subscriber is an individual and not an organization? How is the "OU" 594 field interpreted? For EV certificates, what if the CA fails to 595 populate the "O" field? 597 Browser processing of internationalized names in subject names of 598 certificates allow browsers to either process the Internationalized 599 Name back into Unicode or display the Internationalized Name in ASCII 600 as xn--. See Section 7 of RFC 5280 for more detailed explanation. 602 In addition to the use of names for SSL/TLS processing, certificate 603 distinguished name fields may provide further identification of the 604 subject through domain-component naming and X.500 naming (e.g. 605 country, organization, etc.). When name constraints are used on the 606 DN, the entire subject distinguished name (not just the CN) needs to 607 pass the name constraints. 609 Section 3.1 of RFC 2818 states that in the case of a certificate name 610 mismatch, a browser "MUST either notify the user (clients MAY give 611 the user the opportunity to continue with the connection in any case) 612 or terminate the connection with a bad certificate error." 614 Typical browser behavior will provide a message box that reads, 615 "Security Error: Domain Name Mismatch" with treatment as a bypassable 616 error with options such as "View Certificate," "OK" or "Cancel." 618 Some browsers still prioritize common name processing over subject 619 alternative name processing even though use of the common name has 620 been deprecated. Another scenario is when the common name is not one 621 of the names listed as a subject alternative name. When either of 622 these occur, a browser might throw a domain name mismatch even though 623 the name to be used for the SSL/TLS session is in either the common 624 name field or the subject alternative name of the certificate but not 625 in both. 627 Most browsers display a warning, but allow the user to proceed to 628 viewing the contents of the web site. 630 Some systems, such as Keychain Access in Apple OS X, allow the user 631 to override certificate name mismatches by explicitly trusting a 632 certificate for a particular domain name that is not contained in the 633 certificate. 635 4.2. Wildcard character 636 Most browsers support a wildcard character in the leftmost position. 637 For the browsers listed above in the scope section, we plan to 638 examine wildcard behaviors when the wildcard character is placed in 639 positions other than the leftmost position, or when it alone is 640 located to the immediate left of a top level domain. 642 4.3. Key Usage Extension 643 A server's public key can be used for key encryption, key agreement, 644 or digital signature verification depending on the TLS cipher suite 645 selected. Below are a few examples: 647 . TLS_RSA_WITH_AES_128_CBC_SHA: The Server key is used for encrypting 648 the master secret and thus, the Server certificate should have the 649 key encipherment bit set if the Server certificate contains the key 650 usage extension. 652 . TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: The Server key is used for 653 authentication of ephemeral DH key thus, the Server certificate 654 should have the digital signature bit set if the Server certificate 655 contains the key usage extension. 657 . TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: The Server key is used for 658 authentication of ephemeral DH key thus, the Server certificate 659 should have the digital signature bit set if the Server certificate 660 contains the key usage extension. 662 . TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA: The Server key is used for 663 ECDH key agreement/exchange. Thus, the Server certificate should 664 have the key agreement bit set if the Server certificate contains 665 the key usage extension. 667 4.4. Security Considerations 668 An inability to detect and report an improper match between the 669 client's reference identifier (server name) and the subject name in 670 the certificate (a presented identifier) could enable the misuse of a 671 certificate for man-in-the-middle server authentication. For 672 example, an attacker could use a certificate surreptitiously with a 673 server name to bypass a general requirement that the name in the 674 certificate exactly match the fully qualified domain name of the 675 server. 677 4.5. Areas for Future Work 679 We plan to add information how the browsers adhere to these 680 requirements. For instance, what is the browser behavior where an 681 elliptic curve certificate asserts the key encipherment bit instead 682 of the key agreement bit? 683 Also, if the extended key usage extension is present in the Server 684 certificate, it should have one of the following OIDs: Server 685 Authentication or anyExtendedKeyUsage. There is concern about non- 686 SSL/TLS certificates (certificates issued without the intention that 687 they be used for SSL/TLS) with the anyExtendedKeyUsage EKU. We intend 688 to look at the degree of risk this presents. 690 We plan to add information how browsers vary in their processing of 691 EKUs in end entity certificates. 693 5. Browser Human Interface (Visual) Indicators 694 This section describes the typical kinds of browser/OS behaviors when 695 processing SSL/TLS certificates. 697 5.1. Visual indicators 698 The most commonly used visual indicator of SSL/TLS security is the 699 padlock icon. Variations of the icon include the closed padlock, the 700 open padlock, and the padlock superimposed with a red slash or X. 702 5.2. Positive visual indicators 703 Commonly used visual indicators that are considered positive 704 indications of web site authentication or security are a closed 705 padlock icon, use of the color green, and the display of additional 706 information about issuer or subject of the certificate. 708 Some of these indicators are called EV indicators because of their 709 use when displaying a website that presents an Extended Validation 710 certificate to the browser. 712 5.3. Negative visual indicators 713 Visual indicators used by browsers to convey warnings include use of 714 the color red, a slash (/) or X across a positive indicator (a red 715 slash or X across the padlock icon and/or the "https"), a message 716 box, or the removal of a positive indicator (e.g. removal of the 717 padlock). 719 5.4. Message boxes, dialog boxes and error pages 720 A message box is generally used not just as negative indicator, but 721 also to convey more context-specific guidance to the end user. They 722 can provide warnings or explain why an SSL/TLS connection cannot be 723 completed. Dialog boxes are used when the browser encounters an 724 uncertain environmental condition (for gray areas where the security 725 threat is not black or white). Some dialog boxes provide a simple 726 binary choice (a) proceed or (b) "get me out of here." This type of 727 browser behavior can be referred to as a "single bypassable error." 728 Other dialog boxes can exhibit more complex behavior, such as 729 multiple branches, additional nested bypassable errors, helpful 730 information, and decisions to be made by the user. 732 An error page is another mechanism used by browsers to provide 733 certificate-related information to users. 735 Some error messages provide an option to view the certificate. 736 Clicking on the offer launches the browser's certificate viewer. 738 5.5. Certificate viewers 739 Most browsers provide a means to examine the SSL/TLS certificate of 740 the web site and the chain of certificates leading up to the root 741 certificate. Some browsers block viewing the certificate in 742 circumstances determined by the browser to be insecure. 744 5.6. Certification Path Development and Validation Indication 745 If the certification path cannot be validated, some browsers will 746 alert the user about the inability to complete the server's 747 certificate chain, however the clarity of the explanation varies 748 among browsers. For instance, Firefox indicates "connection is 749 unsecure" and that the browser was unable to determine either 750 security status or the identity of the site. It provides the option 751 of "get me out of here" or "I understand the risks". 753 Most browsers will provide a warning when a certificate is signed by 754 an unknown CA. The warning usually states that an unknown authority 755 issued the certificate. Additional warnings include that if the user 756 has connected to the site previously without errors, it may mean an 757 attacker is trying to impersonate the site and intercept confidential 758 communications. Users are advised not to continue unless they are 759 sure. 761 With some browsers, this error can be bypassed for the session or the 762 user can explicitly trust the certificate permanently. When a 763 certification path fails because the issuer is not in the root store, 764 most browsers will still allow the user to explicitly trust the 765 certificate or the issuing CA. The number of steps required to 766 explicitly trust an untrusted certificate vary from browser to 767 browser. 769 5.7. Configurables 770 Most browsers provide the ability to configure certain certificate- 771 related behaviors. In Mozilla Firefox a user can change some options 772 using Tools -> Options -> Advanced -> Certificates or by typing 773 "about:config" in the address window and editing security 774 preferences. Changes in Microsoft's Internet Explorer settings can 775 be made under Tools -> Internet options -> Advanced -> Security or by 776 editing the registry. In Apple OS X, configuration changes are 777 performed by accessing preferences for certificates in the Keychain, 778 but since the only configurations available are related to revocation 779 checking (CRLs and OCSP), they are outside the scope of this draft. 781 5.8. Security Considerations 782 Better (i.e., more accurate, less ambiguous, and more complete) 783 security warnings to end users will lead to better decisions about 784 system security. While there is much to improve with browser error 785 messages, most operating systems also do not provide information that 786 browsers might use to provide better system diagnoses and messaging. 787 Better end user messages based on more accurate communication of 788 information can help address concerns about "warning fatigue" and 789 other problems of message ineffectiveness and end user confusion. 791 5.9. Areas for Future Work 793 We plan to offer "model" error messages to help guide browsers in 794 communicating with users more clearly. 796 Inputs are sought from the working group participants and vendors to 797 identify additional problems and solutions. 799 6. IANA Considerations 801 This memo includes no request to IANA. 803 7. Security Considerations 805 In addition to the security considerations discussed above, the 806 operations described above exhibit several vulnerabilities that could 807 adversely affect the reliability of the authentication and security 808 provided by SSL/TLS certificates. These vulnerabilities have been 809 discussed throughout this RFC and are summarized below: 811 Additional items will be provided as the draft becomes more stable. 813 8. References 815 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 816 Requirement Levels", BCP 14, RFC 2119, March 1997. 818 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, 819 "Internet X.509 Public Key Infrastructure Certificate Policy and 820 Certification Practices Framework", RFC 3647, Nov 2003. 822 [RFC 4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., 823 Nicholas, R., "Internet X.509 Public Key Infrastructure: 824 Certification Path Building", RFC 4158, September 2005. 826 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 827 Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure 828 Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, 829 May 2008. 831 [RFC6797] Hodges, J., Jackson, C., and Barth, A., "HTTP Strict 832 Transport Security (HSTS)", RFC 6797, November 2012. 834 [W3C-WSC] Web Security Context: User Interface Guidelines, W3C 835 Recommendation 12 August 2010. 837 Authors' Addresses 839 Ben Wilson 840 Email: ben@digicert.com 842 Santosh Chokhani 843 Email: schokhani@cygnacom.com 845 Robin Alden 846 Email: robin@comodo.com