idnits 2.17.1 draft-ietf-wpkops-trustmodel-04.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 (April 29, 2015) is 3256 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 454 looks like a reference -- Missing reference section? 'RFC5280' on line 441 looks like a reference -- Missing reference section? 'RFC3647' on line 457 looks like a reference -- Missing reference section? 'RFC5914' on line 446 looks like a reference -- Missing reference section? 'BR-certs' on line 464 looks like a reference -- Missing reference section? 'RFC6797' on line 449 looks like a reference -- Missing reference section? 'Mozilla-CP' on line 468 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: October 31, 2015 Entrust 6 April 29, 2015 8 Trust models of the Web PKI 9 draft-ietf-wpkops-trustmodel-04 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 October 31, 2015. 33 Copyright Notice 35 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 52 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Trust model . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . 6 62 3.1.1. Browser adopts root store . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . 9 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 82 5.1. HTTPS is optional . . . . . . . . . . . . . . . . . . . . 9 83 5.2. automatic update of root certificates . . . . . . . . . . 9 84 5.3. Naming of subscribers . . . . . . . . . . . . . . . . . . 9 85 5.4. Root CA compromise . . . . . . . . . . . . . . . . . . . 10 86 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 6.1. IETF Normative References . . . . . . . . . . . . . . . . 10 88 6.2. IETF Informative References . . . . . . . . . . . . . . . 10 89 Appendix A. Other references . . . . . . . . . . . . . . . . . . 10 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 92 1. Introduction 94 This document defines the Web PKI trust model as it is currently 95 implemented. The trust model is to support communications between 96 the subscriber and the browser. It refers also to the current 97 processing behaviours of cryptolibraries with the browsers they 98 support, related to the communication between the server and the 99 browser as indicated in the "Browser processing of server 100 certificates" document. This document does not address future 101 changes to the implemented trust model. 103 1.1. Requirements Language 105 The key words "REQUIRED", "MUST", "MUST NOT" and "MAY" in this 106 document are to be interpreted as described in RFC 2119 [RFC2119] 108 1.2. Definitions 110 The use of PKI terminology is used as defined in RFC 5280 [RFC5280]. 111 Additional definitions are provided below for interpretation of this 112 document. 114 Certificate policy - per RFC 3647. [RFC3647] 116 Intermediate CA - is a non-root CA which issues certificates to 117 issuing CAs. 119 Issuing CA - in relation to a particular subscriber certificate, 120 the CA that issued the certificate. 122 Root CA - a CA with a self signed certificate and whose public key 123 is included as a trust anchor in a root certificates store. 125 Root certificate - typically a self-signed certificate that 126 identifies the root CA. The root certificate is a type of trust 127 anchor. 129 Root certificates store - a set of root certificates which can be 130 trusted by the operating system and/or a browser. Within the 131 context of the present document the more general term Root Store 132 is used in preference. 134 Root store policy - the governance policy provided by the root 135 store provider. 137 Subscriber - per RFC 3647. [RFC3647] 139 Subscriber agreement - per RFC 3647. [RFC3647] 140 Trust Anchor - per RFC 5914. [RFC5914] 142 2. Trust model 144 This section describes the basic Web PKI trust model. Variants to 145 the trust model are discussed in section 3. 147 In the Web PKI trust model, a browser uses a root store that contains 148 one or more root CA public keys. Each entry in a browser's root 149 store has been installed on an evaluation made by the browser vendor. 150 Each root CA issues a certificate to one or more issuing CAs that are 151 under the control of the same CA entity with the variant stated in 152 3.2.2. Each issuing CA accepts and responds to certificate requests 153 from one or more subscribers via one or more registration 154 authorities. 156 2.1. Root store provider 158 A root store provider (e.g., Microsoft or Mozilla) determines a root 159 store policy. This policy must be met by a candidate root CA in 160 order to be included in the root store. The root store provider 161 installs and manages root certificates in its operating system or 162 browser to support certificate chain validation. The root store 163 provider establishes requirements for accepting a root certificate. 164 These requirements may include legal agreements, security or audit 165 reports or acceptance by another root store provider. 167 The root store provider may require the root CA to be subject to an 168 annual compliance audit performed by a third party auditor as 169 specified in [BR-certs]. The audit requirements are defined by the 170 root store policy. The audit is based on an accepted schema of the 171 standards (e.g., WebTrust or ETSI). A third party auditor generates 172 an audit report which is provided to the root store provider. If the 173 audit report states the root CA did not comply with the auditing 174 standards, then the root CA will be required to take corrective 175 actions. Once the corrective actions are completed, then an updated 176 report is submitted to the root store provider. If the status of the 177 root CA is not acceptable to the root store provider, then the root 178 CA certificates may be removed from the root store or the indications 179 from the browser (e.g., removal of https indicator) may change for 180 certificates verified under that root CA. 182 2.2. CA Infrastructure 184 The CA infrastructure consists of a PKI hierarchy. Each organization 185 acting as a CA entity is represented by one or more self-signed root 186 certificates. The root CAs sign certificates for subordinate issuing 187 CAs. The root CA may have subordinate intermediate CAs to manage 188 groups of subordinate issuing CAs. The CA entity manages root, 189 intermediate, and issuing CAs and oversees operation of the 190 certificate issuance and management system in accordance with a 191 certificate policy. 193 2.2.1. Registration Authority 195 Each issuing CA operates a registration authority, with variations in 196 3.2.3 and 3.2.7, which authenticates requests for certificates in 197 accordance with the certificate policy of the CA. 199 2.2.2. Certificate status 201 Each CA provides certificate status in the form of a certificate 202 revocation list (CRL) and/or an on-line certificate status protocol 203 (OCSP) response. Updates and validity periods of the certificate 204 status are provided in accordance with the certificate policy of the 205 CA. The location of the CRL is provided in the certificate CDP (CRL 206 Distribution Point) OID and the location of the OCSP response is 207 provided in the AIA (Authority Info Access) OID of the issued 208 certificate. 210 2.3. Subscriber 212 Each subscriber provides services through the browsers to relying 213 parties. The subscriber identifies the on-line web location of its 214 service using a domain name or IP address contained in a certificate. 216 The subscriber submits certificate requests in accordance with a CA's 217 certificate policy. Once the certificate request has been accepted, 218 the subscriber will receive the certificate and will manage the 219 certificate in accordance with the subscriber agreement. 221 2.4. Browser 223 The browser accepts and manages certificates and performs related 224 functions in accordance with the root store policy (e.g., [Mozilla- 225 CP]). 227 3. Trust Model variants 229 This section defines variants to the roles of the parties as defined 230 in section 2. 232 3.1. Root store provider variations 234 3.1.1. Browser adopts root store 236 The browser does not use its own root store, but uses the root store 237 managed by a separate root store provider. For example, the Google 238 Chrome browser operated on Windows uses the Windows root store. 240 The browser will provide its own trust and security indications. The 241 browser may determine whether it will provide additional validation 242 indications. The browser may also provide its own services to verify 243 the status of the certificates. 245 3.2. CA Infrastructure variations 247 3.2.1. One root CA cross-certifies another root CA 249 Some browsers in active use do not possess the capability to be 250 updated with new root certificates in the field. Consequently, these 251 browsers do not accept new root certificates issued by CAs that came 252 into existence after they were first deployed. The new root 253 certificates are accepted by newer browsers and other browsers that 254 can be updated in the field. As such newer CAs operate at a 255 disadvantage to older CAs. 257 The disadvantage can be addressed by having trust extended to the new 258 root certificate (that can belong to the older CA or be another CA), 259 by having the public key of the new root certificate cross-signed by 260 an older root CA which is already accepted in the older browsers. As 261 the cross-certified root CA is also recognized directly by the root 262 store provider, it operates in accordance with the requirements of 263 that certificate policy to which the root CA conforms. In addition, 264 the cross-certified CA complies to any requirements placed upon it by 265 the contract between it and the cross-certifying root CA. 267 This contract should indicate also the adherence to the root store 268 policy. 270 The [BR-certs] may be used as guidance for clarification. 272 3.2.2. Issuing CA is a third party to the root CA 274 An issuing CA may operate as a third party subordinate to the root 275 CA. The issuing CA's behaviour is governed by its contract with the 276 root CA, which commonly stipulates adherence to the root store 277 policy. Unlike the situation in section 3.2.1, the subordinate 278 issuing CA is not recognized independently by any relationship with 279 the root store provider. 281 3.2.3. Registration authority is a third party to the issuing CA 283 A registration authority may operate as a third party to an issuing 284 CA. A registration authority's behaviour is governed by its contract 285 with the issuing CA, which commonly stipulates adherence to the root 286 store policy to which the CA adheres. A third party registration 287 authority is not identified in a CA certificate. 289 3.2.4. Root CA is operated by the government 291 In the case where a root CA is operated by a government department, a 292 root store provider may rely upon an audit conducted in accordance 293 with the government's own internal audit process. 295 3.2.5. Subscriber operates issuing CA 297 A subscriber may operate its own issuing CA. Typically, the 298 subscriber is approved to issue certificates only within a specific 299 region of the name-space, and this limitation is enforced by legal 300 means or it can be also technically constrained. For example, the 301 root CA may use the name constraints certificate extension to limit 302 the region of the name-space in which the issuing CA can issue valid 303 certificates. 305 This is often referred to as an enterprise-based subordinate CA 306 relationship. 308 3.2.6. Subscriber sources management of issuing CA 310 A root CA may host an issuing CA on behalf of a subscriber. 311 Typically, the subscriber is approved to issue certificates only 312 within a specific region of the name-space, and this limitation is 313 enforced by the host root CA either technically or by legal means. 314 Examination of the certificate chain would indicate that the issuing 315 CA was owned by the subscriber by viewing the organization name in 316 the subject field. 318 This may also be an enterprise-based CA relationship; however, the 319 entity operating the CA (rather than the enterprise subscriber) has 320 immediate control of the CA and physical possession of the CA private 321 key. 323 3.2.7. Subscriber manages registration authority 325 A subscriber may manage a registration authority. The subscriber is 326 approved to issue certificates only within a specific region of the 327 name-space, and this limitation is enforced by the issuing CA through 328 technical or legal means. 330 This is often referred to an enterprise-based registration authority 331 relationship with the issuing CA. 333 3.2.8. Subscriber certificate issued by a root CA 335 Some legacy situations demand that a certificate be issued directly 336 by a root CA, without the involvement of intermediate issuing CAs. 338 3.3. Subscriber 340 3.3.1. Subscriber uses agent 342 A subscriber may use a third party agent to manage its certificates. 343 The third party will request certificates from a registration 344 authority and manage the certificates in accordance with the 345 subscriber agreement on the subscriber's behalf. 347 3.4. Browser 349 3.4.1. Browser directly trusts issuing CA key 351 A browser may allow a relying party to designate a CA key as a trust 352 anchor for the purpose of evaluating subscriber certificates. 354 3.4.2. Browser directly trusts subscriber entity key 356 A browser may allow a relying party to designate a subscriber's 357 certificate as a trust anchor. 359 3.4.3. Browser makes root CA public key unusable 361 A browser may allow a relying party to remove the trust of a root CA 362 by deleting the root certificate from the root store. In some cases 363 the trust removal may only be temporary as the browser or operating 364 system may update the root store and restore the trust of the root 365 CA. 367 3.4.4. Browser supports public key pinning 369 A browser may limit the set of public keys used to verify a 370 certificate containing a domain name. Limitation can be done by 371 including the set of accepted public keys in the browser or by 372 respecting an HTTP header provided by the subscriber. 374 4. IANA Considerations 376 This memo includes no request to IANA. 378 5. Security Considerations 380 The trust models described here exhibit several vulnerabilities that 381 could adversely affect the reliability of the authentication they 382 provide. 384 5.1. HTTPS is optional 386 The subscriber does not have to support HTTPS for the web site. The 387 subscriber may provide HTTPS in some cases and not in other cases. 388 As such, the trust model is optional for each web site. In the event 389 of no HTTPS, the browser could more easily be attacked. This attack 390 can be mitigated by supporting HSTS in accordance with RFC 6797 391 [RFC6797]. HSTS allows the subscriber to declare to the browser that 392 interactions shall only be done using HTTPS connections. 394 5.2. automatic update of root certificates 396 The end user may remove or add some or all root certificates provided 397 in a root store provider and then when an automatic update takes 398 place it may be reinstated the removed ones and remove the added ones 399 causing a posible denial of service and introducing some 400 vulnerabilities. 402 5.3. Naming of subscribers 404 Subscriber names with any of the following characteristics can be 405 used in an impersonation attack. 407 o homographic name 409 o mixed-alphabet name 411 o name that contains a string termination character 413 o Internet non-unique name (e.g. an internal server name) 415 With the exception of non-unique names, CAs in the Web PKI are 416 required to screen out requests for certificates with any of these 417 characteristics. CAs are required to phase out the practice of 418 issuing non-unique names by 2015 per [BR-certs]. 420 Technically, unless constrained by an upstream CA to issue 421 certificates only in a specific region of the name-space, any CA in 422 the Web PKI can issue an apparently legitimate certificate for any 423 name, whether or not the legitimate holder of that name is aware of 424 or approves the issuance. Furthermore, the legitimate holder of that 425 name may not discover that such a certificate has been issued. 427 5.4. Root CA compromise 429 In the event of a detected compromise of a root CA, its key is 430 blacklisted by means of a software update. This has the effect of 431 invalidating every certificate that is subordinate to that root CA, 432 whether or not the certificate was issued while the compromise 433 existed. This step would have a severe impact upon the CA and its 434 subscribers; this is a step not likely to be taken without being very 435 careful. 437 6. References 439 6.1. IETF Normative References 441 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 442 Housley, R., and W. Polk, "Internet X.509 Public Key 443 Infrastructure Certificate and Certificate Revocation List 444 (CRL) Profile", RFC 5280, May 2008. 446 [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 447 Format", RFC 5914, June 2010. 449 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 450 Transport Security (HSTS)", RFC 6797, November 2012. 452 6.2. IETF Informative References 454 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 455 Requirement Levels", BCP 14, RFC 2119, March 1997. 457 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 458 Wu, "Internet X.509 Public Key Infrastructure Certificate 459 Policy and Certification Practices Framework", RFC 3647, 460 November 2003. 462 Appendix A. Other references 464 [BR-certs] - CA/Browser Forum, Baseline Requirements for the 465 Issuance and Management of Publicly-Trusted Certificates. 466 https://cabforum.org/baseline-requirements-documents/ 468 [Mozilla-CP] - Mozilla CA Certificate Policy. 469 https://www.mozilla.org/projects/security/certs/policy/ 471 Authors' Addresses 473 Inigo Barreira (editor) 474 Izenpe 475 Beato Tomas de Zumarraga 71, 1. 01008 Vitoria-Gasteiz. Spain 477 Email: i-barreira@izenpe.net 479 Bruce Morton (editor) 480 Entrust 481 1000 Innovation Drive. Ottawa, Ontario. Canada K2K 3E7 483 Email: bruce.morton@entrust.com