[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 RFC 5217

Network Working Group                                   M. Shimaoka, Ed.
Internet-Draft                                                     SECOM
Expires: June 5, 2008                                        N. Hastings
                                                                    NIST
                                                              R. Nielsen
                                                     Booz Allen Hamilton
                                                        December 3, 2007


 Memorandum for multi-domain Public Key Infrastructure Interoperability
                   draft-shimaoka-multidomain-pki-11

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on June 5, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).











Shimaoka, et al.          Expires June 5, 2008                  [Page 1]

Internet-Draft      multi-domain PKI interoperability      December 2007


Abstract

   The objective of this document is to establish a standard terminology
   for interoperability of multi-domain Public Key Infrastructure (PKI),
   where each PKI Domain is operated under a distinct policy.  This
   document describes the relationships between Certification
   Authorities (CAs), provides the definition and requirements for PKI
   Domains, and discusses typical models of multi-domain PKI.











































Shimaoka, et al.          Expires June 5, 2008                  [Page 2]

Internet-Draft      multi-domain PKI interoperability      December 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Objective  . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Document Outline . . . . . . . . . . . . . . . . . . . . .  4
     1.3.  Requirements Terminology . . . . . . . . . . . . . . . . .  4
   2.  Public Key Infrastructure (PKI) Basics . . . . . . . . . . . .  5
     2.1.  Basic Terms  . . . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  Relationships Between Certification Authorities  . . . . .  6
       2.2.1.  Hierarchical CA Relationships  . . . . . . . . . . . .  6
       2.2.2.  Peer-to-peer CA Relationships  . . . . . . . . . . . .  7
     2.3.  Public Key Infrastructure (PKI) Architectures  . . . . . .  8
       2.3.1.  Single CA Architecture . . . . . . . . . . . . . . . .  9
       2.3.2.  Multiple CA Architectures  . . . . . . . . . . . . . .  9
     2.4.  Relationships between PKIs and Relying Parties . . . . . . 13
   3.  PKI Domain . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     3.1.  PKI Domain Properties  . . . . . . . . . . . . . . . . . . 14
     3.2.  Requirements for Establishing and Participating in PKI
           Domains  . . . . . . . . . . . . . . . . . . . . . . . . . 15
       3.2.1.  PKI Requirements . . . . . . . . . . . . . . . . . . . 15
       3.2.2.  PKI Domain Documentation . . . . . . . . . . . . . . . 15
       3.2.3.  PKI Domain Membership Notification . . . . . . . . . . 16
       3.2.4.  Considerations for PKIs and PKI Domains with
               Multiple Policies  . . . . . . . . . . . . . . . . . . 17
     3.3.  PKI Domain Models  . . . . . . . . . . . . . . . . . . . . 18
       3.3.1.  Unifying Trust Point (Unifying Domain) Model . . . . . 18
       3.3.2.  Independent Trust Point Models . . . . . . . . . . . . 19
     3.4.  Operational Considerations . . . . . . . . . . . . . . . . 23
   4.  Trust Models External to PKI Relationships . . . . . . . . . . 24
     4.1.  Trust List Models  . . . . . . . . . . . . . . . . . . . . 24
       4.1.1.  Local Trust List Model . . . . . . . . . . . . . . . . 24
       4.1.2.  Trust Authority Model  . . . . . . . . . . . . . . . . 25
     4.2.  Trust List Considerations  . . . . . . . . . . . . . . . . 26
       4.2.1.  Considerations for a PKI . . . . . . . . . . . . . . . 26
       4.2.2.  Considerations for Relying Parties and Trust
               Authorities  . . . . . . . . . . . . . . . . . . . . . 26
       4.2.3.  Additional Considerations for Trust Authorities  . . . 27
   5.  Abbreviations  . . . . . . . . . . . . . . . . . . . . . . . . 28
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 29
     6.1.  PKI Domain Models  . . . . . . . . . . . . . . . . . . . . 29
     6.2.  Trust List Models  . . . . . . . . . . . . . . . . . . . . 29
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 31
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 32
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 32
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
   Intellectual Property and Copyright Statements . . . . . . . . . . 35




Shimaoka, et al.          Expires June 5, 2008                  [Page 3]

Internet-Draft      multi-domain PKI interoperability      December 2007


1.  Introduction

1.1.  Objective

   The objective of this document is to establish a standard terminology
   that can be used by different Public Key Infrastructure (PKI)
   authorities who are considering establishing trust relationships with
   each other.  The document defines different types of possible trust
   relationships, identifies design and implementation considerations
   that PKIs should implement to facilitate trust relationships across
   PKIs, and identifies issues that should be considered when
   implementing trust relationships.

1.2.  Document Outline

   Section 2 introduces the PKI basics which are necessary before
   talking about multi-domain PKI.  Section 3 describes the definitions
   and requirements of 'PKI domain', and also describes the typical
   models of multi-domain PKI.  Section 4 considers the Trust List
   models depending on relying party-CA relationships, not CA-CA trust
   relationships, although it is not focus of this document.  Section 5
   identifies abbreviations used in the document.

1.3.  Requirements Terminology

   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 [2].























Shimaoka, et al.          Expires June 5, 2008                  [Page 4]

Internet-Draft      multi-domain PKI interoperability      December 2007


2.  Public Key Infrastructure (PKI) Basics

