Internet DRAFT - draft-barreira-wpkops-trustmodel

draft-barreira-wpkops-trustmodel







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]