Internet DRAFT - draft-barreira-trustmodel
draft-barreira-trustmodel
Internet Engineering Task Force I. Barreira, Ed.
Internet-Draft Izenpe
Intended status: Best Current Practice B. Morton, Ed.
Expires: April 12, 2014 Entrust
October 09, 2013
Trust models of the Web PKI
draft-barreira-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.
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 12, 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 12, 2014 [Page 1]
Internet-Draft Trust models of the Web PKI October 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
1.2. 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 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. Normative 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.
1.1. Requirements Language
Barreira & Morton Expires April 12, 2014 [Page 2]
Internet-Draft Trust models of the Web PKI October 2013
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
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 self-signed certificate and whose public key
is included as a trust anchor in a root store.
Root certificate - a typically self-signed certificate that
identifies the root CA.
Root store - a set of root certificates which can be trusted by a
browser.
Root store policy - the policy provided by the root store
provider.
Subscriber - per RFC 3647.
Subscriber agreement - per RFC 3647.
2. Trust model
In the Web PKI trust model, a browser uses a root store that contains
one or more root CA public keys. The root CAs are under the control
of a CA entity and managed in conformance with the root store
governance policy accepted by the browser 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 governance policy to be met by the root CA in order to be
included in the root store. The root store provider stores and
manages root certificates in its operating system or browser to
support certificate chain validation. The root store provider sets
requirements for how trustworthiness will be established and provides
a trust indication through its browser.
The root store provider will verify root CAs through different means
which may include legal agreements, security reports, audit reports
or acceptance by another root store provider.
Barreira & Morton Expires April 12, 2014 [Page 3]
Internet-Draft Trust models of the Web PKI October 2013
The 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 prescribed by the root store policy. The
audit is based on an accepted schema of the standards (e.g., WebTrust
or ETSI). The third party auditor generates an audit report which is
provided to the root store provider. If the audit report states the
CA was not in compliance with the standards, then the 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 anchored to the root CA.
2.2. CA Infrastructure
The CA infrastructure consists of a PKI hierarchy. The CA entity
issues 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
The CA entity operates a registration authority which 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 in accordance with the certificate policy. The location
of the CRL or the OCSP response is provided as a URL posted in one of
the fields in the issued certificate.
2.3. Subscriber
The subscriber provides services through the browsers to relying
parties. The subscriber identifies the location of its service using
a domain name contained in a certificate.
Barreira & Morton Expires April 12, 2014 [Page 4]
Internet-Draft Trust models of the Web PKI October 2013
The subscriber submits certificate requests in accordance with the CA
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 and other
applicable requirements.
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 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, 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
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.
Barreira & Morton Expires April 12, 2014 [Page 5]
Internet-Draft Trust models of the Web PKI October 2013
Unlike the situation in section 3.2.1, the subordinate issuing CA is
not recognized independently by any relationship with the root store
provider.
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.
The third party registration authority is not identified in a CA
certificate as an issuing CA.
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 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
Barreira & Morton Expires April 12, 2014 [Page 6]
Internet-Draft Trust models of the Web PKI October 2013
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.
This is often referred to an enterprise-based registration authority
relationship with the issuing CA.
3.2.8. Subscriber certificate issued by root CA
Some legacy situations demand that the certificate be issued directly
by the root CA, without the involvement of intermediate issuing CAs.
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 on the subscriber's behalf.
3.4. Browser
3.4.1. Browser directly trusts issuing CA key
The browser may allow the relying party to designate a CA key as
trusted, a priori, for the purpose of evaluating subscriber
certificates.
3.4.2. Browser directly trusts subscriber entity key
The browser may allow the relying party to designate a subscriber's
certificate as trusted, a priori.
3.4.3. Browser supports public key pinning
Browser limits the public keys to verify a domain name. Limitation
can be done by including authenticated public keys in the browser or
by respecting a header provided by the subscriber.
4. IANA Considerations
This memo includes no request to IANA.
5. Security Considerations
Barreira & Morton Expires April 12, 2014 [Page 7]
Internet-Draft Trust models of the Web PKI October 2013
The trust models described here exhibit several vulnerabilities that
could adversely affect the reliability of the authentication they
provide.
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 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 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 otherwise-valid certificate that chain
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.
Barreira & Morton Expires April 12, 2014 [Page 8]
Internet-Draft Trust models of the Web PKI October 2013
Every root store provider indicates in their policies how to vet CAs
in case of a failure or a security breach.
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.
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", RFC 6797, November 2012.
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
Email: bruce.morton@entrust.com
Barreira & Morton Expires April 12, 2014 [Page 9]