2.1.  Basic Terms

   The following terms are used throughout this document.  Where
   possible, definitions found in RFC 4949 [5] have been used.

   Certificate:  A digitally-signed data structure that attests to the
      binding of a system entity's identity to a public key value.
      (based on definition of public-key certificate in RFC 4949 [5])

   Certificate Policy:  A named set of rules that indicates the
      applicability of a certificate to a particular community and/or
      class of application with common security requirements.  (X.509
      [3]) Note that to avoid confusion, this document uses the
      terminology "Certificate Policy Document" to refer to the document
      that defines the rules, and "Policy Object Identifier" to specify
      a particular rule set.

   Certificate Policy Document:  A document that defines the rules for
      the issuance and management of certificates and identifies Policy
      OID(s) for these rules.  A Certificate Policy Document may define
      more than one Policy OID.

   Policy Object Identifier (Policy OID):  An identifier applied to a
      set of rules governing the issuance and management of
      certificates.  Policy OIDs are defined in Certificate Policy
      Documents.

   Certification Authority (CA):  An entity that issues certificates
      (especially X.509 certificates) and vouches for the binding
      between the data items in a certificate.  (RFC 4949 [5])

   End Entity (EE):  A system entity that is the subject of a
      certificate and that is using, or is permitted and able to use,
      the matching private key only for a purpose or purposes other than
      signing a certificate; i.e., an entity that is not a CA.  (RFC
      4949 [5])

   Relying Party:  A system entity that depends on the validity of
      information (such as another entity's public key value) provided
      by a certificate. (from RFC 4949 [5] definition of certificate
      user)

   Trust Anchor:  A CA that is the subject of a trust anchor certificate
      that is used to provide the first public key in a certification
      path. [modified from RFC 4949 [5] definition of "trust anchor CA"
      and "trust anchor certificate"]



Shimaoka, et al.          Expires June 5, 2008                  [Page 5]

Internet-Draft      multi-domain PKI interoperability      December 2007


2.2.  Relationships Between Certification Authorities

   CAs establish trust relationships by issuing certificates to other
   CAs.  CA relationships are divided into 'certification hierarchy' [5]
   and 'cross-certification' [5].

   In a certification hierarchy, there are two type of CAs, superior CA
   and 'subordinate CA' [5].  A CA which issued a public-key certificate
   to another (subordinate) CA.

   Superior CA:  A CA which is a issuer of a subordinate CA certificate.

   A cross-certification can be either unilateral or bilateral.

   Unilateral cross-certification:  Cross-certification of one CA (CA1)
      by another CA (CA2) but no cross-certification of CA2 by CA1.

   Bilateral cross-certification:  Cross-certification of one CA (CA1)
      by another CA (CA2) and cross-certification of CA2 by CA1.

2.2.1.  Hierarchical CA Relationships

   In a hierarchical relationship, as shown in Figure 1, one CA assumes
   a parent relationship to the other CA.

                                   +----+
                                   | CA |
                                   +----+
                                     |
                                     v
                                   +----+
                                   | CA |
                                   +----+

                  Figure 1: Hierarchical CA Relationship

   There are two types of hierarchical relationships, depending on
   whether a subordinate CA certificate or a unilateral cross-
   certificate is used.  In the case where one (superior) CA issues a
   subordinate CA certificate to another, the CA at the top of the
   hierarchy, which must itself have a self-signed certificate, is
   called a Root CA.  In the case where one CA issues unilateral cross-
   certificates to other CAs, the CA issuing unilateral cross-
   certificates is called a Unifying CA.  Unifying CAs only use
   unilateral cross-certificates.

   NOTE: In this document, the definition of Root CA is according to
   second definition (context for hierarchical PKI) of 'root CA' in RFC



Shimaoka, et al.          Expires June 5, 2008                  [Page 6]

Internet-Draft      multi-domain PKI interoperability      December 2007


   4949 [5].  First definition (context for PKI) is specifically used to
   'Trust Anchor' in this document.

   Root CA:  A CA that is at the top of a hierarchy, and itself SHOULD
      not issue certificates to end entities (except those required for
      its own operation) but issues subordinate CA certificates to one
      or more CAs.

   Subordinate CA:  A CA whose public-key certificate is issued by
      another superior CA, and itself MUST NOT be used as a Trust
      Anchor.

   Unifying CA:  A CA that is at the top of a hierarchy, and itself
      SHOULD not issue certificates to end entities (except those
      required for its own operation) but establishes unilateral cross-
      certification with other CAs.  A Unifying CA MUST permit CAs to
      which it issues cross-certificates to have self-signed
      certificates.

2.2.2.  Peer-to-peer CA Relationships

   In a peer relationship, no parent child relationship is created.  To
   establish peer relationships, only cross-certificates are used.  Peer
   relationships can be either unilateral or bilateral, as shown in
   Figure 2.

                                              Bilateral
                    Unilateral           Cross-Certification
                Cross-Certification      +----+      +----+
                +----+      +----+       |    | ---> |    |
                | CA | ---> | CA |       | CA |      | CA |
                +----+      +----+       |    | <--- |    |
                                         +----+      +----+

                  Figure 2: Peer-to-peer CA Relationships

   In the case where a CA exists only to manage cross-certificates, that
   CA is called a Bridge CA.  CAs can establish unilateral or bilateral
   cross-certification with a Bridge CA, as shown in Figure 3.

   Bridge CA:  A CA that itself does not issue certificates to end
      entities (except those required for its own operation) but
      establishes unilateral or bilateral cross-certification with other
      CAs.







Shimaoka, et al.          Expires June 5, 2008                  [Page 7]

Internet-Draft      multi-domain PKI interoperability      December 2007


                                  Bilateral
                             Cross-Certification
                  +----+ ----------+    +--------- +----+
                  | CA |           |    |          | CA |
                  +----+ <-------+ |    | +------> +----+
                                 | v    v |
                               +-----------+
                               | Bridge CA |
                               +-----------+
                  +----+         |       |         +----+
                  | CA | <-------+       +-------> | CA |
                  +----+         Unilateral        +----+
                            Cross-Certification

                            Figure 3: Bridge CA

2.3.  Public Key Infrastructure (PKI) Architectures

   A system of CAs that perform some set of certificate management,
   archive management, key management, and token management functions
   for a community of users in an application of asymmetric cryptography
   and share trust relationships, operate under a single Certificate
   Policy Document which defines a shared set of Policy OIDs, and are
   either operated by a single organization or under the direction of a
   single organization.

   Public Key Infrastructure (PKI):  A system of CAs that perform some
      set of certificate management, archive management, key management,
      and token management functions for a community of users in an
      application of asymmetric cryptography and share trust
      relationships, operate under the same Certificate Policy Document
      specifying a shared set of policy OID(s), and are either operated
      by a single organization or under the direction of a single
      organization.

   In addition, a PKI that intends to enter into trust relationships
   with other PKIs MUST designate a Principal CA that will manage all
   trust relationships.  This Principal CA SHOULD also be the trust
   anchor for relying parties of that PKI.

   Principal CA (PCA):  A CA which SHOULD have a self-signed
      certificate, is designated as the CA that will issue cross-
      certificates to Principal CAs in other PKIs, and MAY be the
      subject of cross-certificates issued by Principal CAs in other
      PKIs.

   In discussing different possible architectures for PKI, the concept
   of a certification path is necessary.  A certification path is built



Shimaoka, et al.          Expires June 5, 2008                  [Page 8]

Internet-Draft      multi-domain PKI interoperability      December 2007


   based on trust relationships between CAs.

   Certification Path:  An ordered sequence of certificates where the
      subject of each certificate in the path is the issuer of the next
      certificate in the path.  A certification path begins with a trust
      anchor certificate and ends with an end entity certificate.

2.3.1.  Single CA Architecture

   Definition:  A simple PKI consists of a single CA with a self-signed
      certificate which issues certificates to EEs, as shown in
      Figure 4.


                                   +----+
                                   | CA |
                                   +----+
                                      |
                               +------+-----+
                               v      v     v
                            +----+ +----+ +----+
                            | EE | | EE | | EE |
                            +----+ +----+ +----+

                     Figure 4: Simple PKI Architecture

   Trust Anchor:  The trust anchor MUST be the self-signed certificate
      of the CA.

   Principal CA:  The Principal CA MUST be the CA.

2.3.2.  Multiple CA Architectures

2.3.2.1.  Hierarchical PKI Architecture

   Definition:  A hierarchical PKI consists of a single root CA and one
      or more subordinate CAs that issue certificates to EEs.  A
      hierarchical PKI may have intermediate CAs, which are Subordinate
      CAs that themselves have Subordinate CAs.  The root CAs MUST
      distribute trust anchor (public key and associated data), but the
      format and protocol are irrelevant for this specification.  And
      all subordinate CAs MUST have subordinate CA certificates, as
      shown in Figure 5.

   Trust Anchor:  The trust anchor MUST be the root CA.






Shimaoka, et al.          Expires June 5, 2008                  [Page 9]

Internet-Draft      multi-domain PKI interoperability      December 2007


   Principal CA:  The Principal CA MUST be the root CA.


                            +---------+
                            | Root CA |
                            +---------+
                                 |
                    +------------+------------+
                    v                         v
                  +----+                    +----+
                  | CA |                    | CA |
                  +----+                    +----+
                    |                         |
             +------+------+         +--------+-------+
             v      v      v         v                v
           +----+ +----+ +----+    +----+           +----+
           | EE | | EE | | EE |    | CA |           | CA |
           +----+ +----+ +----+    +----+           +----+
                                     |                |
                                 +---+--+      +------+------+
                                 v      v      v      v      v
                               +----+ +----+ +----+ +----+ +----+
                               | EE | | EE | | EE | | EE | | EE |
                               +----+ +----+ +----+ +----+ +----+

                  Figure 5: Hierarchical PKI Architecture

2.3.2.2.  Mesh PKI Architectures

   Definition:  A mesh PKI consists of multiple CAs with self-signed
      certificates that issue certificates to EEs and issue cross-
      certificates to each other.  A mesh PKI MAY be a full mesh, where
      all CAs issue cross-certificates to all other CAs, as shown in
      Figure 6.  A mesh PKI MAY be a partial mesh, where all CAs do not
      issue cross-certificates to all other CAs.  In a partial mesh PKI,
      certification paths may not exist from all CAs to all other CAs,
      as shown in Figure 7.














Shimaoka, et al.          Expires June 5, 2008                 [Page 10]

Internet-Draft      multi-domain PKI interoperability      December 2007


                     +--------- +-----+ <--------+
                     |          | CA1 |          |
                     | +------> +-----+ -------+ |
                     | |           |           | |
                     | |       +---+--+        | |
                     | |       v      v        | |
                     | |     +----+ +----+     | |
                     | |     | EE | | EE |     | |
                     | |     +----+ +----+     | |
                     v |                       v |
                   +-----+ ----------------> +-----+
                   | CA2 |                   | CA3 |
                   +-----+ <---------------- +-----+
                      |                         |
                  +---+--+               +------+------+
                  v      v               v      v      v
                +----+ +----+          +----+ +----+ +----+
                | EE | | EE |          | EE | | EE | | EE |
                +----+ +----+          +----+ +----+ +----+

                   Figure 6: Full Mesh PKI Architecture


                     +--------- +-----+
                     |          | CA1 | --------+
                     | +------> +-----+         |
                     | |           |            |
                     | |       +---+--+         |
                     | |       v      v         |
                     | |     +----+ +----+      |
                     | |     | EE | | EE |      |
                     | |     +----+ +----+      |
                     v |                        v
                   +-----+                   +-----+
                   | CA2 | ----------------> | CA3 |
                   +-----+                   +-----+
                      |                         |
                  +---+--+               +------+------+
                  v      v               v      v      v
                +----+ +----+          +----+ +----+ +----+
                | EE | | EE |          | EE | | EE | | EE |
                +----+ +----+          +----+ +----+ +----+

                  Figure 7: Partial Mesh PKI Architecture







Shimaoka, et al.          Expires June 5, 2008                 [Page 11]

Internet-Draft      multi-domain PKI interoperability      December 2007


   Trust Anchor:  The trust anchor for an end entity is usually the CA
      that issued its certificate.  The trust anchor for an end entity
      who is not issued a certificate from the mesh PKI MAY be any CA in
      the PKI.  In a partial mesh, selection of the trust anchor may
      result in no certification path from the trust anchor to one or
      more CAs in the mesh.  For example, Figure 7 above, selection of
      CA1 or CA2 as the trust anchor will result in paths from all end
      entities in the figure.  However, selection of CA3 as the trust
      anchor will result in certification paths only for those EEs whose
      certificates were issued by CA3.  No certification path exists to
      CA1 or CA2.

   Principal CA:  The Principal CA MAY be any CA within the mesh PKI.
      However, the mesh PKI MUST have only one Principal CA, and a
      certification path SHOULD exist from the Principal CA to all other
      CAs within the mesh PKI.

   Considerations:  This model SHOULD be used sparingly, especially the
      partial mesh model, because of the complexity of determining trust
      anchors and building certification paths.  A full mesh PKI MAY be
      useful for certification path building, because paths of length
      one exist from all CAs to all other CAs in the mesh.

2.3.2.3.  Hybrid PKI Architectures

   Definition:  A hybrid PKI is a PKI which uses combination of both the
      pure hierarchical model using subordinate CA certificates and the
      pure mesh model using cross-certificates.

                    +-----+ <----- +-----+
                    | CA2 |        | CA1 |
                    +-----+ -----> +-----+
                       |              |
                   +---+--+       +---+--+-------+
                   v      v       v      v       v
                +----+ +----+   +----+ +----+ +-----+
                | EE | | EE |   | EE | | EE | | CA3 |
                +----+ +----+   +----+ +----+ +-----+
                                                 |
                                          +------+------+
                                          v      v      v
                                        +----+ +----+ +----+
                                        | EE | | EE | | EE |
                                        +----+ +----+ +----+

                      Figure 8: Hybrid PKI Architecture





Shimaoka, et al.          Expires June 5, 2008                 [Page 12]

Internet-Draft      multi-domain PKI interoperability      December 2007


   Trust Anchor:  The trust anchor for a hybrid PKI MAY be any CA with
      self-issued certificates in the hybrid PKI.  However, because of
      the potential complexity of a hybrid PKI, the PKI SHOULD provide
      guidance regarding the selection of the trust anchor to relying
      parties because a relying party may fail to build an appropriate
      certification path to a subscriber if he/she chooses inappropriate
      trust anchor.

   Principal CA:  The Principal CA MAY be any CA within the hybrid PKI
      and SHOULD have a self-signed certificate for cross-certification
      with other PKI domain.  However, the hybrid PKI MUST have only one
      Principal CA, and a certification path MUST exist from the
      Principal CA to every CA within the PKI.

   Considerations:  This model SHOULD be used sparingly because of the
      complexity of determining trust anchors and building certification
      paths.  However, hybrid PKIs may occur as a result of the
      evolution of a PKI over time, such as CAs within an organization
      joining together to become a single PKI.

2.4.  Relationships between PKIs and Relying Parties

   Relying Parties establish trust relationship by Trust Anchor to a
   PKI.  Relying Parties may use Trust List for establishing trust
   relationships to one or more PKIs.  Trust List is a set of one or
   more Trust Anchor for trusting one or more PKIs.

   There are two types of maintenance models of Trust List, Relying
   Party Trust List Model and Trust Authority Model.  Detail information
   of each model is described in section 4.1 (Section 4.1).





















Shimaoka, et al.          Expires June 5, 2008                 [Page 13]

Internet-Draft      multi-domain PKI interoperability      December 2007


3.  PKI Domain

   Two or more PKIs may choose to enter into trust relationships with
   each other.  For these relationships, each PKI retains its own set of
   Certificate Policy OID(s) and its own Principal CA.  Prior to
   establishing the trust relationship, each PKI determines the level of
   trust of each external PKI by reviewing external PKI Certificate
   Policy Document(s) and any other PKI governance documentation through
   a process known as policy mapping.  Trust relationships are
   technically formalized through the issuance of cross-certificates.
   Such a collection of two or more PKIs is known as a PKI Domain.

   PKI Domain:  A set of two or more PKIs that have chosen to enter into
      trust relationships with each other through the use of cross-
      certificates.  Each PKI that has entered into the PKI Domain is
      considered a member of that PKI Domain.  NOTE: This definition
      specifies how domain consists, besides "CA domain" defined in RFC
      4949 [5].

   Domain Policy Object Identifier:  A domain Policy Object Identifier
      (OID) is a policy OID which is shared across a PKI Domain.  Each
      CA in the PKI Domain MUST be operated under the domain policy OID.
      Each CA MAY also have its own policy OID(s) in addition to the
      domain policy OID.  In such a case, the CA MUST comply with both
      policies.  The domain policy OID is used to identify the PKI
      Domain.

   Policy Mapping:  A process by which members of a PKI Domain evaluate
      the CPs and other governance documentation of other potential PKI
      Domain members to determine the level of trust that each PKI in
      the PKI Domain places on certificates issued by each other PKI in
      the PKI Domain.

3.1.  PKI Domain Properties

   o  A PKI Domain MAY operate a Bridge CA or a Unifying CA that defines
      members of the domain by issuing cross-certificates to those
      members.

   o  A single PKI MAY simultaneously belong to two or more PKI Domains.

   o  A PKI Domain MAY contain PKI Domains within its own membership.

   o  Two or more PKI Domains MAY enter into a trust relationship with
      each other.  In this case, they MAY combine into a single PKI
      Domain or retain the existing PKI Domains and define a new PKI
      Domain with the existing PKI Domains as members.




Shimaoka, et al.          Expires June 5, 2008                 [Page 14]

Internet-Draft      multi-domain PKI interoperability      December 2007


   o  A member of a PKI Domain MAY choose to participate in the PKI
      Domain but restrict or deny trust in one or more other member PKIs
      of that same PKI Domain.

3.2.  Requirements for Establishing and Participating in PKI Domains

   The establishment of trust relationships has a direct impact on the
   trust model of relying parties.  As a result, consideration must be
   taken in the creation and maintenance of PKI Domains to prevent
   inadvertent trust.

3.2.1.  PKI Requirements

   In order for a PKI to participate in one or more PKI Domains, that
   PKI MUST have the following:

   o  A Certificate Policy Document documenting the requirements for
      operation of that PKI.  The Certificate Policy Document SHOULD be
      in RFC 3647 [4] format.

   o  One or more Policy OID(s) defined in the Certificate Policy
      Document that are also asserted in all certificates issued by that
      PKI

   o  A defined Principal CA

   PKI Domains MAY also impose additional technical, documentation, or
   policy requirements for membership in the PKI Domain.

3.2.2.  PKI Domain Documentation

   PKI Domains MUST be formally defined and documented.  This
   documentation may vary greatly depending on the of PKI Domain, it
   MUST address the following:

   o  Establish the existence of the PKI Domain.

   o  Define the authority for maintaining the PKI Domain.

         Examples of PKI Domain Authorities are (1) Representatives from
         two PKIs that agree to form a simple PKI Domain, (2) A single
         entity which may or may not be related to any of the PKIs in
         the PKI Domain, (3) A governance board made up of
         representatives from each PKI Domain member.

   o  Define how the PKI Domain is governed.





Shimaoka, et al.          Expires June 5, 2008                 [Page 15]

Internet-Draft      multi-domain PKI interoperability      December 2007


   o  Define the purpose and community of interest of the PKI Domain.

         Examples of PKI Domain intents are (1) allow relying parties of
         one PKI to trust certificates issued by another PKI, (2) Allow
         PKIs that support similar subscriber communities of interest to
         interact with each other, (3) Allow relying parties to trust
         certificates issued by a number of PKIs that all meet a set of
         requirements.

   o  Unless the PKI Domain has a predetermined membership, describe the
      requirements and methods for joining the PKI Domain, such as
      FPKIMETHOD [14].

   Examples of governance documents that PKI Domains MAY choose to use
   are:

   o  Statement of intent between two or more parties

   o  Memorandum of Agreement between two or more parties

   o  Certificate Policy Document for the PKI Domain

   o  Charter for the PKI Domain

   o  Methodology for PKI Domain membership

3.2.3.  PKI Domain Membership Notification

   A cross-certificate from the Principal CA of one PKI to the Principal
   CA of another PKI indicates a mapping between one or more policies of
   the first PKI and one or more policies of the second PKI.  When a
   relying party is determining if a certificate can be validated, it
   builds a certification path from the certificate being presented to a
   Trust Anchor.  To prevent inadvertent trust across PKI Domains when a
   single PKI is a member of two or more disparate PKI Domains, each PKI
   Domain must be cognizant of what PKI Domains its member PKIs
   participate in.  Figure 9 illustrates this concept.














Shimaoka, et al.          Expires June 5, 2008                 [Page 16]

Internet-Draft      multi-domain PKI interoperability      December 2007


                              +-----------------------------+
                              |                PKI Domain 2 |
               +----------------------------+               |
               |              |             |               |
               | +------+ <------ +------+ <------ +------+ |
               | | PKI1 |     |   | PKI2 |  |      | PKI3 | |
               | +------+ ------> +------+ ------> +------+ |
               |              |             |               |
               |              +-----------------------------+
               | PKI Domain 1               |
               +----------------------------+

              Figure 9: Participation in Multiple PKI Domains

   As shown in Figure 9, PKI2 is a member of both PKI Domain 1 and PKI
   Domain 2.  Since a certification path exists from PKI1 to PKI2, and
   from PKI2 to PKI3, a certification path also exists from PKI1 to
   PKI3.  However, PKI1 does not share domain membership with PKI3, so
   the certification path validation from PKI1 to PKI3 with a validation
   policy for PKI Domain 1 must not succeed.  To ensure correct
   certification path validation and policy mapping, the cross
   certificates issued by both PKI1 and PKI3 to PKI2 must contain
   constraints such as policy mapping or name constraints disallowing
   the validation of certification paths outside their respective
   domains.

   To fully prevent inadvertent trust, any PKI that is a member of one
   or more PKI Domains MUST inform all PKI Domains of its membership in
   all other PKI Domains.  In addition, that PKI MUST inform all PKI
   Domains that it is a member of any time its membership status changes
   with regards to any other PKI Domain.  If a PKI Domain is informed of
   the change in status of one of its member PKIs with regards to other
   PKI Domains, that PKI Domain MUST review the constraints in any
   cross-certificate issued to that PKI.  If the change in membership
   would result in a change to the allowed or disallowed certification
   paths, the PKI Domain MUST ensure that all such cross-certificates
   are revoked and re-issued with correct constraints.

3.2.4.  Considerations for PKIs and PKI Domains with Multiple Policies

   In some cases, a single PKI MAY issue certificates at more than one
   assurance level.  If so, the Certificate Policy Document MUST define
   separate policy OIDs for each assurance level, and MUST define the
   differences between certificates of different assurance levels.

   A PKI Domain MAY also support more than one assurance level.  If so,
   the PKI Domain MUST also define separate policy OIDs for each
   assurance level, and MUST define the differences in requirements for



Shimaoka, et al.          Expires June 5, 2008                 [Page 17]

Internet-Draft      multi-domain PKI interoperability      December 2007


   each level.

   When PKIs and PKI Domains choose to establish trust relationships,
   these trust relationships MAY exist for only one defined assurance
   level, MAY have a one-to-one relationship between PKI assurance
   levels and PKI Domain assurance levels, or MAY have many-to-one or
   one-to-many relationships between assurance levels.  These
   relationships MUST be defined in cross-certificates issued between
   PKIs in the PKI Domain.

3.3.  PKI Domain Models

   Two or more PKI Domains may choose to enter into trust relationships
   with each other.  In that case, they may form a larger PKI Domain by
   establishing a new Unifying or Bridge CA or by issuing cross
   certificates between their Principal CAs.

3.3.1.  Unifying Trust Point (Unifying Domain) Model

   In the Unifying Trust Point Model, a PKI Domain is created by
   establishing a joint superior CA that issues unilateral cross-
   certificates to each PKI Domain, as shown in Figure 10.  Such a joint
   superior CA is defined as Unifying CA, and the Principal CAs in each
   PKI Domain have the hierarchical CA relationship with that Unifying
   CA.  In this model, any relying party from any of the PKI Domains
   MUST specify the Unifying CA as its trust anchor in order to validate
   a subscriber in the other PKI Domains.  If the relying party does not
   desire to validate subscribers in other PKI Domains, the relying
   party MAY continue to use the Principal CA from the old PKI Domain as
   its trust anchor.

   This model may be used for merging multiple PKI Domains into a single
   PKI Domain with less change to existing PKI Domains, or MAY be used
   to combine multiple PKI Domains into one PKI Domain for relying
   parties.  The unilateral cross-certificate issued by the Unifying CA
   to the Principal CAs in each PKI Domain may include any policy
   mapping.














Shimaoka, et al.          Expires June 5, 2008                 [Page 18]

Internet-Draft      multi-domain PKI interoperability      December 2007


              Cross-certified                   Cross-certified
               Unifying CA                       Unifing CA
              to PKI Domain 1 +--------------+  to PKI Domain 3
                    +---------|  Unifying CA |---+
                    |         +--------------+   |
                    |                 |          |
                    |  Cross-certified|          |
                    |   Unifying CA   |          |
                    |  to PKI Domain 2|          |
        +-----------|---+ +-----------|---+ +----|-----------------+
        |    PKI    |   | |    PKI    |   | |    |    PKI          |
        |  domain 1 |   | |  domain 2 |   | |    |  domain 3       |
        |           v   | |           v   | |    v                 |
        |       +-----+ | |       +-----+ | | +-----+ ----+        |
        |   +---| PCA | | |       | PCA | | | | PCA |     |        |
        |   |   +-----+ | |       +-----+ | | +-----+ <-+ |        |
        |   |      |    | |          |    | |   | ^     | v        |
        |   |      |    | |          |    | |   | |   +----+       |
        |   |      |    | |          |    | |   | |   | CA |---+   |
        |   |      |    | |          |    | |   | |   +----+   |   |
        |   |      |    | |          v    | |   v |    ^ |     |   |
        |   |      |    | |       +----+  | | +----+   | |     |   |
        |   |      |    | |   +---| CA |  | | | CA |---+ |     |   |
        |   |      |    | |   |   +----+  | | +----+     |     |   |
        |   |      |    | |   |      |    | |   |        |     |   |
        |   v      v    | |   v      v    | |   v        v     v   |
        | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ |
        | | EE | | EE | | | | EE | | EE | | | | EE | | EE | | EE | |
        | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ |
        +---------------+ +---------------+ +----------------------+

          Figure 10: Unifying Trust Point (Unifying Domain) Model

3.3.2.  Independent Trust Point Models

   In Independent Trust Point Models, relying parties continue to use
   only the trust anchor of their PKI Domain.  A relying party in the
   individual trust point model can continue to use the trust anchor of
   its PKI Domain.

3.3.2.1.  Direct Cross-Certification Model

   The model in which each PKI Domain trusts each other by issuing
   cross-certificate directly between each Principal CA, as shown in
   Figure 11.  This model may be used for shortening a certification
   path, or establishing a trust relationship expeditiously.





Shimaoka, et al.          Expires June 5, 2008                 [Page 19]

Internet-Draft      multi-domain PKI interoperability      December 2007


   Considerations:  A PKI Domain in this model SHOULD consider that the
      other PKI Domain may cross-certify with any more PKI Domains.  If
      a PKI Domain wants to restrict a certification path, the PKI
      Domain SHOULD NOT rely on the validation policy of the relying
      party, but SHOULD include the constraints in the cross-certificate
      explicitly.  A PKI Domain that relies on the validation policy of
      the relying party about such constraints cannot guarantee the
      constraints will be recognized and followed.


        +---------------+                 +------------------------+
        |    PKI        | cross-certified |         PKI            |
        |  domain 1     |    each other   |       domain 2         |
        |      +-----+ --------------------> +-----+ ----+         |
        |      | PCA |  |                 |  | PCA |     |         |
        |      +-----+ <-------------------- +-----+ <-+ |         |
        |         |     |                 |     ^      | v         |
        |         |     |                 |     |    +----+        |
        |         |     |                 |     |    | CA |---+    |
        |         |     |                 |     |    +----+   |    |
        |         v     |                 |     v     ^ |     |    |
        |       +----+  |                 |   +----+  | |     |    |
        |   +---| CA |  |                 |   | CA |--+ |     |    |
        |   |   +----+  |                 |   +----+    |     |    |
        |   |      |    |                 |     |       |     |    |
        |   v      v    |                 |     v       v     v    |
        | +----+ +----+ |                 |   +----+ +----+ +----+ |
        | | EE | | EE | |                 |   | EE | | EE | | EE | |
        | +----+ +----+ |                 |   +----+ +----+ +----+ |
        +---------------+                 +------------------------+

                Figure 11: Direct Cross-Certification Model

3.3.2.2.  Bridge Model

   The model in which every PKI Domain trusts each other through a
   Bridge CA by Cross-Certification, as shown in Figure 12.  In this
   model, the trust relationship is not established between a subscriber
   domain and a relying party domain directly, but established from the
   Principal CA of relying party's PKI Domain via Bridge CA.  This model
   is useful in reducing the number of cross-certifications required for
   a PKI Domain to interoperate with other PKI Domains.

   Requirements for Bridge model:

   o  Bridge CA MUST NOT be used as the trust anchor in any PKI Domain.





Shimaoka, et al.          Expires June 5, 2008                 [Page 20]

Internet-Draft      multi-domain PKI interoperability      December 2007


   o  Bridge CA SHOULD issue cross-certificates with other PKI Domains
      mutually or MAY issue cross certificates unilaterally.

   o  Bridge CA MUST NOT issue EE certificates except when it is
      necessary for the CA's operation.

   o  Bridge CA MUST use its own domain policy OID, not other PKI Domain
      policy OID(s), for the policy mapping.

   o  Bridge CA SHOULD be a neutral position to all PKI Domains which
      trust through the Bridge CA.  For example in Figure 12, in the
      case that a relying party who trusts the PCA of PKI Domain 1 as
      its trust anchor builds the certification path to a subscriber in
      PKI Domain 3:

         Cross-Certificate from PKI Domain 1 to Bridge CA:

            issuerDomainPolicy := domain policy OID of PKI Domain 1

            subjectDomainPolicy := domain policy OID of Bridge CA

         Cross-Certificate from Bridge CA to PKI Domain 3:

            issuerDomainPolicy := domain policy OID of Bridge CA

            subjectDomainPolicy := domain policy OID of PKI Domain 3

   o  Cross-Certificates issued by Bridge CA and Cross-Certificate
      issued to Bridge CA SHOULD include the requireExplicitPolicy with
      a value that is greater than zero in the policyConstraints
      extension because a relying party MAY not set the initial-
      explicit-policy to TRUE.

   o  PKI Domains cross-certified with Bridge CA SHOULD NOT cross-
      certify directly to other PKI Domains cross-certified with the
      same Bridge CA.

   o  Bridge CA SHOULD clarify the method for the policy mapping of
      cross-certification to keep its transparency.

   Considerations:  The Bridge CA SHOULD be operated by an independent
      third party agreed upon by the PKI Domains or a consortium
      consisting of representation from the PKI Domain members.  The
      Bridge CA SHOULD do policy mapping in a well documented and agreed
      upon manner with all PKI Domains.  For using the name constraints,
      the Bridge CA SHOULD pay attention to preventing a conflict of
      each name space of the cross-certified PKI Domains.  The PKI
      Domains that perform cross-certification with the Bridge CA SHOULD



Shimaoka, et al.          Expires June 5, 2008                 [Page 21]

Internet-Draft      multi-domain PKI interoperability      December 2007


      confirm the following:

      *  Does the Bridge CA perform the policy mapping via its own
         domain policy OID?

      *  Does the Bridge CA clarify the method of policy mapping in the
         cross-certification?

      *  Is the Bridge CA able to accept the domain policy that the PKI
         Domain desires?

         +  If the domain policy is mapped to one with a lower security
            level, the PKI Domain SHOULD NOT accept it.  Otherwise, the
            PKI Domain MUST carefully consider the risks involved with
            accepting certificates with a lower security level.


          cross-certified                      cross-certified
        PKI Domain 1 with BCA               PKI Domain 3 with BCA
                  +---------> +-----------+ -----+
                  |           | Bridge CA |      |
                  | +-------- +-----------+ <--+ |
                  | |                 ^ |      | |
                  | | cross-certified | |      | |
                  | |   PKI Domain 2  | |      | |
                  | |     with BCA    | |      | |
        +---------|-|---+ +-----------|-|-+ +--|-|-----------------+
        |  PKI    | |   | |   PKI     | | | |  | |    PKI          |
        |domain 1 | v   | | domain 2  | v | |  | v  domain 3       |
        |       +-----+ | |       +-----+ | | +-----+ ----+        |
        |   +---| PCA | | |       | PCA | | | | PCA |     |        |
        |   |   +-----+ | |       +-----+ | | +-----+ <-+ |        |
        |   |      |    | |          |    | |   | ^     | v        |
        |   |      |    | |          |    | |   | |   +----+       |
        |   |      |    | |          |    | |   | |   | CA |---+   |
        |   |      |    | |          |    | |   | |   +----+   |   |
        |   |      |    | |          v    | |   v |    ^ |     |   |
        |   |      |    | |       +----+  | | +----+   | |     |   |
        |   |      |    | |   +---| CA |  | | | CA |---+ |     |   |
        |   |      |    | |   |   +----+  | | +----+     |     |   |
        |   |      |    | |   |      |    | |   |        |     |   |
        |   v      v    | |   v      v    | |   v        v     v   |
        | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ |
        | | EE | | EE | | | | EE | | EE | | | | EE | | EE | | EE | |
        | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ |
        +---------------+ +---------------+ +----------------------+

                          Figure 12: Bridge Model



Shimaoka, et al.          Expires June 5, 2008                 [Page 22]

Internet-Draft      multi-domain PKI interoperability      December 2007


3.4.  Operational Considerations

   Each PKI Domain MAY use policy mapping for crossing different PKI
   Domains.  If a PKI Domain wants to restrict a certification path, the
   PKI Domain SHOULD NOT rely on the validation policy of the relying
   party, but SHOULD include the constraints in the cross-certificate
   explicitly.

   For example, when each PKI Domain wants to affect the constraints to
   a certification path, it SHOULD set the requireExplicitPolicy to zero
   in the policyConstraints extension of any cross-certificates.  A PKI
   Domain that relies on the validation policy of the relying party
   about such constraints cannot guarantee the constraints will be
   recognized and followed.





































Shimaoka, et al.          Expires June 5, 2008                 [Page 23]

Internet-Draft      multi-domain PKI interoperability      December 2007


4.  Trust Models External to PKI Relationships

   As opposed to PKI Doman trust relationships entered into by PKIs
   themselves, trust across multiple PKIs can be created by entities
   external to the PKIs through locally configured lists of trust
   anchors.

   Trust List:  A set of one or more Trust Anchors used by a relying
      party to explicitly trust one or more PKIs.

   Note that Trust Lists are often created without the knowledge of the
   PKIs that are included in the list.

4.1.  Trust List Models

4.1.1.  Local Trust List Model

   A Trust List can be created and maintained by a single relying party
   for its own use.

   Local Trust List:  A Trust List installed and maintained by a single
      relying party for its own use.  NOTE: This definition likes
      "trust-file PKI" defined in RFC 4949 [5].  However, this document
      prefer the word "Local Trust List" against "Trust Authority" after
      mentioned.

   Figure 13 illustrates a Local Trust List.

      +-------------------------------------------------------------+
      |  Relying Party                                              |
      | +---------------------------------------------------------+ |
      | | Trust List                                              | |
      | | +--------------+  +--------------+     +--------------+ | |
      | | | PKI 1        |  | PKI 2        | ... | PKI n        | | |
      | | | Trust Anchor |  | Trust Anchor |     | Trust Anchor | | |
      | | +--------------+  +--------------+     +--------------+ | |
      | +---------------------------------------------------------+ |
      +-------------------------------------------------------------+

              Figure 13: Relying Party Local Trust List Model

   Creating a Local Trust List is the simplest method for relying
   parties to trust EE certificates.  Using Local Trust Lists does not
   require cross-certification between the PKI that issued the relying
   party's own certificate and the PKI that issued the EE's certificate.
   Nor does it require implementing mechanisms for processing complex
   certification paths, as all CAs in a path can be included in the
   Local Trust List.  As a result, Local Trust Lists are the most common



Shimaoka, et al.          Expires June 5, 2008                 [Page 24]

Internet-Draft      multi-domain PKI interoperability      December 2007


   model in use today.  However, because Local Trust Lists are created
   and managed independently by each Relying Party, the use of Local
   Trust Lists can be difficult for an enterprise to manage.

4.1.2.  Trust Authority Model

   Alternatively, a Trust List can be created and maintained for use by
   multiple relying parties.  In this case, the entity responsible for
   the Trust List is known as a Trust Authority.

   Trust Authority:  An entity that manages a Trust List for use by one
      or more relying parties.

   Figure 14 illustrates a Trust Authority and how it is used by Relying
   Parties.  Note that the Trust Authority replaces the PKI Trust
   Anchor(s) in the Local Trust List for each participating Relying
   Party.

      +-------------------------------------------------------------+
      |  Trust Authority                                            |
      | +---------------------------------------------------------+ |
      | | Trust List                                              | |
      | | +--------------+  +--------------+     +--------------+ | |
      | | | PKI 1        |  | PKI 2        | ... | PKI n        | | |
      | | | Trust Anchor |  | Trust Anchor |     | Trust Anchor | | |
      | | +--------------+  +--------------+     +--------------+ | |
      | +---------------------------------------------------------+ |
      +-------------------------------------------------------------+

           +---------------------+  +---------------------+
           |   Relying Party 1   |  |   Relying Party 2   |
           | +-----------------+ |  | +-----------------+ | ...
           | | Trust Authority | |  | | Trust Authority | |
           | +-----------------+ |  | +-----------------+ |
           +---------------------+  +---------------------+

                     Figure 14: Trust Authority Model

   A Trust Authority may be operated by a PKI, a collection of relying
   parties that share a common set of users, an enterprise on behalf of
   all of its relying parties, or an independent entity.  Although PKIs
   generally establish trust relationships through cross-certificates, a
   PKI may choose to provide a Trust Authority to support relying
   parties that do not support processing of certification paths.  A
   collection of relying parties that share a common set of users may
   choose to maintain a single Trust Authority to simplify the
   management of Trust Lists.  An enterprise may choose to provide a
   Trust Authority to implement enterprise policies and direct all



Shimaoka, et al.          Expires June 5, 2008                 [Page 25]

Internet-Draft      multi-domain PKI interoperability      December 2007


   Relying Parties within the enterprise to use its Trust Authority.
   Finally, an independent entity may choose to operate a Trust
   Authority as a managed service.

4.2.  Trust List Considerations

4.2.1.  Considerations for a PKI

   A PKI SHOULD publish its Certificate Policy Document so that Relying
   Parties and Trust Authorities can determine what, if any, warranties
   are provided by the PKI regarding reliance on EE certificates.

   A PKI SHOULD broadly publicize information regarding revocation or
   compromise of a Trust Anchor or Principal CA certificate through
   notice on a web page, press release, and/or other appropriate
   mechanisms so that Relying Parties and Trust Authorities can
   determine if a Trust Anchor or Principal CA certificate installed in
   a Trust List should be removed.

   A PKI SHOULD publish CRLs or other information regarding the
   revocation status of EE certificates to a repository that can be
   accessed by any party that desires to rely on the EE certificates.

4.2.2.  Considerations for Relying Parties and Trust Authorities

   Relying Parties and Trust Authorities are responsible for the
   following prior to including a PKI in the Trust List:

   o  Reviewing the Certificate Policy Document of each PKI to determine
      that the PKI is operated to an acceptable level of assurance.

   o  Reviewing the Certificate Policy Document of each PKI to ensure
      any requirements imposed on Relying Parties are met.

   o  Determining if the PKI provides any warranties regarding reliance
      on EE certificates, and if these warranties are acceptable for the
      intended reliance on the EE certificates.  Reliance may be at the
      Relying Party's own risk.

   o  Periodically reviewing information published by the PKI to its
      repository, including Certificate Policy Document updates or
      notice of CA revocation or compromise.

   A PKI can choose to join or leave PKI Domains in accordance with its
   Certificate Policy Document.  If the Relying Party or Trust Authority
   does not wish to inherit trust in other members of these PKI Domains,
   it is the responsibility of the Relying Party or Trust Authority to
   inhibit policy mapping.



Shimaoka, et al.          Expires June 5, 2008                 [Page 26]

Internet-Draft      multi-domain PKI interoperability      December 2007


4.2.3.  Additional Considerations for Trust Authorities

   A Trust Authority SHOULD establish a Trust Authority Policy that
   identifies the following:

   o  The intended community of Relying Parties that will use the Trust
      Authority.

   o  The process by which Trust Anchors are added or removed from the
      Trust List.

   o  Any warranties provided by the Trust Authority for reliance on EE
      certificates.  These warranties may be those provided by the PKIs
      themselves or may be additional warranties provided by the Trust
      Authority.

   o  Information regarding how the Trust Authority protects the
      integrity of its Trust List.

   o  Information regarding how Relying Parties interact with the Trust
      Authority to obtain information as to whether an EE certificate is
      trusted.





























Shimaoka, et al.          Expires June 5, 2008                 [Page 27]

Internet-Draft      multi-domain PKI interoperability      December 2007


5.  Abbreviations

   CA:  Certification Authority

   EE:  End Entity

   OID:  Object Identifier

   PCA:  Principal Certification Authority

   PKI:  Public Key Infrastructure








































Shimaoka, et al.          Expires June 5, 2008                 [Page 28]

Internet-Draft      multi-domain PKI interoperability      December 2007


6.  Security Considerations

   This section highlights security considerations related to
   establishing PKI Domains.

   Because this RFC defines terminology and not protocols or technology
   for implementing the terminology, technology-specific security
   considerations are not applicable.  However, a high level discussion
   of applicable security considerations is warranted.

6.1.  PKI Domain Models

   For all PKI Domain models that described in section 3.3 created
   through the issuance of cross certificates, standard threats
   including message insertion, modification, and man-in-the-middle are
   not applicable because all information created by CAs, including
   policy mapping and constraints, is digitally signed by the CA
   generating the cross-certificate.

   Verifying that a given certificate was issued by a member of a PKI
   Domain may be a time critical determination.  If cross certificates
   and revocation status information cannot be obtained in a timely
   manner, a denial of service may be experienced by the end entity.  In
   situations where such verification is critical, caching of cross
   certificates and revocation status information may be warranted.

   An additional security consideration for PKI Domains is inadvertent
   trust, which can occur if a single PKI is a member of multiple PKI
   Domains.  See Section 3.2.3 for a discussion of inadvertent trust and
   mechanisms to prevent it.

   Finally, members of PKI Domains MUST participate in domain
   governance, or at a minimum, be informed anytime a PKI joins or
   leaves the domain, so that domain members can make appropriate
   decisions for maintaining their own membership in the domain or
   choosing to restrict or deny trust in the new member PKI.

6.2.  Trust List Models

   In these models also, many standard attacks are not applicable since
   certificates are digitally signed.  Additional security
   considerations apply when trust is created through trust list.

   A variation of the modification attack is possible in trust list
   models.  If an attacker is able to add or remove CAs from the relying
   party or trust authority trust list, the attacker can affect which
   certificates will or will not be accepted.  To prevent this attack,
   access to trust lists MUST be adequately protected against



Shimaoka, et al.          Expires June 5, 2008                 [Page 29]

Internet-Draft      multi-domain PKI interoperability      December 2007


   unauthorized modification.  This protection is especially important
   for trust anchors that are used by multiple applications, as it is a
   key vulnerability of this model.  This attack may result in
   unauthorized usage if a CA is added to a trust list, or denial of
   service if a CA is removed from a trust list.

   For trust authority models, a denial of service attack is also
   possible if the application cannot obtain timely information from the
   trust anchor.  Applications SHOULD specify service level agreements
   with trust authority.  In addition, applications MAY choose to
   locally cache the list of CAs maintained by the trust authority as a
   backup in the event that the trust anchor's repository (e.g., LDAP
   directory) is not available.






































