idnits 2.17.1 draft-ietf-wpkops-trustmodel-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: ---------------------------------------------------------------------------- No issues found here. 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 29, 2014) is 3592 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2119' on line 433 looks like a reference -- Missing reference section? 'RFC5280' on line 420 looks like a reference -- Missing reference section? 'RFC3647' on line 436 looks like a reference -- Missing reference section? 'RFC5914' on line 425 looks like a reference -- Missing reference section? 'BR-certs' on line 443 looks like a reference -- Missing reference section? 'RFC6797' on line 428 looks like a reference -- Missing reference section? 'Mozilla-CP' on line 447 looks like a reference Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force I. Barreira, Ed. 3 Internet-Draft Izenpe 4 Intended status: Best Current Practice B. Morton, Ed. 5 Expires: November 30, 2014 Entrust 6 May 29, 2014 8 Trust models of the Web PKI 9 draft-ietf-wpkops-trustmodel-02 11 Abstract 13 This is one of a set of documents to define the operation of the Web 14 PKI. It describes the currently deployed Web PKI trust. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on November 30, 2014. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 52 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Trust model . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Root store provider . . . . . . . . . . . . . . . . . . . 4 55 2.2. CA Infrastructure . . . . . . . . . . . . . . . . . . . . 4 56 2.2.1. Registration Authority . . . . . . . . . . . . . . . 5 57 2.2.2. Certificate status . . . . . . . . . . . . . . . . . 5 58 2.3. Subscriber . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.4. Browser . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Trust Model variants . . . . . . . . . . . . . . . . . . . . 5 61 3.1. Root store provider variations . . . . . . . . . . . . . 5 62 3.1.1. Browser adopts root store . . . . . . . . . . . . . . 5 63 3.2. CA Infrastructure variations . . . . . . . . . . . . . . 6 64 3.2.1. One root CA cross-certifies another root CA . . . . . 6 65 3.2.2. Issuing CA is a third party to the root CA . . . . . 6 66 3.2.3. Registration authority is a third party to the 67 issuing CA . . . . . . . . . . . . . . . . . . . . . 6 68 3.2.4. Root CA is operated by the government . . . . . . . . 7 69 3.2.5. Subscriber operates issuing CA . . . . . . . . . . . 7 70 3.2.6. Subscriber sources management of issuing CA . . . . . 7 71 3.2.7. Subscriber manages registration authority . . . . . . 7 72 3.2.8. Subscriber certificate issued by a root CA . . . . . 7 73 3.3. Subscriber . . . . . . . . . . . . . . . . . . . . . . . 8 74 3.3.1. Subscriber uses agent . . . . . . . . . . . . . . . . 8 75 3.4. Browser . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 3.4.1. Browser directly trusts issuing CA key . . . . . . . 8 77 3.4.2. Browser directly trusts subscriber entity key . . . . 8 78 3.4.3. Browser makes root CA public key unusable . . . . . . 8 79 3.4.4. Browser supports public key pinning . . . . . . . . . 8 80 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 82 5.1. HTTPS is optional . . . . . . . . . . . . . . . . . . . . 9 83 5.2. Naming of subscribers . . . . . . . . . . . . . . . . . . 9 84 5.3. Root CA compromise . . . . . . . . . . . . . . . . . . . 9 85 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 6.1. IETF Normative References . . . . . . . . . . . . . . . . 10 87 6.2. IETF Informative References . . . . . . . . . . . . . . . 10 88 Appendix A. Other references . . . . . . . . . . . . . . . . . . 10 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 91 1. Introduction 93 This document defines the Web PKI trust model as it is currently 94 implemented. The trust model is to support communications between 95 the subscriber and the browser. This document does not address 96 future changes to the implemented trust model. 98 1.1. Requirements Language 100 The key words "REQUIRED", "MUST", "MUST NOT" and "MAY" in this 101 document are to be interpreted as described in RFC 2119 [RFC2119] 103 1.2. Definitions 105 The use of PKI terminology is used as defined in RFC 5280 [RFC5280]. 106 Additional definitions are provided below for interpretation of this 107 document. 109 Certificate policy - per RFC 3647. [RFC3647] 111 Intermediate CA - is a non-root CA which issues certificates to 112 issuing CAs. 114 Issuing CA - in relation to a particular subscriber certificate, 115 the CA that issued the certificate. 117 Root CA - a CA with a self signed certificate and whose public key 118 is included as a trust anchor in a root store. 120 Root certificate - typically a self-signed certificate that 121 identifies the root CA. The root certificate is a type of trust 122 anchor. 124 Root store - a set of root certificates which can be trusted by a 125 browser. 127 Root store policy - the governance policy provided by the root 128 store provider. 130 Subscriber - per RFC 3647. [RFC3647] 132 Subscriber agreement - per RFC 3647. [RFC3647] 134 Trust Anchor - per RFC 5914. [RFC5914] 136 2. Trust model 138 This section describes the basic Web PKI trust model. Variants to 139 the trust model are discussed in section 3. 141 In the Web PKI trust model, a browser uses a root store that contains 142 one or more root CA public keys. Each entry in a browser's root 143 store has been installed on an evaluation made by the browser vendor. 144 Each root CA issues a certificate to one or more issuing CAs that are 145 under the control of the same CA entity with the variant stated in 146 3.2.2. Each issuing CA accepts and responds to certificate requests 147 from one or more subscribers via one or more registration 148 authorities. 150 2.1. Root store provider 152 A root store provider (e.g., Microsoft or Mozilla) determines a root 153 store policy. This policy must be met by a candidate root CA in 154 order to be included in the root store. The root store provider 155 installs and manages root certificates in its operating system or 156 browser to support certificate chain validation. The root store 157 provider establishes requirements for accepting a root certificate. 158 These requirements may include legal agreements, security or audit 159 reports or acceptance by another root store provider. 161 The root store provider may require the root CA to be subject to an 162 annual compliance audit performed by a third party auditor as 163 specified in [BR-certs]. The audit requirements are defined by the 164 root store policy. The audit is based on an accepted schema of the 165 standards (e.g., WebTrust or ETSI). A third party auditor generates 166 an audit report which is provided to the root store provider. If the 167 audit report states the root CA did not comply with the auditing 168 standards, then the root CA will be required to take corrective 169 actions. Once the corrective actions are completed, then an updated 170 report is submitted to the root store provider. If the status of the 171 root CA is not acceptable to the root store provider, then the root 172 CA certificates may be removed from the root store or the indications 173 from the browser (e.g., removal of https indicator) may change for 174 certificates verified under that root CA. 176 2.2. CA Infrastructure 178 The CA infrastructure consists of a PKI hierarchy. Each organization 179 acting as a CA entity is represented by one or more self-signed root 180 certificates. The root CAs sign certificates for subordinate issuing 181 CAs. The root CA may have subordinate intermediate CAs to manage 182 groups of subordinate issuing CAs. The CA entity manages root, 183 intermediate, and issuing CAs and oversees operation of the 184 certificate issuance and management system in accordance with a 185 certificate policy. 187 2.2.1. Registration Authority 189 Each issuing CA operates a registration authority, with variations in 190 3.2.3 and 3.2.7, which authenticates requests for certificates in 191 accordance with the certificate policy of the CA. 193 2.2.2. Certificate status 195 Each CA provides certificate status in the form of a certificate 196 revocation list (CRL) and/or an on-line certificate status protocol 197 (OCSP) response. Updates and validity periods of the certificate 198 status are provided in accordance with the certificate policy of the 199 CA. The location of the CRL is provided in the certificate CDP (CRL 200 Distribution Point) OID and the location of the OCSP response is 201 provided in the AIA (Authority Info Access) OID of the issued 202 certificate. 204 2.3. Subscriber 206 Each subscriber provides services through the browsers to relying 207 parties. The subscriber identifies the on-line web location of its 208 service using a domain name or IP address contained in a certificate. 210 The subscriber submits certificate requests in accordance with a CA's 211 certificate policy. Once the certificate request has been accepted, 212 the subscriber will receive the certificate and will manage the 213 certificate in accordance with the subscriber agreement. 215 2.4. Browser 217 The browser accepts and manages certificates and performs related 218 functions in accordance with the root store policy (e.g., [Mozilla- 219 CP]). 221 3. Trust Model variants 223 This section defines variants to the roles of the parties as defined 224 in section 2. 226 3.1. Root store provider variations 228 3.1.1. Browser adopts root store 230 The browser does not use its own root store, but uses the root store 231 managed by a separate root store provider. For example, the Google 232 Chrome browser operated on Windows uses the Windows root store. 234 The browser will provide its own trust and security indications. The 235 browser may determine whether it will provide extended validation 236 indications. The browser may also provide its own services to verify 237 the status of the certificates. 239 3.2. CA Infrastructure variations 241 3.2.1. One root CA cross-certifies another root CA 243 Some browsers in active use do not possess the capability to be 244 updated with new root certificates in the field. Consequently, these 245 browsers do not accept new root certificates issued by CAs that came 246 into existence after they were first deployed. The new root 247 certificates are accepted by newer browsers and other browsers that 248 can be updated in the field. As such newer CAs operate at a 249 disadvantage to older CAs. 251 The disadvantage can be addressed by having trust extended to the new 252 root certificate, by having the public key of the new root 253 certificate cross-signed by an older root CA which is already 254 accepted in the older browsers. As the cross-certified root CA is 255 also recognized directly by the root store provider, it operates in 256 accordance with the requirements of that certificate policy to which 257 the root CA conforms. In addition, the cross-certified CA complies 258 to any requirements placed upon it by the contract between it and the 259 cross-certifying root CA. 261 3.2.2. Issuing CA is a third party to the root CA 263 An issuing CA may operate as a third party subordinate to the root 264 CA. The issuing CA's behaviour is governed by its contract with the 265 root CA, which commonly stipulates adherence to the root store 266 policy. Unlike the situation in section 3.2.1, the subordinate 267 issuing CA is not recognized independently by any relationship with 268 the root store provider. 270 3.2.3. Registration authority is a third party to the issuing CA 272 A registration authority may operate as a third party to an issuing 273 CA. A registration authority's behaviour is governed by its contract 274 with the issuing CA, which commonly stipulates adherence to the root 275 store policy to which the CA adheres. A third party registration 276 authority is not identified in a CA certificate. 278 3.2.4. Root CA is operated by the government 280 In the case where a root CA is operated by a government department, a 281 root store provider may rely upon an audit conducted in accordance 282 with the government's own internal audit process. 284 3.2.5. Subscriber operates issuing CA 286 A subscriber may operate its own issuing CA. Typically, the 287 subscriber is approved to issue certificates only within a specific 288 region of the name-space, and this limitation is enforced by 289 contract. The root CA may use the name constraints certificate 290 extension to limit the region of the name-space in which the issuing 291 CA can issue valid certificates. 293 This is often referred to as an enterprise-based subordinate CA 294 relationship. 296 3.2.6. Subscriber sources management of issuing CA 298 A root CA may host an issuing CA on behalf of a subscriber. 299 Typically, the subscriber is approved to issue certificates only 300 within a specific region of the name-space, and this limitation is 301 enforced by the host root CA. Examination of the certificate chain 302 would indicate that the issuing CA was owned by the subscriber by 303 viewing the organization name in the subject field. 305 This may also be an enterprise-based CA relationship; however, the 306 entity operating the CA (rather than the enterprise subscriber) has 307 immediate control of the CA and physical possession of the CA private 308 key. 310 3.2.7. Subscriber manages registration authority 312 A subscriber may manage a registration authority. The subscriber is 313 approved to issue certificates only within a specific region of the 314 name-space, and this limitation is enforced by the issuing CA through 315 technical or legal means. 317 This is often referred to an enterprise-based registration authority 318 relationship with the issuing CA. 320 3.2.8. Subscriber certificate issued by a root CA 322 Some legacy situations demand that a certificate be issued directly 323 by a root CA, without the involvement of intermediate issuing CAs. 325 3.3. Subscriber 327 3.3.1. Subscriber uses agent 329 A subscriber may use a third party agent to manage its certificates. 330 The third party will request certificates from a registration 331 authority and manage the certificates in accordance with the 332 subscriber agreement on the subscriber's behalf. 334 3.4. Browser 336 3.4.1. Browser directly trusts issuing CA key 338 A browser may allow a relying party to designate a CA key as a trust 339 anchor for the purpose of evaluating subscriber certificates. 341 3.4.2. Browser directly trusts subscriber entity key 343 A browser may allow a relying party to designate a subscriber's 344 certificate as a trust anchor. 346 3.4.3. Browser makes root CA public key unusable 348 A browser may allow a relying party to remove the trust of a root CA 349 by deleting the root certificate from the root store. In some cases 350 the trust removal may only be temporary as the browser or operating 351 system may update the root store and restore the trust of the root 352 CA. 354 3.4.4. Browser supports public key pinning 356 A browser may limit the set of public keys used to verify a 357 certificate containing a domain name. Limitation can be done by 358 including the set of accepted public keys in the browser or by 359 respecting an HTTP header provided by the subscriber. 361 4. IANA Considerations 363 This memo includes no request to IANA. 365 5. Security Considerations 367 The trust models described here exhibit several vulnerabilities that 368 could adversely affect the reliability of the authentication they 369 provide. 371 5.1. HTTPS is optional 373 The subscriber does not have to support HTTPS for the web site. The 374 subscriber may provide HTTPS in some cases and not in other cases. 375 As such, the trust model is optional for each web site. In the event 376 of no HTTPS, the browser could more easily be attacked. This attack 377 can be mitigated by supporting HSTS in accordance with RFC 6797 378 [RFC6797]. HSTS allows the subscriber to declare to the browser that 379 interactions shall only be done using HTTPS connections. 381 5.2. Naming of subscribers 383 Subscriber names with any of the following characteristics can be 384 used in an impersonation attack. 386 o homographic name 388 o mixed-alphabet name 390 o name that contains a string termination character 392 o Internet non-unique name (e.g. an internal server name) 394 With the exception of non-unique names, CAs in the Web PKI are 395 required to screen out requests for certificates with any of these 396 characteristics. CAs are required to phase out the practice of 397 issuing non-unique names by 2015 per [BR-certs]. 399 Technically, unless constrained by an upstream CA to issue 400 certificates only in a specific region of the name-space, any CA in 401 the Web PKI can issue an apparently legitimate certificate for any 402 name, whether or not the legitimate holder of that name is aware of 403 or approves the issuance. Furthermore, the legitimate holder of that 404 name may not discover that such a certificate has been issued. 406 5.3. Root CA compromise 408 In the event of a detected compromise of a root CA, its key is 409 blacklisted by means of a software update. This has the effect of 410 invalidating every certificate that is subordinate to that root CA, 411 whether or not the certificate was issued while the compromise 412 existed. This step would have a severe impact upon the CA and its 413 subscribers; this is a step not likely to be taken without very 414 careful. 416 6. References 418 6.1. IETF Normative References 420 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 421 Housley, R., and W. Polk, "Internet X.509 Public Key 422 Infrastructure Certificate and Certificate Revocation List 423 (CRL) Profile", RFC 5280, May 2008. 425 [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 426 Format", RFC 5914, June 2010. 428 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 429 Transport Security (HSTS)", RFC 6797, November 2012. 431 6.2. IETF Informative References 433 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 434 Requirement Levels", BCP 14, RFC 2119, March 1997. 436 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 437 Wu, "Internet X.509 Public Key Infrastructure Certificate 438 Policy and Certification Practices Framework", RFC 3647, 439 November 2003. 441 Appendix A. Other references 443 [BR-certs] - CA/Browser Forum, Baseline Requirements for the 444 Issuance and Management of Publicly-Trusted Certificates. 445 https://cabforum.org/baseline-requirements-documents/ 447 [Mozilla-CP] - Mozilla CA Certificate Policy. https://www.mozilla 448 .org/projects/security/certs/policy/ 450 Authors' Addresses 452 Inigo Barreira (editor) 453 Izenpe 454 Beato Tomas de Zumarraga 71, 1. 01008 Vitoria-Gasteiz. Spain 456 Phone: +34 945067705 457 Email: i-barreira@izenpe.net 458 Bruce Morton (editor) 459 Entrust 460 1000 Innovation Drive. Ottawa, Ontario. Canada K2K 3E7 462 Email: bruce.morton@entrust.com