idnits 2.17.1 draft-ietf-wpkops-trustmodel-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2013) is 3840 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) == Unused Reference: 'RFC5280' is defined on line 379, but no explicit reference was found in the text == Unused Reference: 'RFC5914' is defined on line 384, but no explicit reference was found in the text == Unused Reference: 'RFC6797' is defined on line 387, but no explicit reference was found in the text == Unused Reference: 'RFC3647' is defined on line 392, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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: April 24, 2014 Entrust 6 October 21, 2013 8 Trust models of the Web PKI 9 draft-ietf-wpkops-trustmodel-00 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 model. 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 April 24, 2014. 33 Copyright Notice 35 Copyright (c) 2013 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. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Trust model . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Root store provider . . . . . . . . . . . . . . . . . . . 3 54 2.2. CA Infrastructure . . . . . . . . . . . . . . . . . . . . 4 55 2.2.1. Registration Authority . . . . . . . . . . . . . . . 4 56 2.2.2. Certificate status . . . . . . . . . . . . . . . . . 4 57 2.3. Subscriber . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.4. Browser . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Trust Model variants . . . . . . . . . . . . . . . . . . . . 5 60 3.1. Root store provider variations . . . . . . . . . . . . . 5 61 3.1.1. Browser adopts root store . . . . . . . . . . . . . . 5 62 3.2. CA Infrastructure variations . . . . . . . . . . . . . . 5 63 3.2.1. One root CA cross-certifies another root CA . . . . . 5 64 3.2.2. Issuing CA is a third party to the root CA . . . . . 5 65 3.2.3. Registration authority is a third party to the 66 issuing CA . . . . . . . . . . . . . . . . . . . . . 6 67 3.2.4. Root CA is operated by the government . . . . . . . . 6 68 3.2.5. Subscriber operates issuing CA . . . . . . . . . . . 6 69 3.2.6. Subscriber sources management of issuing CA . . . . . 6 70 3.2.7. Subscriber manages registration authority . . . . . . 6 71 3.2.8. Subscriber certificate issued by a root CA . . . . . 7 72 3.3. Subscriber . . . . . . . . . . . . . . . . . . . . . . . 7 73 3.3.1. Subscriber uses agent . . . . . . . . . . . . . . . . 7 74 3.4. Browser . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 3.4.1. Browser directly trusts issuing CA key . . . . . . . 7 76 3.4.2. Browser directly trusts subscriber entity key . . . . 7 77 3.4.3. Browser supports public key pinning . . . . . . . . . 7 78 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 80 5.1. HTTPS is optional . . . . . . . . . . . . . . . . . . . . 8 81 5.2. Naming of subscribers . . . . . . . . . . . . . . . . . . 8 82 5.3. Root CA compromise . . . . . . . . . . . . . . . . . . . 8 83 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 85 6.2. Informative References . . . . . . . . . . . . . . . . . 9 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 88 1. Introduction 90 This document defines the Web PKI trust model as it is currently 91 implemented. The trust model is to support communications between 92 the subscriber and the browser. This document does not address 93 future changes to the implemented trust model. 95 1.1. Definitions 97 The use of PKI terminology is used as defined in RFC 5280. 98 Additional definitions are provided below for interpretation of this 99 document. 101 Certificate policy - per RFC 3647. 103 Root CA - a CA with a self-signed certificate and whose public key 104 is included as a trust anchor in a root store. 106 Root certificate - typically a self-signed certificate that 107 identifies the root CA. The root certificate is a type of trust 108 anchor. 110 Root store - a set of root certificates which can be trusted by a 111 browser. 113 Root store policy - the governance policy provided by the root 114 store provider. 116 Subscriber - per RFC 3647. 118 Subscriber agreement - per RFC 3647. 120 Trust anchor - per RFC 5914. 122 2. Trust model 124 In the Web PKI trust model, a browser uses a root store that contains 125 one or more root CA public keys. Each entry in a browser's root 126 store has been installed on an evaluation made by the browser vendor. 127 Each such root CA issues a certificate to one or more issuing CAs 128 that are under the control of the same CA entity. Each issuing CA 129 accepts and responds to certificate requests from one or more 130 subscribers via one or more registration authorities. 132 2.1. Root store provider 134 A root store provider (e.g., Microsoft or Mozilla) determines a root 135 store policy. This policy must be met by a candidate root CA in 136 order to be included in the root store. The root store provider 137 installs and manages root certificates in its operating system or 138 browser to support certificate chain validation. The root store 139 provider establishes requirements for accepting a root certificate. 140 These requirements may include legal agreements, security or audit 141 reports by third parties or acceptance by another root store 142 provider. 144 A root store provider requires the root CA to be subject to an annual 145 compliance audit performed by a third party auditor. The audit 146 requirements are defined by the root store policy. The audit is 147 based on an accepted schema of the standards (e.g., WebTrust or 148 ETSI). A third party auditor generates an audit report which is 149 provided to the root store provider. If the audit report states the 150 root CA did not comply with the auditing standards, then the root CA 151 will be required to take corrective actions. Once the corrective 152 actions are completed, then an updated report is submitted to the 153 root store provider. If the status of the root CA is not acceptable 154 to the root store provider, then the root CA certificates may be 155 removed from the root store or the indications from the browser may 156 change for certificates verified under that root CA. 158 2.2. CA Infrastructure 160 The CA infrastructure consists of a PKI hierarchy. Each organization 161 acting as a CA entity is represented by one or more self-signed 162 certificates. The self-signed certificate is called the root 163 certificate of a root CA. The root CAs sign certificates for 164 subordinate issuing CAs. The root CA may have subordinate 165 intermediate CAs to manage groups of subordinate issuing CAs. The CA 166 entity manages root, intermediate, and issuing CAs and oversees 167 operation of the certificate issuance and management system in 168 accordance with a certificate policy. 170 2.2.1. Registration Authority 172 Each issuing CA operates a registration authority that authenticates 173 requests for certificates in accordance with the certificate policy. 175 2.2.2. Certificate status 177 Each CA provides certificate status in the form of a certificate 178 revocation list (CRL) and/or an online certificate status protocol 179 (OCSP) response. Updates and validity periods of the certificate 180 status are provided in accordance with the certificate policy of the 181 CA. The location of the CRL is provided in the certificate CRL 182 distribution point (CDP) OID and the location of the OCSP response is 183 provided in the authority info access (AIA) OID of the issued 184 certificate. 186 2.3. Subscriber 188 Each subscriber provides services through the browsers to relying 189 parties. The subscriber identifies the online location of its 190 service using a domain name contained in a certificate. The 191 subscriber submits certificate requests in accordance with a CA's 192 certificate policy. Once the certificate request has been accepted, 193 the subscriber will receive the certificate and will manage the 194 certificate in accordance with the subscriber agreement. 196 2.4. Browser 198 The browser accepts and manages certificates and performs related 199 functions in accordance with the root store policy. 201 3. Trust Model variants 203 This section defines variants to the roles of the parties as defined 204 in section 2. 206 3.1. Root store provider variations 208 3.1.1. Browser adopts root store 210 The browser does not use its own root store, but uses the root store 211 managed by a separate root store provider. 213 3.2. CA Infrastructure variations 215 3.2.1. One root CA cross-certifies another root CA 217 Some browsers in active use do not possess the capability to be 218 updated with new root certificates in the field. Consequently, these 219 products do not accept certificates issued by CAs that came into 220 existence after they were first deployed; although the certificates 221 of these CAs are accepted by newer products and ones that can be 222 updated in the field. As such newer CAs operate at a disadvantage to 223 older CAs, and they commonly address this disadvantage by having 224 their public key cross-certified by an older CA. 226 As the cross-certified root CA is also recognized directly by the 227 root store provider, it operates in accordance with the requirements 228 of that certificate policy, in addition to any requirements placed 229 upon it by the contract between it and the cross-certifying root CA. 231 3.2.2. Issuing CA is a third party to the root CA 233 An issuing CA may operate as a third party subordinate to the root 234 CA. The issuing CA's behavior is governed by its contract with the 235 root CA, which commonly stipulates adherence to the root store 236 policy. Unlike the situation in section 3.2.1, the subordinate 237 issuing CA is not recognized independently by any relationship with 238 the root store provider. 240 3.2.3. Registration authority is a third party to the issuing CA 242 A registration authority may operate as a third party to an issuing 243 CA. A registration authority's behavior is governed by its contract 244 with the issuing CA, which commonly stipulates adherence to the root 245 store policy to which the CA adheres. A third party registration 246 authority is not identified in a CA certificate. 248 3.2.4. Root CA is operated by the government 250 In the case where a root CA is operated by a government department, a 251 root store provider may rely upon an audit conducted in accordance 252 with the government's own internal audit process. 254 3.2.5. Subscriber operates issuing CA 256 A subscriber may operate its own issuing CA. Typically, the 257 subscriber is approved to issue certificates only within a specific 258 region of the name-space, and this limitation is enforced by 259 contract. The root CA may use the name constraints certificate 260 extension to limit the region of the name-space in which the issuing 261 CA can issue valid certificates. This is often referred to as an 262 enterprise-based subordinate CA relationship. 264 3.2.6. Subscriber sources management of issuing CA 266 A root CA may host an issuing CA on behalf of a subscriber. 267 Typically, the subscriber is approved to issue certificates only 268 within a specific region of the name-space, and this limitation is 269 enforced by the host root CA. Examination of the certificate chain 270 would indicate that the issuing CA was owned and operated by the 271 subscriber. 273 This may also be an enterprise-based CA relationship; however, the 274 entity operating the CA (rather than the enterprise subscriber) has 275 immediate control of the CA and physical possession of the CA private 276 key. 278 3.2.7. Subscriber manages registration authority 280 A subscriber may manage a registration authority. The subscriber is 281 approved to issue certificates only within a specific region of the 282 name-space, and this limitation is enforced by the issuing CA through 283 technical or legal means. 285 This is often referred to an enterprise-based registration authority 286 relationship with the issuing CA. 288 3.2.8. Subscriber certificate issued by a root CA 290 Some legacy situations demand that a certificate be issued directly 291 by a root CA, without the involvement of intermediate issuing CAs. 293 3.3. Subscriber 295 3.3.1. Subscriber uses agent 297 A subscriber may use a third party agent to manage its certificates. 298 The third party will request certificates from a registration 299 authority and manage the certificates in accordance with the 300 subscriber agreement on the subscriber's behalf. 302 3.4. Browser 304 3.4.1. Browser directly trusts issuing CA key 306 A browser may allow a relying party to designate a CA key as a trust 307 anchor for the purpose of evaluating subscriber certificates. 309 3.4.2. Browser directly trusts subscriber entity key 311 A browser may allow a relying party to designate a subscriber's 312 certificate as a trust anchor. 314 3.4.3. Browser supports public key pinning 316 A browser may limit the set of public keys used to verify a 317 certificate containing a domain name. Limitation can be done by 318 including the set of accepted public keys in the browser or by 319 respecting an HTTP header provided by the subscriber. 321 4. IANA Considerations 323 This memo includes no request to IANA. 325 5. Security Considerations 327 The trust models described here exhibit several vulnerabilities that 328 could adversely affect the reliability of the authentication they 329 provide. 331 5.1. HTTPS is optional 333 The subscriber does not have to support HTTPS for the web site. The 334 subscriber may provide HTTPS in some cases and not in other cases. 335 As such, the trust model is optional for each web site. In the event 336 of no HTTPS, the browser could more easily be attacked. This attack 337 can be mitigated by supporting HSTS in accordance with RFC 6797. 338 HSTS allows the subscriber to declare to the browser that 339 interactions shall only be done using HTTPS connections. 341 5.2. Naming of subscribers 343 Subscriber names with any of the following characteristics can be 344 used in an impersonation attack. 346 o homographic name 348 o mixed-alphabet name 350 o name that contains a string termination character 352 o Internet non-unique name (e.g. an internal server name) 354 With the exception of non-unique names, CAs in the Web PKI are 355 required to screen out requests for certificates with any of these 356 characteristics. CAs are required to phase out the practice of 357 issuing non-unique names by 2015. 359 Technically, unless constrained by an upstream CA to issue 360 certificates only in a specific region of the name-space, any CA in 361 the Web PKI can issue an apparently legitimate certificate for any 362 name, whether or not the legitimate holder of that name is aware of 363 or approves the issuance. Furthermore, the legitimate holder of that 364 name may not discover that such a certificate has been issued. 366 5.3. Root CA compromise 368 In the event of a detected compromise of a root CA, its key is 369 blacklisted by the root store provider by means of a software update. 370 This has the effect of invalidating every certificate that is 371 subordinate to that root CA, whether or not the certificate was 372 issued while the compromise existed. This step would have a severe 373 impact upon the CA and its subscribers; this is a step not likely to 374 be taken without very careful. 376 6. References 377 6.1. Normative References 379 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 380 Housley, R., and W. Polk, "Internet X.509 Public Key 381 Infrastructure Certificate and Certificate Revocation List 382 (CRL) Profile", RFC 5280, May 2008. 384 [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 385 Format", RFC 5914, June 2010. 387 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 388 Transport Security (HSTS)", RFC 6797, November 2012. 390 6.2. Informative References 392 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 393 Wu, "Internet X.509 Public Key Infrastructure Certificate 394 Policy and Certification Practices Framework", RFC 3647, 395 November 2003. 397 Authors' Addresses 399 Inigo Barreira (editor) 400 Izenpe 401 Beato Tomas de Zumarraga 71, 1. 01008 Vitoria-Gasteiz. Spain 403 Phone: +34 945067705 404 Email: i-barreira@izenpe.net 406 Bruce Morton (editor) 407 Entrust 408 1000 Innovation Drive. Ottawa, Ontario. Canada K2K 3E7 410 Phone: +1 613 2703743 411 Email: bruce.morton@entrust.com