idnits 2.17.1 draft-barreira-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 (June 26, 2013) is 3950 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: 'RFC3647' is defined on line 350, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 355, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3647 Summary: 1 error (**), 0 flaws (~~), 3 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: December 28, 2013 Entrust 6 June 26, 2013 8 Trust models of the Web PKI 9 draft-barreira-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 and 15 common variants. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 28, 2013. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 53 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Trust model . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Root store provider . . . . . . . . . . . . . . . . . . . 3 56 2.2. CA Infrastructure . . . . . . . . . . . . . . . . . . . . 4 57 2.2.1. CA . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2.2. Registration Authority . . . . . . . . . . . . . . . 4 59 2.2.3. Certificate status . . . . . . . . . . . . . . . . . 4 60 2.2.4. CA audit . . . . . . . . . . . . . . . . . . . . . . 4 61 2.3. Subscriber . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.4. Relying party . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Trust Model variants . . . . . . . . . . . . . . . . . . . . 5 64 3.1. Root Store provider . . . . . . . . . . . . . . . . . . . 5 65 3.1.1. Certificate-using client adopts root store . . . . . 5 66 3.1.2. Certificate-using client uses Trust Service Status 67 List by Recognized Authorities . . . . . . . . . . . 5 68 3.2. CA Infrastructure . . . . . . . . . . . . . . . . . . . . 5 69 3.2.1. One root CA cross-certifies another root CA . . . . . 5 70 3.2.2. Issuing CA is a third party to the root CA . . . . . 6 71 3.2.3. Registration authority is a third party to the 72 issuing CA . . . . . . . . . . . . . . . . . . . . . 6 73 3.2.4. Root CA is operated by the government . . . . . . . . 6 74 3.2.5. Subscriber operates issuing CA . . . . . . . . . . . 6 75 3.2.6. Subscriber sources management of issuing CA . . . . . 6 76 3.2.7. Subscriber manages registration authority . . . . . . 6 77 3.2.8. Subscriber certificate issued by root CA . . . . . . 6 78 3.3. Subscriber . . . . . . . . . . . . . . . . . . . . . . . 7 79 3.3.1. Subscriber uses agent . . . . . . . . . . . . . . . . 7 80 3.4. Relying Party . . . . . . . . . . . . . . . . . . . . . . 7 81 3.4.1. Relying party directly trusts issuing CA key . . . . 7 82 3.4.2. Relying party directly trusts subscriber entity key . 7 83 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 85 6. Normative References . . . . . . . . . . . . . . . . . . . . 8 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 88 1. Introduction 90 1.1. Requirements Language 92 The key words "REQUIRED", "MUST", "MUST NOT" and "MAY" in this 93 document are to be interpreted as described in RFC 2119 [RFC2119] 95 1.2. Definitions 96 The use of PKI terminology is as used as defined in RFC 5280. Other 97 definitions are defined below for interpretation of this document. 99 Root CA - a CA with a certificate, typically self-signed, and 100 whose public key is included in a root store. 102 Root certificate - a self-signed certificate that identifies the 103 root CA. 105 Root store - a set of root certificates which is embedded in a 106 certificate-using client. 108 Root store policy - the policy provided by the root store 109 provider. 111 Subscriber - per RFC 3647. 113 Subscriber agreement - per RFC 3647. 115 Trust service - a service which enhances trust and confidence in 116 electronic transactions. 118 2. Trust model 120 In the Web PKI trust model, a certificate-using client (e.g., 121 operating system or browser) uses a root store that contains one or 122 more root CA public keys. The CAs are under the control of a CA 123 entity and managed in conformance with the root store policy accepted 124 by the certificate-using client supplier. Each such root CA issues a 125 certificate to one or more issuing CAs that are under the control of 126 the same CA entity. Each issuing CA accepts and responds to 127 certificate requests from one or more subscribers via one or more 128 registration authorities. 130 2.1. Root store provider 132 The root store provider (e.g. Microsoft or Mozilla) determines a root 133 store policy. The root store provider stores and manages root 134 certificates in its certificate-using client to support certificate 135 chain validation. The root store provider determines how 136 trustworthiness will be established and provides a trust indication 137 through its certificate-using client to the relying parties. 139 2.2. CA Infrastructure 141 2.2.1. CA 143 The CA infrastructure is a made up of a PKI hierarchy. The CA entity 144 issues one or more self-signed certificates. The self-signed 145 certificate is called a root certificate of a root CA. The root CAs 146 sign certificates for subordinate issuing CAs. The root CA may have 147 subordinate intermediate CAs to manage groups of subordinate issuing 148 CAs. The CA entity manages root, intermediate, issuing CAs and 149 operates the certificate issuance and management system in accordance 150 with a certificate policy. 152 2.2.2. Registration Authority 154 The CA entity operates a registration authority which authenticates 155 requests for certificates in accordance with the certificate policy. 157 2.2.3. Certificate status 159 Each CA provides certificate status in the form of a certificate 160 revocation list (CRL) and/or an online certificate status protocol 161 (OCSP) response. Updates and validity periods of the certificate 162 status are in accordance with the certificate policy. The location 163 of the CRL or the OCSP response is provided as a URL posted in an OID 164 of the issued certificate. 166 2.2.4. CA audit 168 The CA is subject to an annual compliance audit performed by a third 169 party auditing body as prescribed by the root store policy. 171 2.3. Subscriber 173 The subscriber provides services through the certificate-using 174 clients to relying parties. The subscriber identifies a relationship 175 of its service to a domain name through a certificate. The 176 subscriber submits certificate requests in accordance with the 177 certificate policy. Once the certificate request has been accepted, 178 the subscriber will receive the certificate and will manage the 179 certificate in accordance with the subscriber agreement. 181 2.4. Relying party 183 The relying party uses a certificate-using client in communication 184 with a subscriber. The relying party implicitly accepts the root 185 store policy and the certificate policy by choosing to use a 186 particular certificate-using client. 188 3. Trust Model variants 190 This section defines variants to the roles of the parties as defined 191 in section 2 193 3.1. Root Store provider 195 3.1.1. Certificate-using client adopts root store 197 The certificate-using client does not use its own root store, but 198 uses the root store managed by a separate root store provider. 199 Usually, the certificate-using client evaluates the subscriber's 200 certificate and may check the certificate subject's domain name 201 matches that requested by the subscriber. 203 3.1.2. Certificate-using client uses Trust Service Status List by 204 Recognized Authorities 206 One or more authorities (e.g., EU national regulatory authorities) 207 provide a list of CAs which have been assessed for trustworthiness 208 for specific purposes (e.g. web sites meeting EU regulations), called 209 the Trust Service Status List (TSSL). The root store provider adopts 210 the TSSL as the list of root certificates to be contained in the root 211 store. 213 3.2. CA Infrastructure 215 3.2.1. One root CA cross-certifies another root CA 217 A small but significant portion of the certificate-using clients in 218 active use does not possess the capability to be updated in the 219 field. Consequently, these products do not accept certificates 220 issued by CAs that came into existence after they were first 221 deployed. Although their certificates are accepted by newer products 222 and ones that can be updated in the field, newer CAs operate at a 223 disadvantage to older CAs, and they commonly address this 224 disadvantage by having their public key cross-certified by an older 225 CA. As the cross-certified root CA is also recognized directly by 226 the root store provider, it operates in accordance with the 227 requirements of that certificate policy, regardless of any 228 requirements placed upon it by the contract between it and the cross- 229 certifying root CA. 231 3.2.2. Issuing CA is a third party to the root CA 233 The issuing CA may operate as a third party to the root CA. The 234 issuing CA's behavior is governed by its contract with the root CA, 235 which commonly stipulates adherence to the root store policy. 237 3.2.3. Registration authority is a third party to the issuing CA 239 The registration authority may operate as a third party to the 240 issuing CA. The registration authority's behavior is governed by its 241 contract with the issuing CA, which commonly stipulates adherence to 242 the root store policy. 244 3.2.4. Root CA is operated by the government 246 In the case where the root CA is operated by a government department, 247 the root store provider may relax the requirement for a fully- 248 independent third-party audit, relying instead upon an audit 249 conducted in accordance with the government's own internal audit 250 process. 252 3.2.5. Subscriber operates issuing CA 254 A subscriber may operate its own issuing CA. Typically, the 255 subscriber is approved to issue certificates only within a specific 256 region of the name-space, and this limitation is enforced by contract 257 or technical constraints. The root CA may use the name constraints 258 certificate extension to limit the region of the name-space in which 259 the issuing CA can issue valid certificates. 261 3.2.6. Subscriber sources management of issuing CA 263 A root CA may host an issuing CA on behalf of a subscriber. 264 Typically, the subscriber is approved to issue certificates only 265 within a specific region of the name-space, and this limitation is 266 enforced by the host root CA. Examination of the certificate chain 267 would indicate that the issuing CA was owned and operated by the 268 subscriber. 270 3.2.7. Subscriber manages registration authority 272 A subscriber may manage a registration authority. The subscriber is 273 approved to issue certificates only within a specific region of the 274 name-space, and this limitation is enforced by the issuing CA. 276 3.2.8. Subscriber certificate issued by root CA 277 Some legacy situations demand that the certificate be issued directly 278 by the root CA, without the involvement of issuing CAs. This model 279 is now deprecated, but the practice will remain in effect 280 indefinitely. 282 3.3. Subscriber 284 3.3.1. Subscriber uses agent 286 The subscriber may use a third party agent to manage their 287 certificates. The third party will request certificates from the 288 registration authority and manage the certificates in accordance with 289 the subscriber agreement. 291 3.4. Relying Party 293 3.4.1. Relying party directly trusts issuing CA key 295 The certificate-using client may allow the relying party to designate 296 a CA key as trusted, a priori, for the purpose of evaluating 297 subscriber certificates. 299 3.4.2. Relying party directly trusts subscriber entity key 301 The certificate-using client may allow the relying party to designate 302 a subscriber as trusted, a priori. 304 4. IANA Considerations 306 This memo includes no request to IANA. 308 5. Security Considerations 310 The trust models described here exhibit several vulnerabilities that 311 could adversely affect the reliability of the authentication they 312 provide. The first concerns the naming of subscribers. The second 313 concerns controllability and observability of issued certificates. 315 Subscriber names with any of the following characteristics can be 316 used in an impersonation attack. 318 o homographic name 320 o mixed-alphabet name 322 o name that contains a string termination character 324 o non-unique name (e.g. an internal server name) 325 With the exception of non-unique names, CAs in the Web PKI are 326 required to screen out requests for certificates with any of these 327 characteristics. CAs are required to phase out the practice of 328 issuing non-unique names by 2016. 330 Technically, unless constrained by an upstream CA to issue 331 certificates only in a specific region of the name-space, any CA in 332 the Web PKI can issue an apparently legitimate certificate for any 333 name, whether or not the legitimate holder of that name is aware of 334 or approves the issuance. Furthermore, the legitimate holder of that 335 name may not discover that such a certificate has been issued. 337 In the event of a compromise of a root CA, its key is blacklisted by 338 certificate-using products by means of a software update. This has 339 the effect of invalidating every otherwise-valid certificate that 340 chains to that root, whether or not it was issued while the 341 compromise existed. This step would have a severe impact upon the CA 342 and its certificate holders; a step not likely to be taken without 343 very careful deliberation and (perhaps) hesitation. 345 6. Normative References 347 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 348 Requirement Levels", BCP 14, RFC 2119, March 1997. 350 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 351 Wu, "Internet X.509 Public Key Infrastructure Certificate 352 Policy and Certification Practices Framework", RFC 3647, 353 November 2003. 355 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 356 Housley, R., and W. Polk, "Internet X.509 Public Key 357 Infrastructure Certificate and Certificate Revocation List 358 (CRL) Profile", RFC 5280, May 2008. 360 Authors' Addresses 362 Inigo Barreira (editor) 363 Izenpe 364 Beato Tomas de Zumarraga 71, 1. 01008 Vitoria-Gasteiz. Spain 366 Phone: +34 945067705 367 Email: i-barreira@izenpe.net 368 Bruce Morton (editor) 369 Entrust 370 1000 Innovation Drive. Ottawa, Ontario. Canada K2K 3E7 372 Email: bruce.morton@entrust.com