Internet DRAFT - draft-webpki-trustmodel
draft-webpki-trustmodel
Internet Engineering Task Force I. Barreira, Ed.
Internet-Draft Izenpe
Intended status: Best Current Practice B. Morton, Ed.
Expires: December 07, 2013 Entrust
June 05, 2013
Trust models of the Web PKI
draft-webpki-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 07, 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 07, 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 . . . . . . . . . . . . . . . . . . . . . . . 3
2. Trust model . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Root store provider . . . . . . . . . . . . . . . . . . . 3
2.2. CA Infrastructure . . . . . . . . . . . . . . . . . . . . 3
2.2.1. CA . . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . 5
3.2.3. Registration authority is a third party to the
issuing CA . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.1. Subscriber uses agent . . . . . . . . . . . . . . . . 6
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 "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]
Barreira & Morton Expires December 07, 2013 [Page 2]
Internet-Draft Trust models of the Web PKI June 2013
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 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.
Subscriber - a subject of a certificate who is issued a
certificate.
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, each of which is under the control of a CA
and managed in conformance with the certificate 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. The following graphic shows the
relationship of the parties in the trust model.
2.1. Root store provider
The root store provider (e.g. Microsoft or Mozilla) determines a
certificate policy. The root store provider stores and manages root
certificates in its certificate-using client to support the trust
model. The root store provider determines how trust will be
validated and provides a trust indication through its certificate-
using client to the relying parties.
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
Barreira & Morton Expires December 07, 2013 [Page 3]
Internet-Draft Trust models of the Web PKI June 2013
certificate is called a root certificate of a root CA. The root CAs
issue 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 in
accordance with the certificate policy. The CA entity operates the
certificate issuance and management system in accordance with the
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 audit as prescribed by the certificate 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 certificate policy.
2.4. Relying party
The relying party uses a certificate-using client in communication
with a subscriber. The relying party implicitly accepts the
certificate policy by choosing to use a particular certificate-using
client.
3. Trust Model variants
This section defines variants to the roles of the parties as defined
in section 2
Barreira & Morton Expires December 07, 2013 [Page 4]
Internet-Draft Trust models of the Web PKI June 2013
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. 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.
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 certificate policy of the
root store provider.
3.2.3. Registration authority is a third party to the issuing CA
Barreira & Morton Expires December 07, 2013 [Page 5]
Internet-Draft Trust models of the Web PKI June 2013
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 certificate policy of the root store provider.
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
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
Barreira & Morton Expires December 07, 2013 [Page 6]
Internet-Draft Trust models of the Web PKI June 2013
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 certificate policy.
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)
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
Barreira & Morton Expires December 07, 2013 [Page 7]
Internet-Draft Trust models of the Web PKI June 2013
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.
[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
Bruce Morton (editor)
Entrust
1000 Innovation Drive. Ottawa, Ontario. Canada K2K 3E7
Email: bruce.morton@entrust.com
Barreira & Morton Expires December 07, 2013 [Page 8]
