Internet Engineering Task Force I. Barreira, Ed. Internet-Draft Izenpe Intended status: Best Current Practice B. Morton, Ed. Expires: April 24, 2014 Entrust October 21, 2013 Trust models of the Web PKI draft-ietf-wpkops-trustmodel-00 Abstract This is one of a set of documents to define the operation of the Web PKI. It describes the currently deployed Web PKI trust model. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 24, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Barreira & Morton Expires April 24, 2014 [Page 1] Internet-Draft Trust models of the Web PKI October 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 2. Trust model . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Root store provider . . . . . . . . . . . . . . . . . . . 3 2.2. CA Infrastructure . . . . . . . . . . . . . . . . . . . . 4 2.2.1. Registration Authority . . . . . . . . . . . . . . . 4 2.2.2. Certificate status . . . . . . . . . . . . . . . . . 4 2.3. Subscriber . . . . . . . . . . . . . . . . . . . . . . . 4 2.4. Browser . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Trust Model variants . . . . . . . . . . . . . . . . . . . . 5 3.1. Root store provider variations . . . . . . . . . . . . . 5 3.1.1. Browser adopts root store . . . . . . . . . . . . . . 5 3.2. CA Infrastructure variations . . . . . . . . . . . . . . 5 3.2.1. One root CA cross-certifies another root CA . . . . . 5 3.2.2. Issuing CA is a third party to the root CA . . . . . 5 3.2.3. Registration authority is a third party to the issuing CA . . . . . . . . . . . . . . . . . . . . . 6 3.2.4. Root CA is operated by the government . . . . . . . . 6 3.2.5. Subscriber operates issuing CA . . . . . . . . . . . 6 3.2.6. Subscriber sources management of issuing CA . . . . . 6 3.2.7. Subscriber manages registration authority . . . . . . 6 3.2.8. Subscriber certificate issued by a root CA . . . . . 7 3.3. Subscriber . . . . . . . . . . . . . . . . . . . . . . . 7 3.3.1. Subscriber uses agent . . . . . . . . . . . . . . . . 7 3.4. Browser . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4.1. Browser directly trusts issuing CA key . . . . . . . 7 3.4.2. Browser directly trusts subscriber entity key . . . . 7 3.4.3. Browser supports public key pinning . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5.1. HTTPS is optional . . . . . . . . . . . . . . . . . . . . 8 5.2. Naming of subscribers . . . . . . . . . . . . . . . . . . 8 5.3. Root CA compromise . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction This document defines the Web PKI trust model as it is currently implemented. The trust model is to support communications between the subscriber and the browser. This document does not address future changes to the implemented trust model. Barreira & Morton Expires April 24, 2014 [Page 2] Internet-Draft Trust models of the Web PKI October 2013 1.1. Definitions The use of PKI terminology is used as defined in RFC 5280. Additional definitions are provided below for interpretation of this document. Certificate policy - per RFC 3647. Root CA - a CA with a self-signed certificate and whose public key is included as a trust anchor in a root store. Root certificate - typically a self-signed certificate that identifies the root CA. The root certificate is a type of trust anchor. Root store - a set of root certificates which can be trusted by a browser. Root store policy - the governance policy provided by the root store provider. Subscriber - per RFC 3647. Subscriber agreement - per RFC 3647. Trust anchor - per RFC 5914. 2. Trust model In the Web PKI trust model, a browser uses a root store that contains one or more root CA public keys. Each entry in a browser's root store has been installed on an evaluation made by the browser vendor. Each such root CA issues a certificate to one or more issuing CAs that are under the control of the same CA entity. Each issuing CA accepts and responds to certificate requests from one or more subscribers via one or more registration authorities. 2.1. Root store provider A root store provider (e.g., Microsoft or Mozilla) determines a root store policy. This policy must be met by a candidate root CA in order to be included in the root store. The root store provider installs and manages root certificates in its operating system or browser to support certificate chain validation. The root store provider establishes requirements for accepting a root certificate. These requirements may include legal agreements, security or audit reports by third parties or acceptance by another root store provider. Barreira & Morton Expires April 24, 2014 [Page 3] Internet-Draft Trust models of the Web PKI October 2013 A root store provider requires the root CA to be subject to an annual compliance audit performed by a third party auditor. The audit requirements are defined by the root store policy. The audit is based on an accepted schema of the standards (e.g., WebTrust or ETSI). A third party auditor generates an audit report which is provided to the root store provider. If the audit report states the root CA did not comply with the auditing standards, then the root CA will be required to take corrective actions. Once the corrective actions are completed, then an updated report is submitted to the root store provider. If the status of the root CA is not acceptable to the root store provider, then the root CA certificates may be removed from the root store or the indications from the browser may change for certificates verified under that root CA. 2.2. CA Infrastructure The CA infrastructure consists of a PKI hierarchy. Each organization acting as a CA entity is represented by one or more self-signed certificates. The self-signed certificate is called the root certificate of a root CA. The root CAs sign certificates for subordinate issuing CAs. The root CA may have subordinate intermediate CAs to manage groups of subordinate issuing CAs. The CA entity manages root, intermediate, and issuing CAs and oversees operation of the certificate issuance and management system in accordance with a certificate policy. 2.2.1. Registration Authority Each issuing CA operates a registration authority that authenticates requests for certificates in accordance with the certificate policy. 2.2.2. Certificate status Each CA provides certificate status in the form of a certificate revocation list (CRL) and/or an online certificate status protocol (OCSP) response. Updates and validity periods of the certificate status are provided in accordance with the certificate policy of the CA. The location of the CRL is provided in the certificate CRL distribution point (CDP) OID and the location of the OCSP response is provided in the authority info access (AIA) OID of the issued certificate. 2.3. Subscriber Each subscriber provides services through the browsers to relying parties. The subscriber identifies the online location of its service using a domain name contained in a certificate. The subscriber submits certificate requests in accordance with a CA's Barreira & Morton Expires April 24, 2014 [Page 4] Internet-Draft Trust models of the Web PKI October 2013 certificate policy. Once the certificate request has been accepted, the subscriber will receive the certificate and will manage the certificate in accordance with the subscriber agreement. 2.4. Browser The browser accepts and manages certificates and performs related functions in accordance with the root store policy. 3. Trust Model variants This section defines variants to the roles of the parties as defined in section 2. 3.1. Root store provider variations 3.1.1. Browser adopts root store The browser does not use its own root store, but uses the root store managed by a separate root store provider. 3.2. CA Infrastructure variations 3.2.1. One root CA cross-certifies another root CA Some browsers in active use do not possess the capability to be updated with new root certificates in the field. Consequently, these products do not accept certificates issued by CAs that came into existence after they were first deployed; although the certificates of these CAs are accepted by newer products and ones that can be updated in the field. As such newer CAs operate at a disadvantage to older CAs, and they commonly address this disadvantage by having their public key cross-certified by an older CA. As the cross-certified root CA is also recognized directly by the root store provider, it operates in accordance with the requirements of that certificate policy, in addition to any requirements placed upon it by the contract between it and the cross-certifying root CA. 3.2.2. Issuing CA is a third party to the root CA An issuing CA may operate as a third party subordinate to the root CA. The issuing CA's behavior is governed by its contract with the root CA, which commonly stipulates adherence to the root store policy. Unlike the situation in section 3.2.1, the subordinate issuing CA is not recognized independently by any relationship with the root store provider. Barreira & Morton Expires April 24, 2014 [Page 5] Internet-Draft Trust models of the Web PKI October 2013 3.2.3. Registration authority is a third party to the issuing CA A registration authority may operate as a third party to an issuing CA. A registration authority's behavior is governed by its contract with the issuing CA, which commonly stipulates adherence to the root store policy to which the CA adheres. A third party registration authority is not identified in a CA certificate. 3.2.4. Root CA is operated by the government In the case where a root CA is operated by a government department, a root store provider may rely upon an audit conducted in accordance with the government's own internal audit process. 3.2.5. Subscriber operates issuing CA A subscriber may operate its own issuing CA. Typically, the subscriber is approved to issue certificates only within a specific region of the name-space, and this limitation is enforced by contract. The root CA may use the name constraints certificate extension to limit the region of the name-space in which the issuing CA can issue valid certificates. This is often referred to as an enterprise-based subordinate CA relationship. 3.2.6. Subscriber sources management of issuing CA A root CA may host an issuing CA on behalf of a subscriber. Typically, the subscriber is approved to issue certificates only within a specific region of the name-space, and this limitation is enforced by the host root CA. Examination of the certificate chain would indicate that the issuing CA was owned and operated by the subscriber. This may also be an enterprise-based CA relationship; however, the entity operating the CA (rather than the enterprise subscriber) has immediate control of the CA and physical possession of the CA private key. 3.2.7. Subscriber manages registration authority A subscriber may manage a registration authority. The subscriber is approved to issue certificates only within a specific region of the name-space, and this limitation is enforced by the issuing CA through technical or legal means. This is often referred to an enterprise-based registration authority relationship with the issuing CA. Barreira & Morton Expires April 24, 2014 [Page 6] Internet-Draft Trust models of the Web PKI October 2013 3.2.8. Subscriber certificate issued by a root CA Some legacy situations demand that a certificate be issued directly by a root CA, without the involvement of intermediate issuing CAs. 3.3. Subscriber 3.3.1. Subscriber uses agent A subscriber may use a third party agent to manage its certificates. The third party will request certificates from a registration authority and manage the certificates in accordance with the subscriber agreement on the subscriber's behalf. 3.4. Browser 3.4.1. Browser directly trusts issuing CA key A browser may allow a relying party to designate a CA key as a trust anchor for the purpose of evaluating subscriber certificates. 3.4.2. Browser directly trusts subscriber entity key A browser may allow a relying party to designate a subscriber's certificate as a trust anchor. 3.4.3. Browser supports public key pinning A browser may limit the set of public keys used to verify a certificate containing a domain name. Limitation can be done by including the set of accepted public keys in the browser or by respecting an HTTP header provided by the subscriber. 4. IANA Considerations This memo includes no request to IANA. 5. Security Considerations The trust models described here exhibit several vulnerabilities that could adversely affect the reliability of the authentication they provide. Barreira & Morton Expires April 24, 2014 [Page 7] Internet-Draft Trust models of the Web PKI October 2013 5.1. HTTPS is optional The subscriber does not have to support HTTPS for the web site. The subscriber may provide HTTPS in some cases and not in other cases. As such, the trust model is optional for each web site. In the event of no HTTPS, the browser could more easily be attacked. This attack can be mitigated by supporting HSTS in accordance with RFC 6797. HSTS allows the subscriber to declare to the browser that interactions shall only be done using HTTPS connections. 5.2. Naming of subscribers Subscriber names with any of the following characteristics can be used in an impersonation attack. o homographic name o mixed-alphabet name o name that contains a string termination character o Internet non-unique name (e.g. an internal server name) With the exception of non-unique names, CAs in the Web PKI are required to screen out requests for certificates with any of these characteristics. CAs are required to phase out the practice of issuing non-unique names by 2015. Technically, unless constrained by an upstream CA to issue certificates only in a specific region of the name-space, any CA in the Web PKI can issue an apparently legitimate certificate for any name, whether or not the legitimate holder of that name is aware of or approves the issuance. Furthermore, the legitimate holder of that name may not discover that such a certificate has been issued. 5.3. Root CA compromise In the event of a detected compromise of a root CA, its key is blacklisted by the root store provider by means of a software update. This has the effect of invalidating every certificate that is subordinate to that root CA, whether or not the certificate was issued while the compromise existed. This step would have a severe impact upon the CA and its subscribers; this is a step not likely to be taken without very careful. 6. References Barreira & Morton Expires April 24, 2014 [Page 8] Internet-Draft Trust models of the Web PKI October 2013 6.1. Normative References [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Format", RFC 5914, June 2010. [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict Transport Security (HSTS)", RFC 6797, November 2012. 6.2. Informative References [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, November 2003. Authors' Addresses Inigo Barreira (editor) Izenpe Beato Tomas de Zumarraga 71, 1. 01008 Vitoria-Gasteiz. Spain Phone: +34 945067705 Email: i-barreira@izenpe.net Bruce Morton (editor) Entrust 1000 Innovation Drive. Ottawa, Ontario. Canada K2K 3E7 Phone: +1 613 2703743 Email: bruce.morton@entrust.com Barreira & Morton Expires April 24, 2014 [Page 9]