Shimaoka, et al.          Expires June 5, 2008                 [Page 30]

Internet-Draft      multi-domain PKI interoperability      December 2007


7.  IANA Considerations

   This document has no actions for IANA.
















































Shimaoka, et al.          Expires June 5, 2008                 [Page 31]

Internet-Draft      multi-domain PKI interoperability      December 2007


8.  References

8.1.  Normative References

   [1]   Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
         Public Key Infrastructure Certificate and Certificate
         Revocation List (CRL) Profile", RFC 3280, April 2002.

   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

8.2.  Informative References

   [3]   International International Telephone and Telegraph
         Consultative Committee, "Information Technology - Open Systems
         Interconnection - The Directory: Authentication Framework",
         CCITT Recommendation X.509, March 2000.

   [4]   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.

   [5]   Shirey, R., "Internet Security Glossary, Version 2", RFC 4949,
         August 2007.

   [6]   Housley, R. and W. Polk, "Planning for PKI", August 2001.

   [7]   Lloyd, S., Ed. and PKI Forum, "PKI Interoperability Framework",
         March 2001.

   [8]   Lloyd, S., Ed. and PKI Forum, "CA-CA Interoperability",
         March 2001.

   [9]   Shimaoka, M., NPO Japan Network Security Association, and ISEC,
         Information Technology Promotion Agency, Japan,
         "Interoperability Issues for multi PKI domain", July 2002.

   [10]  NPO Japan Network Security Association and ISEC, Information
         Technology Promotion Agency, Japan, "Implementation Problems on
         PKI", Feb 2003.

   [11]  Japan PKI Forum, Korea PKI Forum, PKI Forum Singapore, and
         Chinese Taipei PKI Forum, "Achieving PKI Interoperability
         2003", July 2003.

   [12]  Japan PKI Forum, Korea PKI Forum, and PKI Forum Singapore,
         "Achieving PKI Interoperability", April 2002.



