Internet Engineering Task Force I. Barreira, Ed. Internet-Draft Izenpe Intended status: Best Current Practice B. Morton, Ed. Expires: December 28, 2013 Entrust June 26, 2013 Trust models of the Web PKI draft-barreira-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 and common variants. 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 December 28, 2013. 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 December 28, 2013 [Page 1] Internet-Draft Trust models of the Web PKI June 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 2 2. Trust model . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Root store provider . . . . . . . . . . . . . . . . . . . 3 2.2. CA Infrastructure . . . . . . . . . . . . . . . . . . . . 4 2.2.1. CA . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2.2. Registration Authority . . . . . . . . . . . . . . . 4 2.2.3. Certificate status . . . . . . . . . . . . . . . . . 4 2.2.4. CA audit . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Subscriber . . . . . . . . . . . . . . . . . . . . . . . 4 2.4. Relying party . . . . . . . . . . . . . . . . . . . . . . 4 3. Trust Model variants . . . . . . . . . . . . . . . . . . . . 5 3.1. Root Store provider . . . . . . . . . . . . . . . . . . . 5 3.1.1. Certificate-using client adopts root store . . . . . 5 3.1.2. Certificate-using client uses Trust Service Status List by Recognized Authorities . . . . . . . . . . . 5 3.2. CA Infrastructure . . . . . . . . . . . . . . . . . . . . 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 . . . . . 6 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 root CA . . . . . . 6 3.3. Subscriber . . . . . . . . . . . . . . . . . . . . . . . 7 3.3.1. Subscriber uses agent . . . . . . . . . . . . . . . . 7 3.4. Relying Party . . . . . . . . . . . . . . . . . . . . . . 7 3.4.1. Relying party directly trusts issuing CA key . . . . 7 3.4.2. Relying party directly trusts subscriber entity key . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Normative References . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction 1.1. Requirements Language The key words "REQUIRED", "MUST", "MUST NOT" and "MAY" in this document are to be interpreted as described in RFC 2119 [RFC2119] 1.2. Definitions Barreira & Morton Expires December 28, 2013 [Page 2] Internet-Draft Trust models of the Web PKI June 2013 The use of PKI terminology is as used as defined in RFC 5280. Other definitions are defined below for interpretation of this document. Root CA - a CA with a certificate, typically self-signed, and whose public key is included in a root store. Root certificate - a self-signed certificate that identifies the root CA. Root store - a set of root certificates which is embedded in a certificate-using client. Root store policy - the policy provided by the root store provider. Subscriber - per RFC 3647. Subscriber agreement - per RFC 3647. Trust service - a service which enhances trust and confidence in electronic transactions. 2. Trust model In the Web PKI trust model, a certificate-using client (e.g., operating system or browser) uses a root store that contains one or more root CA public keys. The CAs are under the control of a CA entity and managed in conformance with the root store policy accepted by the certificate-using client supplier. 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 The root store provider (e.g. Microsoft or Mozilla) determines a root store policy. The root store provider stores and manages root certificates in its certificate-using client to support certificate chain validation. The root store provider determines how trustworthiness will be established and provides a trust indication through its certificate-using client to the relying parties. Barreira & Morton Expires December 28, 2013 [Page 3] Internet-Draft Trust models of the Web PKI June 2013 2.2. CA Infrastructure 2.2.1. CA The CA infrastructure is a made up of a PKI hierarchy. The CA entity issues one or more self-signed certificates. The self-signed certificate is called a 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, issuing CAs and operates the certificate issuance and management system in accordance with a certificate policy. 2.2.2. Registration Authority The CA entity operates a registration authority which authenticates requests for certificates in accordance with the certificate policy. 2.2.3. 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 in accordance with the certificate policy. The location of the CRL or the OCSP response is provided as a URL posted in an OID of the issued certificate. 2.2.4. CA audit The CA is subject to an annual compliance audit performed by a third party auditing body as prescribed by the root store policy. 2.3. Subscriber The subscriber provides services through the certificate-using clients to relying parties. The subscriber identifies a relationship of its service to a domain name through a certificate. The subscriber submits certificate requests in accordance with the 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. Relying party The relying party uses a certificate-using client in communication with a subscriber. The relying party implicitly accepts the root store policy and the certificate policy by choosing to use a particular certificate-using client. Barreira & Morton Expires December 28, 2013 [Page 4] Internet-Draft Trust models of the Web PKI June 2013 3. Trust Model variants This section defines variants to the roles of the parties as defined in section 2 3.1. Root Store provider 3.1.1. Certificate-using client adopts root store The certificate-using client does not use its own root store, but uses the root store managed by a separate root store provider. Usually, the certificate-using client evaluates the subscriber's certificate and may check the certificate subject's domain name matches that requested by the subscriber. 3.1.2. Certificate-using client uses Trust Service Status List by Recognized Authorities One or more authorities (e.g., EU national regulatory authorities) provide a list of CAs which have been assessed for trustworthiness for specific purposes (e.g. web sites meeting EU regulations), called the Trust Service Status List (TSSL). The root store provider adopts the TSSL as the list of root certificates to be contained in the root store. 3.2. CA Infrastructure 3.2.1. One root CA cross-certifies another root CA A small but significant portion of the certificate-using clients in active use does not possess the capability to be updated in the field. Consequently, these products do not accept certificates issued by CAs that came into existence after they were first deployed. Although their certificates are accepted by newer products and ones that can be updated in the field, 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, regardless of any requirements placed upon it by the contract between it and the cross- certifying root CA. Barreira & Morton Expires December 28, 2013 [Page 5] Internet-Draft Trust models of the Web PKI June 2013 3.2.2. Issuing CA is a third party to the root CA The issuing CA may operate as a third party 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. 3.2.3. Registration authority is a third party to the issuing CA The registration authority may operate as a third party to the issuing CA. The registration authority's behavior is governed by its contract with the issuing CA, which commonly stipulates adherence to the root store policy. 3.2.4. Root CA is operated by the government In the case where the root CA is operated by a government department, the root store provider may relax the requirement for a fully- independent third-party audit, relying instead 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 or technical constraints. 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. 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. 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. 3.2.8. Subscriber certificate issued by root CA Barreira & Morton Expires December 28, 2013 [Page 6] Internet-Draft Trust models of the Web PKI June 2013 Some legacy situations demand that the certificate be issued directly by the root CA, without the involvement of issuing CAs. This model is now deprecated, but the practice will remain in effect indefinitely. 3.3. Subscriber 3.3.1. Subscriber uses agent The subscriber may use a third party agent to manage their certificates. The third party will request certificates from the registration authority and manage the certificates in accordance with the subscriber agreement. 3.4. Relying Party 3.4.1. Relying party directly trusts issuing CA key The certificate-using client may allow the relying party to designate a CA key as trusted, a priori, for the purpose of evaluating subscriber certificates. 3.4.2. Relying party directly trusts subscriber entity key The certificate-using client may allow the relying party to designate a subscriber as trusted, a priori. 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. The first concerns the naming of subscribers. The second concerns controllability and observability of issued certificates. 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 non-unique name (e.g. an internal server name) Barreira & Morton Expires December 28, 2013 [Page 7] Internet-Draft Trust models of the Web PKI June 2013 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 2016. 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. In the event of a compromise of a root CA, its key is blacklisted by certificate-using products by means of a software update. This has the effect of invalidating every otherwise-valid certificate that chains to that root, whether or not it was issued while the compromise existed. This step would have a severe impact upon the CA and its certificate holders; a step not likely to be taken without very careful deliberation and (perhaps) hesitation. 6. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [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. Authors' Addresses Inigo Barreira (editor) Izenpe Beato Tomas de Zumarraga 71, 1. 01008 Vitoria-Gasteiz. Spain Phone: +34 945067705 Email: i-barreira@izenpe.net Barreira & Morton Expires December 28, 2013 [Page 8] Internet-Draft Trust models of the Web PKI June 2013 Bruce Morton (editor) Entrust 1000 Innovation Drive. Ottawa, Ontario. Canada K2K 3E7 Email: bruce.morton@entrust.com Barreira & Morton Expires December 28, 2013 [Page 9]