Internet Engineering Task Force T. Moses, Ed. Internet-Draft Entrust Ltd. Intended status: BCP September 4, 2012 Expires: March 8, 2013 Trust models of the Web PKI draft-moses-webpki-trustmodel-00 Abstract This is one of a set of drafts that document the operation of the Web PKI. It describes common variants of the 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 March 8, 2013. Copyright Notice Copyright (c) 2012 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. Moses Expires March 8, 2013 [Page 1] Internet-Draft Trust models of the Web PKI September 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Graphical conventions . . . . . . . . . . . . . . . . . . 3 2. Basic trust model . . . . . . . . . . . . . . . . . . . . . . 4 3. Trust model variants . . . . . . . . . . . . . . . . . . . . . 5 3.1. Client application uses OS root store . . . . . . . . . . 5 3.2. Subscriber certificates issued by root CA . . . . . . . . 6 3.3. One root CA cross-certifies another root CA . . . . . . . 6 3.4. Issuing CA is an affiliate . . . . . . . . . . . . . . . . 7 3.5. Registration authority is an affiliate . . . . . . . . . . 8 3.6. The root CA is operated by a government . . . . . . . . . 9 3.7. The certificate user directly trusts an issuing CA . . . . 9 3.8. The certificate user directly trusts a certificate-holder certificate . . . . . . . . . . . . . . 10 3.9. Certificate holder operates issuing CA . . . . . . . . . . 10 3.10. Certificate holder manages issuing CA . . . . . . . . . . 11 3.11. Certificate holder manages RA . . . . . . . . . . . . . . 12 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Normative References . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Moses Expires March 8, 2013 [Page 2] Internet-Draft Trust models of the Web PKI September 2012 1. Introduction 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.2. Graphical conventions The graphical conventions used in this document are illustrated in Figure 1. --------------------------------------------------------- | Unaffiliated user | | ----------------- | | | | Certificate User | |---------------------------------------------------------| | Certificate-using product supplier | | ---------------------------------- | | | 0..1 | | Policy Management Authority v -> 0..many | |---------------------------------------------------------| | Commercial CA | | ------------- | | | 1..2 | | Root CA v -> 1..many | | --------------------------------------------------------- | | Web-site operator | | | ----------------- | | | | 0..1 | | | Issuing CA v -> 0..many | | | | | | | 1 | | | Registration Authority v -> 1..many | --| | | | 1 | | Certificate Holder v -> 1..many | --------------------------------------------------------- Figure 1: Graphical conventions Each entry in the diagram (e.g. "Root CA") represents a function of the Web PKI. Each function imports and verifies credentials from the function directly below it and (in some cases) exports a certificate containing the credential. Moses Expires March 8, 2013 [Page 3] Internet-Draft Trust models of the Web PKI September 2012 Vertical cardinality (represented by a down arrow) indicates recursive depth, whereas horizontal cardinality (represented by a right arrow) indicates selection breadth. The boxes delineate the boundaries of distinct entities (e.g. arms- length businesses or natural persons), example names for which appear underlined in the top lefthand corner of the box. Where boxes appear overlaid ( "Issuing CA" and "Registration Authority"), it indicates that the function is the responsibility of the overlying entity, but it is hosted by the underlying entity. 2. Basic trust model The basic server-authentication trust model is shown in Figure 2. --------------------------------------------------------- | Unaffiliated user | | ----------------- | | | | Certificate User | |---------------------------------------------------------| | Certificate-using product supplier | | ---------------------------------- | | | 1 | | Policy Management Authority v -> 1..many | |---------------------------------------------------------| | Commercial CA | | ------------- | | | 1 | | Root CA v -> 1..many | | | | | 1 | | Issuing CA v -> 1..many | | | | | 1 | | Registration Authority v -> 1..many | |---------------------------------------------------------| | Web-site operator | | ----------------- | | | 1 | | Certificate Holder v -> 1..many | --------------------------------------------------------- Figure 2: Basic server-authentication trust model The certificate user implicitly accepts the policy of the policy Moses Expires March 8, 2013 [Page 4] Internet-Draft Trust models of the Web PKI September 2012 management authority by choosing to use a particular certificate- using product. However, some product suppliers adopt the policies of other suppliers by copying their root store, without seeking independent evidence of conformance. All functions of the commercial CA are subject to the audit process prescribed by the policy management authority. If the roles of the unaffiliated user and the Web site operator were to be reversed, then the figure would depict the use of the Web PKI for client authentication. 3. Trust model variants There are several variants of the basic trust model in common use. 3.1. Client application uses OS root store The situation is shown in Figure 3. --------------------------------------------------------- | Unaffiliated user | | ----------------- | | | | Certificate User | |---------------------------------------------------------| | Certificate-using product supplier | | ---------------------------------- | | | 1 | | Client v -> 1 | |---------------------------------------------------------| | OS supplier | | ----------- | | | 1 | | Policy Management Authority v -> 1..many | |---------------------------------------------------------| | Commercial CA | | ------------- | | | 1 | | Root CA v -> 1..many | |---------------------------------------------------------| | | | | Figure 3: Client application uses OS root store In this variant, the certificate user software does not use its own Moses Expires March 8, 2013 [Page 5] Internet-Draft Trust models of the Web PKI September 2012 root store. Instead, it uses the platform operating system root store and certificate processing functions to validate the certificate-holder's certificate. It may then apply additional checks, such as checking that the certificate subject's domain name matches that requested by the certificate user. 3.2. Subscriber certificates issued by root CA Some legacy situations demand that the certificate-holder certificate be issued directly by the root CA, without the involvement of intermediate or issuing CAs, see Figure 4. This model is now deprecated, but the practice will remain in effect indefinitely. --------------------------------------------------------- | Legacy client | | ------------- | | | | Certificate User | |---------------------------------------------------------| | Certificate-using product supplier | | ---------------------------------- | | | 1 | | Policy Management Authority v -> 1..many | |---------------------------------------------------------| | Commercial CA | | ------------- | | | 1 | | Root CA v -> 1..many | |---------------------------------------------------------| | Server operator | | --------------- | | | 1 | | Certificate Holder v -> 1..many | --------------------------------------------------------- Figure 4: Certificate holder certificate issued by root CA 3.3. One root CA cross-certifies another root CA A small but significant portion of the certificate-using products 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 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. See Figure 5. Moses Expires March 8, 2013 [Page 6] Internet-Draft Trust models of the Web PKI September 2012 --------------------------------------------------------- | Unaffiliated user | | ----------------- | | | | Certificate User | |---------------------------------------------------------| | Certificate-using product supplier | | ---------------------------------- | | | 1 | | Policy Management Authority v -> 1..many | |---------------------------------------------------------| | Commercial CA | | ------------- | | | 2 | | Root CA v -> 1..many | | | Figure 5: One root CA certifies another root CA Because the cross-certified root CA is recognized directly by a policy management authority, it operates in accordance with the requirements of that policy management authority, regardless of any requirements placed upon it by the contract between it and the cross- certifying root CA. 3.4. Issuing CA is an affiliate The issuing CA may operate at arms-length to the root CA, as shown in Figure 6. Moses Expires March 8, 2013 [Page 7] Internet-Draft Trust models of the Web PKI September 2012 | | |---------------------------------------------------------| | Commercial CA | | ------------- | | | 1 | | Root CA v -> 1..many | |---------------------------------------------------------| | Affiliate | | --------- | | | 1 | | Issuing CA v -> 1..many | | | | | 1 | | Registration Authority v -> 1..many | |---------------------------------------------------------| | Web site operator | | ----------------- | | | 1 | | Certificate Holder v -> 1..many | --------------------------------------------------------- Figure 6: Issuing CA affiliated to root CA The affiliate's behavior is governed by its contract with the root CA, which commonly stipulates adherence to the policies of the policy management authority. 3.5. Registration authority is an affiliate The registration authority may operate at arms-length to the issuing CA, as shown in Figure 7. | | | | | | 1 | | Issuing CA v -> 1..many | |---------------------------------------------------------| | Affiliate | | --------- | | | 1 | | Registration Authority v -> 1..many | |---------------------------------------------------------| | Web site operator | | ----------------- | | | 1 | | Certificate Holder v -> 1..many | --------------------------------------------------------- Moses Expires March 8, 2013 [Page 8] Internet-Draft Trust models of the Web PKI September 2012 Figure 7: RA affiliated to issuing CA The affiliate's behavior is governed by its contract with the issuing CA. The issuing CA commonly performs a subset of the checks normally performed by the registration authority, such as identifying unacceptable names. 3.6. The root CA is operated by a government In the case where the root CA is operated by a government department, the policy authority 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.7. The certificate user directly trusts an issuing CA Certificate user products may allow the user to designate a CA key as trusted, a priori, for the purpose of validating certificate-holder certificates. See Figure 8. --------------------------------------------------------- | Unaffiliated user | | ----------------- | | | | Certificate User | |---------------------------------------------------------| | Commercial CA | | ------------- | | | 1 | | Issuing CA v -> 1..many | | | | | 1 | | Registration Authority v -> 1..many | |---------------------------------------------------------| | Web-site operator | | ----------------- | | | 1 | | Certificate Holder v -> 1..many | --------------------------------------------------------- Figure 8: Certificate user directly trusts issuing CA Clearly, in this case, the user does not benefit from any of the assurances normally provided by the policy management authority or the root CA. Moses Expires March 8, 2013 [Page 9] Internet-Draft Trust models of the Web PKI September 2012 3.8. The certificate user directly trusts a certificate-holder certificate Certificate user products may allow the user to designate a certificate-holder key as trusted, a priori. See Figure 9. --------------------------------------------------------- | Unaffiliated user | | ----------------- | | | | Certificate User | |---------------------------------------------------------| | Web-site operator | | ----------------- | | | 1 | | Certificate Holder v -> 1..many | --------------------------------------------------------- Figure 9: Certificate user directly trusts certificate holder Clearly, in this case, the user does not benefit from any of the assurances normally provided by the policy management authority, the root CA, or the issuing CA. 3.9. Certificate holder operates issuing CA A certificate holder may operate its own issuing CA. Typically, the certificate holder is approved to issue certificates only within a specific region of the name-space, and this limitation is enforced by contract. See Figure 10. Moses Expires March 8, 2013 [Page 10] Internet-Draft Trust models of the Web PKI September 2012 | | |---------------------------------------------------------| | Commercial CA | | ------------- | | | 1 | | Root CA v -> 1..many | |---------------------------------------------------------| | Web-site operator | | ----------------- | | | 1 | | Issuing CA v -> 1..many | | | | | 1 | | Registration Authority v -> 1..many | | | | | 1 | | Certificate Holder v -> 1..many | --------------------------------------------------------- Figure 10: Certificate holder operates issuing CA The root CA may use the PKIX name constraints certificate extension to limit the region of name-space in which the issuing CA can issue valid certificates. 3.10. Certificate holder manages issuing CA A root CA may host an issuing CA on behalf of a certificate holder. Typically, the certificate holder 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 path indicates that the issuing CA was owned and operated by the certificate holder. See Figure 11. Moses Expires March 8, 2013 [Page 11] Internet-Draft Trust models of the Web PKI September 2012 | | |---------------------------------------------------------| | Commercial CA | | ------------- | | | 1 | | Root CA v -> 1..many | | --------------------------------------------------------- | | Web-site operator | | | ----------------- | | | | 1 | | | Issuing CA v -> 1..many | | | | | | | 1 | | | Registration Authority v -> 1..many | --| | | | 1 | | Certificate Holder v -> 1..many | --------------------------------------------------------- Figure 11: Certificate holder manages issuing CA 3.11. Certificate holder manages RA An issuing CA may host a registration authority on behalf of a certificate holder. Typically, the certificate holder is approved to issue certificates only within a specific region of the name-space, and this limitation is enforced by the host issuing CA. Examination of the certificate path indicates that the registration authority was owned and operated by the issuing CA. See Figure 12. | | | | 1 | | Issuing CA v -> 1..many | | --------------------------------------------------------- | | Web-site operator | | | ----------------- | | | | 1 | | | Registration Authority v -> 1..many | --| | | | 1 | | Certificate Holder v -> 1..many | --------------------------------------------------------- Figure 12: Certificate holder manages RA Moses Expires March 8, 2013 [Page 12] Internet-Draft Trust models of the Web PKI September 2012 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 certificate holders. The second concerns controllability and observability of issued certificates. Certificate holder 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) With the exception of non-unique names, CAs in the Web PKI are required to screen out requests for certificates with 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-user 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 clearly has 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 Moses Expires March 8, 2013 [Page 13] Internet-Draft Trust models of the Web PKI September 2012 Requirement Levels", BCP 14, RFC 2119, March 1997. Author's Address Tim Moses (editor) Entrust Ltd. Phone: +1 613 270 3183 Email: tim.moses@entrust.com Moses Expires March 8, 2013 [Page 14]