Shimaoka, et al.          Expires June 5, 2008                 [Page 32]

Internet-Draft      multi-domain PKI interoperability      December 2007


   [13]  Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R.
         Nicholas, "Internet X.509 Public Key Infrastructure:
         Certification Path Building", RFC 4158, September 2005.

   [14]  "US Government PKI Cross-Certification Criteria and
         Methodology", January 2006.













































Shimaoka, et al.          Expires June 5, 2008                 [Page 33]

Internet-Draft      multi-domain PKI interoperability      December 2007


Authors' Addresses

   Masaki Shimaoka (editor)
   SECOM Co., Ltd. Intelligent System Laboratory
   SECOM SC Center, 8-10-16 Shimorenjaku
   Mitaka, Tokyo  181-8528
   JP

   Email: m-shimaoka@secom.co.jp


   Nelson Hastings
   National Institute of Standard and Technology
   100 Bureau Drive, Stop 8930
   Gaithersburg, MD  20899-8930
   US

   Email: nelson.hastings@nist.gov


   Rebecca Nielsen
   Booz Allen Hamilton
   8283 Greensboro Drive
   McLean, VA  22102
   US

   Email: nielsen_rebecca@bah.com
























Shimaoka, et al.          Expires June 5, 2008                 [Page 34]

Internet-Draft      multi-domain PKI interoperability      December 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Shimaoka, et al.          Expires June 5, 2008                 [Page 35]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/