draft-ietf-wpkops-trustmodel-02.txt   draft-ietf-wpkops-trustmodel-03.txt 
Internet Engineering Task Force I. Barreira, Ed. Internet Engineering Task Force I. Barreira, Ed.
Internet-Draft Izenpe Internet-Draft Izenpe
Intended status: Best Current Practice B. Morton, Ed. Intended status: Best Current Practice B. Morton, Ed.
Expires: November 30, 2014 Entrust Expires: January 23, 2015 Entrust
May 29, 2014 July 22, 2014
Trust models of the Web PKI Trust models of the Web PKI
draft-ietf-wpkops-trustmodel-02 draft-ietf-wpkops-trustmodel-03
Abstract Abstract
This is one of a set of documents to define the operation of the Web This is one of a set of documents to define the operation of the Web
PKI. It describes the currently deployed Web PKI trust. PKI. It describes the currently deployed Web PKI trust.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 30, 2014. This Internet-Draft will expire on January 23, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
2. Trust model . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Trust model . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Root store provider . . . . . . . . . . . . . . . . . . . 4 2.1. Root store provider . . . . . . . . . . . . . . . . . . . 4
2.2. CA Infrastructure . . . . . . . . . . . . . . . . . . . . 4 2.2. CA Infrastructure . . . . . . . . . . . . . . . . . . . . 4
2.2.1. Registration Authority . . . . . . . . . . . . . . . 5 2.2.1. Registration Authority . . . . . . . . . . . . . . . 5
2.2.2. Certificate status . . . . . . . . . . . . . . . . . 5 2.2.2. Certificate status . . . . . . . . . . . . . . . . . 5
2.3. Subscriber . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Subscriber . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Browser . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Browser . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Trust Model variants . . . . . . . . . . . . . . . . . . . . 5 3. Trust Model variants . . . . . . . . . . . . . . . . . . . . 5
3.1. Root store provider variations . . . . . . . . . . . . . 5 3.1. Root store provider variations . . . . . . . . . . . . . 6
3.1.1. Browser adopts root store . . . . . . . . . . . . . . 5 3.1.1. Browser adopts root store . . . . . . . . . . . . . . 6
3.2. CA Infrastructure variations . . . . . . . . . . . . . . 6 3.2. CA Infrastructure variations . . . . . . . . . . . . . . 6
3.2.1. One root CA cross-certifies another root CA . . . . . 6 3.2.1. One root CA cross-certifies another root CA . . . . . 6
3.2.2. Issuing CA is a third party to the root CA . . . . . 6 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 3.2.3. Registration authority is a third party to the
issuing CA . . . . . . . . . . . . . . . . . . . . . 6 issuing CA . . . . . . . . . . . . . . . . . . . . . 7
3.2.4. Root CA is operated by the government . . . . . . . . 7 3.2.4. Root CA is operated by the government . . . . . . . . 7
3.2.5. Subscriber operates issuing CA . . . . . . . . . . . 7 3.2.5. Subscriber operates issuing CA . . . . . . . . . . . 7
3.2.6. Subscriber sources management of issuing CA . . . . . 7 3.2.6. Subscriber sources management of issuing CA . . . . . 7
3.2.7. Subscriber manages registration authority . . . . . . 7 3.2.7. Subscriber manages registration authority . . . . . . 7
3.2.8. Subscriber certificate issued by a root CA . . . . . 7 3.2.8. Subscriber certificate issued by a root CA . . . . . 8
3.3. Subscriber . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Subscriber . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1. Subscriber uses agent . . . . . . . . . . . . . . . . 8 3.3.1. Subscriber uses agent . . . . . . . . . . . . . . . . 8
3.4. Browser . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Browser . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4.1. Browser directly trusts issuing CA key . . . . . . . 8 3.4.1. Browser directly trusts issuing CA key . . . . . . . 8
3.4.2. Browser directly trusts subscriber entity key . . . . 8 3.4.2. Browser directly trusts subscriber entity key . . . . 8
3.4.3. Browser makes root CA public key unusable . . . . . . 8 3.4.3. Browser makes root CA public key unusable . . . . . . 8
3.4.4. Browser supports public key pinning . . . . . . . . . 8 3.4.4. Browser supports public key pinning . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5.1. HTTPS is optional . . . . . . . . . . . . . . . . . . . . 9 5.1. HTTPS is optional . . . . . . . . . . . . . . . . . . . . 9
5.2. Naming of subscribers . . . . . . . . . . . . . . . . . . 9 5.2. automatic update of root certificates . . . . . . . . . . 9
5.3. Root CA compromise . . . . . . . . . . . . . . . . . . . 9 5.3. Naming of subscribers . . . . . . . . . . . . . . . . . . 9
5.4. Root CA compromise . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. IETF Normative References . . . . . . . . . . . . . . . . 10 6.1. IETF Normative References . . . . . . . . . . . . . . . . 10
6.2. IETF Informative References . . . . . . . . . . . . . . . 10 6.2. IETF Informative References . . . . . . . . . . . . . . . 10
Appendix A. Other references . . . . . . . . . . . . . . . . . . 10 Appendix A. Other references . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
This document defines the Web PKI trust model as it is currently This document defines the Web PKI trust model as it is currently
implemented. The trust model is to support communications between implemented. The trust model is to support communications between
the subscriber and the browser. This document does not address the subscriber and the browser. It refers also to the current
future changes to the implemented trust model. processing behaviours of cryptolibraries with the browsers they
support, related to the communication between the server and the
browser as indicated in the "Browser processing of server
certificates" document. This document does not address future
changes to the implemented trust model.
1.1. Requirements Language 1.1. Requirements Language
The key words "REQUIRED", "MUST", "MUST NOT" and "MAY" in this The key words "REQUIRED", "MUST", "MUST NOT" and "MAY" in this
document are to be interpreted as described in RFC 2119 [RFC2119] document are to be interpreted as described in RFC 2119 [RFC2119]
1.2. Definitions 1.2. Definitions
The use of PKI terminology is used as defined in RFC 5280 [RFC5280]. The use of PKI terminology is used as defined in RFC 5280 [RFC5280].
Additional definitions are provided below for interpretation of this Additional definitions are provided below for interpretation of this
skipping to change at page 3, line 27 skipping to change at page 3, line 36
Certificate policy - per RFC 3647. [RFC3647] Certificate policy - per RFC 3647. [RFC3647]
Intermediate CA - is a non-root CA which issues certificates to Intermediate CA - is a non-root CA which issues certificates to
issuing CAs. issuing CAs.
Issuing CA - in relation to a particular subscriber certificate, Issuing CA - in relation to a particular subscriber certificate,
the CA that issued the certificate. the CA that issued the certificate.
Root CA - a CA with a self signed certificate and whose public key Root CA - a CA with a self signed certificate and whose public key
is included as a trust anchor in a root store. is included as a trust anchor in a root certificates store.
Root certificate - typically a self-signed certificate that Root certificate - typically a self-signed certificate that
identifies the root CA. The root certificate is a type of trust identifies the root CA. The root certificate is a type of trust
anchor. anchor.
Root store - a set of root certificates which can be trusted by a Root certificates store - a set of root certificates which can be
browser. trusted by the operating system and/or a browser. Within the
context of the present document the more general term Root Store
is used in preference.
Root store policy - the governance policy provided by the root Root store policy - the governance policy provided by the root
store provider. store provider.
Subscriber - per RFC 3647. [RFC3647] Subscriber - per RFC 3647. [RFC3647]
Subscriber agreement - per RFC 3647. [RFC3647] Subscriber agreement - per RFC 3647. [RFC3647]
Trust Anchor - per RFC 5914. [RFC5914] Trust Anchor - per RFC 5914. [RFC5914]
2. Trust model 2. Trust model
This section describes the basic Web PKI trust model. Variants to This section describes the basic Web PKI trust model. Variants to
the trust model are discussed in section 3. the trust model are discussed in section 3.
In the Web PKI trust model, a browser uses a root store that contains 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 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. store has been installed on an evaluation made by the browser vendor.
skipping to change at page 6, line 6 skipping to change at page 6, line 14
3.1. Root store provider variations 3.1. Root store provider variations
3.1.1. Browser adopts root store 3.1.1. Browser adopts root store
The browser does not use its own root store, but uses the root store The browser does not use its own root store, but uses the root store
managed by a separate root store provider. For example, the Google managed by a separate root store provider. For example, the Google
Chrome browser operated on Windows uses the Windows root store. Chrome browser operated on Windows uses the Windows root store.
The browser will provide its own trust and security indications. The The browser will provide its own trust and security indications. The
browser may determine whether it will provide extended validation browser may determine whether it will provide additional validation
indications. The browser may also provide its own services to verify indications. The browser may also provide its own services to verify
the status of the certificates. the status of the certificates.
3.2. CA Infrastructure variations 3.2. CA Infrastructure variations
3.2.1. One root CA cross-certifies another root CA 3.2.1. One root CA cross-certifies another root CA
Some browsers in active use do not possess the capability to be Some browsers in active use do not possess the capability to be
updated with new root certificates in the field. Consequently, these updated with new root certificates in the field. Consequently, these
browsers do not accept new root certificates issued by CAs that came browsers do not accept new root certificates issued by CAs that came
into existence after they were first deployed. The new root into existence after they were first deployed. The new root
certificates are accepted by newer browsers and other browsers that certificates are accepted by newer browsers and other browsers that
can be updated in the field. As such newer CAs operate at a can be updated in the field. As such newer CAs operate at a
disadvantage to older CAs. disadvantage to older CAs.
The disadvantage can be addressed by having trust extended to the new The disadvantage can be addressed by having trust extended to the new
root certificate, by having the public key of the new root root certificate (that can belong to the older CA or be another CA),
certificate cross-signed by an older root CA which is already by having the public key of the new root certificate cross-signed by
accepted in the older browsers. As the cross-certified root CA is an older root CA which is already accepted in the older browsers. As
also recognized directly by the root store provider, it operates in the cross-certified root CA is also recognized directly by the root
accordance with the requirements of that certificate policy to which store provider, it operates in accordance with the requirements of
the root CA conforms. In addition, the cross-certified CA complies that certificate policy to which the root CA conforms. In addition,
to any requirements placed upon it by the contract between it and the the cross-certified CA complies to any requirements placed upon it by
cross-certifying root CA. the contract between it and the cross-certifying root CA.
This contract should indicate also the adherence to the root store
policy.
The [BR-certs] may be used as guidance for clarification.
3.2.2. Issuing CA is a third party to the 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 An issuing CA may operate as a third party subordinate to the root
CA. The issuing CA's behaviour is governed by its contract with the CA. The issuing CA's behaviour is governed by its contract with the
root CA, which commonly stipulates adherence to the root store root CA, which commonly stipulates adherence to the root store
policy. Unlike the situation in section 3.2.1, the subordinate policy. Unlike the situation in section 3.2.1, the subordinate
issuing CA is not recognized independently by any relationship with issuing CA is not recognized independently by any relationship with
the root store provider. the root store provider.
skipping to change at page 7, line 15 skipping to change at page 7, line 23
3.2.4. Root CA is operated by the government 3.2.4. Root CA is operated by the government
In the case where a root CA is operated by a government department, a 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 root store provider may rely upon an audit conducted in accordance
with the government's own internal audit process. with the government's own internal audit process.
3.2.5. Subscriber operates issuing CA 3.2.5. Subscriber operates issuing CA
A subscriber may operate its own issuing CA. Typically, the A subscriber may operate its own issuing CA. Typically, the
subscriber is approved to issue certificates only within a specific subscriber is approved to issue certificates only within a specific
region of the name-space, and this limitation is enforced by region of the name-space, and this limitation is enforced by legal
contract. The root CA may use the name constraints certificate means or it can be also technically constrained. For example, the
extension to limit the region of the name-space in which the issuing root CA may use the name constraints certificate extension to limit
CA can issue valid certificates. 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 This is often referred to as an enterprise-based subordinate CA
relationship. relationship.
3.2.6. Subscriber sources management of issuing CA 3.2.6. Subscriber sources management of issuing CA
A root CA may host an issuing CA on behalf of a subscriber. A root CA may host an issuing CA on behalf of a subscriber.
Typically, the subscriber is approved to issue certificates only Typically, the subscriber is approved to issue certificates only
within a specific region of the name-space, and this limitation is within a specific region of the name-space, and this limitation is
enforced by the host root CA. Examination of the certificate chain enforced by the host root CA either technically or by legal means.
would indicate that the issuing CA was owned by the subscriber by Examination of the certificate chain would indicate that the issuing
viewing the organization name in the subject field. CA was owned by the subscriber by viewing the organization name in
the subject field.
This may also be an enterprise-based CA relationship; however, the This may also be an enterprise-based CA relationship; however, the
entity operating the CA (rather than the enterprise subscriber) has entity operating the CA (rather than the enterprise subscriber) has
immediate control of the CA and physical possession of the CA private immediate control of the CA and physical possession of the CA private
key. key.
3.2.7. Subscriber manages registration authority 3.2.7. Subscriber manages registration authority
A subscriber may manage a registration authority. The subscriber is A subscriber may manage a registration authority. The subscriber is
approved to issue certificates only within a specific region of the approved to issue certificates only within a specific region of the
skipping to change at page 9, line 15 skipping to change at page 9, line 25
5.1. HTTPS is optional 5.1. HTTPS is optional
The subscriber does not have to support HTTPS for the web site. The 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. 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 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 of no HTTPS, the browser could more easily be attacked. This attack
can be mitigated by supporting HSTS in accordance with RFC 6797 can be mitigated by supporting HSTS in accordance with RFC 6797
[RFC6797]. HSTS allows the subscriber to declare to the browser that [RFC6797]. HSTS allows the subscriber to declare to the browser that
interactions shall only be done using HTTPS connections. interactions shall only be done using HTTPS connections.
5.2. Naming of subscribers 5.2. automatic update of root certificates
The end user may remove or add some or all root certificates provided
in a root store provider and then when an automatic update takes
place it may be reinstated the removed ones and remove the added ones
causing a posible denial of service and introducing some
vulnerabilities.
5.3. Naming of subscribers
Subscriber names with any of the following characteristics can be Subscriber names with any of the following characteristics can be
used in an impersonation attack. used in an impersonation attack.
o homographic name o homographic name
o mixed-alphabet name o mixed-alphabet name
o name that contains a string termination character o name that contains a string termination character
skipping to change at page 9, line 40 skipping to change at page 10, line 9
characteristics. CAs are required to phase out the practice of characteristics. CAs are required to phase out the practice of
issuing non-unique names by 2015 per [BR-certs]. issuing non-unique names by 2015 per [BR-certs].
Technically, unless constrained by an upstream CA to issue Technically, unless constrained by an upstream CA to issue
certificates only in a specific region of the name-space, any CA in certificates only in a specific region of the name-space, any CA in
the Web PKI can issue an apparently legitimate certificate for any the Web PKI can issue an apparently legitimate certificate for any
name, whether or not the legitimate holder of that name is aware of name, whether or not the legitimate holder of that name is aware of
or approves the issuance. Furthermore, the legitimate holder of that or approves the issuance. Furthermore, the legitimate holder of that
name may not discover that such a certificate has been issued. name may not discover that such a certificate has been issued.
5.3. Root CA compromise 5.4. Root CA compromise
In the event of a detected compromise of a root CA, its key is In the event of a detected compromise of a root CA, its key is
blacklisted by means of a software update. This has the effect of blacklisted by means of a software update. This has the effect of
invalidating every certificate that is subordinate to that root CA, invalidating every certificate that is subordinate to that root CA,
whether or not the certificate was issued while the compromise whether or not the certificate was issued while the compromise
existed. This step would have a severe impact upon the CA and its 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 subscribers; this is a step not likely to be taken without being very
careful. careful.
6. References 6. References
6.1. IETF Normative References 6.1. IETF Normative References
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
skipping to change at page 10, line 36 skipping to change at page 10, line 50
Wu, "Internet X.509 Public Key Infrastructure Certificate Wu, "Internet X.509 Public Key Infrastructure Certificate
Policy and Certification Practices Framework", RFC 3647, Policy and Certification Practices Framework", RFC 3647,
November 2003. November 2003.
Appendix A. Other references Appendix A. Other references
[BR-certs] - CA/Browser Forum, Baseline Requirements for the [BR-certs] - CA/Browser Forum, Baseline Requirements for the
Issuance and Management of Publicly-Trusted Certificates. Issuance and Management of Publicly-Trusted Certificates.
https://cabforum.org/baseline-requirements-documents/ https://cabforum.org/baseline-requirements-documents/
[Mozilla-CP] - Mozilla CA Certificate Policy. https://www.mozilla [Mozilla-CP] - Mozilla CA Certificate Policy.
.org/projects/security/certs/policy/ https://www.mozilla.org/projects/security/certs/policy/
Authors' Addresses Authors' Addresses
Inigo Barreira (editor) Inigo Barreira (editor)
Izenpe Izenpe
Beato Tomas de Zumarraga 71, 1. 01008 Vitoria-Gasteiz. Spain Beato Tomas de Zumarraga 71, 1. 01008 Vitoria-Gasteiz. Spain
Phone: +34 945067705
Email: i-barreira@izenpe.net Email: i-barreira@izenpe.net
Bruce Morton (editor) Bruce Morton (editor)
Entrust Entrust
1000 Innovation Drive. Ottawa, Ontario. Canada K2K 3E7 1000 Innovation Drive. Ottawa, Ontario. Canada K2K 3E7
Email: bruce.morton@entrust.com Email: bruce.morton@entrust.com
 End of changes. 25 change blocks. 
43 lines changed or deleted 64 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/