[Docs] [txt|pdf] [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
Internet-Draft                                                     SECOM
Expires: January 10, 2007                                    N. Hastings
                                                                    NIST
                                                              R. Nielsen
                                                     Booz Allen Hamilton
                                                            July 9, 2006


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

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 January 10, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This memo is intended to describe the foundation necessary to the
   deployment of a multi-domain PKI.  The scope of this memo is to
   establish and clarify the trust relationships and interoperability
   between multiple PKI domains.  A Certification Authority (CA) is able
   to extend a certification path by establishing trust with other CAs.



Shimaoka, et al.        Expires January 10, 2007                [Page 1]

Internet-Draft      multi-domain PKI interoperability          July 2006


   Both single- and multi-domain PKIs are established by such trust
   relationships between CAs.  Typical and primitive PKI model is a
   single-domain PKI that shares the same Certificate Policy (CP) at a
   specified trust level.  A multi-domain PKI is established by
   combining more than one single-domain PKI.  A multi-domain PKI can be
   categorized as either a multi-trust point model based on the trust
   list model; or single-trust point model based on the Cross-
   Certification model.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Objective  . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Document Outline . . . . . . . . . . . . . . . . . . . . .  3
     1.3.  Requirements and Assumptions . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Basic Concepts . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Certification Authority Relationships  . . . . . . . . . .  5
       2.2.1.  Hierarchical . . . . . . . . . . . . . . . . . . . . .  6
       2.2.2.  Peer . . . . . . . . . . . . . . . . . . . . . . . . .  7
     2.3.  Public Key Infrastructure (PKI)  . . . . . . . . . . . . .  7
       2.3.1.  Simple PKI . . . . . . . . . . . . . . . . . . . . . .  8
       2.3.2.  Hierarchical PKI . . . . . . . . . . . . . . . . . . .  9
       2.3.3.  Mesh PKI . . . . . . . . . . . . . . . . . . . . . . . 10
       2.3.4.  Hybrid PKI . . . . . . . . . . . . . . . . . . . . . . 12
   3.  Trust Lists  . . . . . . . . . . . . . . . . . . . . . . . . . 14
     3.1.  Relying Party Trust List Model . . . . . . . . . . . . . . 15
     3.2.  Trust Authority Model  . . . . . . . . . . . . . . . . . . 16
   4.  PKI Domain . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     4.1.  Requirements for PKI domain  . . . . . . . . . . . . . . . 18
     4.2.  Risk Analysis of non-interoperable PKI domains . . . . . . 18
     4.3.  Trust Relationship Disclosure Requirements for
           multi-domain PKIs  . . . . . . . . . . . . . . . . . . . . 18
   5.  Abbreviations  . . . . . . . . . . . . . . . . . . . . . . . . 19
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 22
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
   Intellectual Property and Copyright Statements . . . . . . . . . . 25









Shimaoka, et al.        Expires January 10, 2007                [Page 2]

Internet-Draft      multi-domain PKI interoperability          July 2006


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 (Section 2) describes basic PKI terminology necessary to
   consider trust relationships.  Section 3 (Section 3) focuses on trust
   relationships established by relying parties.  Section 4 (Section 4)
   defines a PKI domain and requirements for PKI interoperation within a
   PKI domain.  Section 5 defines requirements for interoperation across
   PKI domains.  Finally, Section 6 provides a glossary summarizing the
   terms described in the remainder of the document.

1.3.  Requirements and Assumptions

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























Shimaoka, et al.        Expires January 10, 2007                [Page 3]

Internet-Draft      multi-domain PKI interoperability          July 2006


2.  Terminology

2.1.  Basic Concepts

   The following terms defining basic constructs are used throughout
   this document.  Where possible, definitions found in RFC 2828 [2]
   have been used.  Additional terms from RFC 2828 [2] and new terms
   that define relationships between these constructs are introduced and
   defined in later sections.  A full list of terms can be found in
   Section 6 [8.1].

   Certificate

      A digitally-signed data structure that attests to the binding of a
      system entity's identity to a public key value. [modified from the
      RFC 2828 definition of public-key certificate]

   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) [5]

   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 2828) [2]

   End Entity

      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 2828) [2]

   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 the RFC 2828 definition of certificate user]

   Trust Anchor

      A certificate upon which a relying party relies as being valid
      without the need for validation testing. [modified from the RFC
      2828 definition of trusted certificate]




Shimaoka, et al.        Expires January 10, 2007                [Page 4]

Internet-Draft      multi-domain PKI interoperability          July 2006


2.2.  Certification Authority Relationships

   Certification Authorities (CA) establish trust relationships by
   issuing certificates to other CAs.  CA relationships can be either
   hierarchical or peer.  There are three types of certificates that are
   issued by CAs to other CAs, self-signed certificates, subordinate CA
   certificates, or peer cross-certificates.  The process of issuing
   cross-certificates is known as cross-certification, which can be
   either unilateral or bilateral.

   Self-Signed Certificate

      A certificate for which the public key bound by the certificate
      and the private key used to sign the certificate are components of
      the same key pair, which belongs to the signer.  (RFC 2828) [2]

   Cross-Certificate

      A certificate issued from one CA to another CA.

   Subordinate CA Certificate

      A certificate issued from one CA to another CA which becomes that
      CA's own signing certificate.  Because the CA that is the subject
      of the subordinate CA certificate uses the subordinate CA
      certificate as its own signing certificate, the issuing CA
      authorizes the existence of the subordinate CA. [modified from the
      RFC 2828 definition of subordinate certification authority]

   Peer Cross-Certificate

      A certificate issued from one CA to another CA where the CA that
      is the subject of the cross-certificate does not use the cross-
      certificate as its own signing certificate.

   Cross-Certification

      The act or process of issuing a cross-certificate.  Note that this
      definition is not the same as the definition in RFC 2828 [2],
      which only addresses bilateral cross-certification.

   Unilateral Cross-Certification

      The act or process by which one CA certifies the public key of
      another CA by issuing a peer cross-certificate to that other CA.
      [modified from the RFC 2828 definition of cross-certification]

   Bilateral Cross-Certification



Shimaoka, et al.        Expires January 10, 2007                [Page 5]

Internet-Draft      multi-domain PKI interoperability          July 2006


      The act or process by which two CAs each certify a public key of
      the other by each CA issuing a peer cross-certificate to the other
      CA. [modified from the RFC 2828 definition of cross-certification]

2.2.1.  Hierarchical

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

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

   Figure 1: Hierarchical Trust Relationship

   There are two types of hierarchical relationships, depending on
   whether a subordinate CA certificate or a peer cross-certificate is
   used.  In the case where one 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 peer cross-certificates to other CAs, that CA is
   called a Unifying CA.  Unifying CAs only use unilateral peer cross-
   certificates.

   Root CA

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

   Unifying CA

      A CA that is at the top of a hierarchy, and itself does not issue
      certificates to end entities (except those required for its own
      operation) but establishes unilateral cross-certification with
      other CAs.







Shimaoka, et al.        Expires January 10, 2007                [Page 6]

Internet-Draft      multi-domain PKI interoperability          July 2006


2.2.2.  Peer

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

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

   Figure 2: Peer Trust Relationship

   In the case where a CA exists only to manage peer 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.


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

   Figure 3: Bridge CA

2.3.  Public Key Infrastructure (PKI)

   RFC 2828 [2] defines a PKI as "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



Shimaoka, et al.        Expires January 10, 2007                [Page 7]

Internet-Draft      multi-domain PKI interoperability          July 2006


   application of asymmetric cryptography."  However, this definition
   does not provide a good concept of a PKI boundary e.g., when two CAs
   enter a trust relationship, under what circumstances are they
   becoming part of the same PKI and when are they creating a trust
   relationship between two distinct PKIs.  The definition of PKI in
   this document adds a boundary constraint to the definition.

   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 a single
      Certificate Policy, 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

      A CA which has a self-signed certificate and is designated as the
      CA that will issue peer cross-certificates to principal CAs in
      other PKIs and be the subject of peer 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
   based on trust relationships between CAs.

   Certification Path

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

2.3.1.  Simple PKI

   Definition

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





Shimaoka, et al.        Expires January 10, 2007                [Page 8]

Internet-Draft      multi-domain PKI interoperability          July 2006


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

   Figure 4: Simple PKI Model

   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.  Hierarchical PKI

   Definition

      A hierarchical PKI consists of a single root CA and one or more
      subordinate CAs that issue certificates to EEs.  The root CA MUST
      have a self-signed certificate and all subordinate CAs MUST have
      subordinate CA certificates, as shown in Figure 5.























Shimaoka, et al.        Expires January 10, 2007                [Page 9]

Internet-Draft      multi-domain PKI interoperability          July 2006


                            +---------+
                            | 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 Model

   Trust Anchor

      The trust anchor MUST be root CA.

   Principal CA

      The principal CA MUST be the root CA.

2.3.3.  Mesh PKI

   Definition

      A mesh PKI consists of multiple self-signed CAs that issue
      certificates to EEs and issue peer cross-certificates to each
      other.

      A mesh PKI MAY be a full mesh, where all CAs issue peer 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 peer 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 January 10, 2007               [Page 10]

Internet-Draft      multi-domain PKI interoperability          July 2006


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

   Figure 6: Full Mesh PKI model


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

   Figure 7: Partial Mesh PKI model

   Trust Anchor





Shimaoka, et al.        Expires January 10, 2007               [Page 11]

Internet-Draft      multi-domain PKI interoperability          July 2006


      The trust anchor for a relying party who is issued a certificate
      from a CA in the mesh PKI SHOULD be the CA who issued the
      certificate to the relying party.  The trust anchor for the
      relying party 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, in Figure xxx 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 PKI.  However, the mesh
      PKI MUST have only one principal CA, and a trust path MUST exist
      from the principal CA to every CA within the 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.4.  Hybrid PKI

   Definition

      A hybrid PKI is a PKI that uses a combination of peer cross-
      certificates and subordinate CA certificates to define the CAs
      that are a part of the PKI.

   Trust Anchor

      The trust anchor for a relying party who is issued a certificate
      from a CA in the mesh PKI SHOULD be the CA who issued the
      certificate to the relying party.  The trust anchor for the
      relying party who is not issued a certificate from the mesh PKI
      MAY be any self-signed CA in the PKI.

   Principal CA





Shimaoka, et al.        Expires January 10, 2007               [Page 12]

Internet-Draft      multi-domain PKI interoperability          July 2006


      The principal CA MAY be any CA within the PKI that has a self-
      signed certificate.  However, the hybrid PKI MUST have only one
      principal CA, and a trust 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.







































Shimaoka, et al.        Expires January 10, 2007               [Page 13]

Internet-Draft      multi-domain PKI interoperability          July 2006


3.  Trust Lists

   Relying parties MAY choose to trust multiple PKIs through the use of
   trust lists.  Trust lists can be managed by an individual relying
   party or by a trust authority that is shared by multiple relying
   parties.

   Trust List

      A list of one or more trust anchors used by a relying party to
      explicitly trust a PKI.

   Trust Authority

      An entity that manages a centralized trust list for one or more
      relying parties.

   Figure 8 shows an example of a trust list that contains a simple PKI,
   a hierarchical PKI, and a full mesh PKI.
































Shimaoka, et al.        Expires January 10, 2007               [Page 14]

Internet-Draft      multi-domain PKI interoperability          July 2006


                                   Trust List
        +--------------------------------------------------------------+
        |                         Trust Anchors                        |
        |                                                              |
        | +---------------+ +---------------+ +----------------------+ |
        | |     PKI 1     | |     PKI 2     | |         PKI 3        | |
        | |               | |               | |                      | |
        | |     +----+    | |     +----+    | | +----+               | |
        | |     | CA |    | |     | CA |    | | | CA | <-----+       | |
        | |     +----+    | |     +----+    | | +----+       |       | |
        | |       |       | |       |       | |   ^          |       | |
        +---------|-----------------|-------------|----------|---------+
          |       |       | |       |       | |   |          |       |
          |   +---+--+    | |       v       | |   |          v       |
          |   v      v    | |     +----+    | |   |       +----+     |
          | +----+ +----+ | |     | CA |    | |   |       | CA |     |
          | | EE | | EE | | |     +----+    | |   |       +----+     |
          | +----+ +----+ | |       |       | |   |        ^ |       |
          |               | |   +---+--+    | |   v        | |       |
          +---------------+ |   v      v    | | +----+     | |       |
                            | +----+ +----+ | | | CA | <---+ |       |
                            | | EE | | EE | | | +----+       |       |
                            | +----+ +----+ | |   |          |       |
                            |               | |   |      +---+--+    |
                            +---------------+ |   v      v      v    |
                                              | +----+ +----+ +----+ |
                                              | | EE | | EE | | EE | |
                                              | +----+ +----+ +----+ |
                                              +----------------------+


   Figure 8: Trust List

3.1.  Relying Party Trust List Model

   Any Relying Party MAY choose to trust certificates issued by a PKI by
   installing a trust anchor for that PKI into its local trust list.

   Installing a PKI's trust anchor into a local trust list the is the
   simplest method for relying parties to trust EE certificates issued
   by that PKI.  Using local trust lists does not require cross-
   certification between the PKI that issued the relying party's own
   certificate and the other PKI.  Nor does it require implementing
   mechanisms for processing complex certification paths.  As a result,
   the local trust list model is the most common model in use today.

   Considerations




Shimaoka, et al.        Expires January 10, 2007               [Page 15]

Internet-Draft      multi-domain PKI interoperability          July 2006


      Relying parties who choose to install trust anchors for PKIs that
      they are not also subscribers to do not necessarily create a
      relationship with the PKI.  The relying party may be relying on
      certificates for a purpose that is not supported by the PKI as
      defined in the PKI's certificate policy.  Also, the relying party
      will not be directly informed if the trust anchor's certificate is
      revoked, and so MUST check the PKI's repository to verify the
      status of the trust anchor.  Relying parties MUST be aware of
      these considerations when making a decision to use this model.

      PKIs that are directly installed into relying party trust lists
      MAY choose to cross-certify other PKIs.  Relying parties MUST
      implement appropriate controls to ensure that they do not
      inadvertently trust certificates from cross-certified PKIs that
      they did not intend to trust.  For example:

         Assume certification path X->Y->Z->EE(Z) exists.  When cross-
         certificate X->Y includes pathLenConstraints=1, CA-Z cannot
         extend the certification path started from CA-X by more cross
         certificates.  However, if the relying party trust CA-Y
         directly, the cross certificate constraint in X->Y is ignored
         allowing CA-Z to extend the certification path by more cross
         certificates.  Thus, relying party MUST recognize a risk of
         trusting another CA directly.

      PKIs that intend to support the relying party trust list model
      SHOULD publish their certificate policies so that relying parties
      can determine if their use is supported under the policy.  PKIs
      SHOULD also broadly publicize any revocation of a trust anchor CA
      or the principal CA (email, repository, press release, etc.).

3.2.  Trust Authority Model

   A relying party MAY choose to trust certificates issued by PKIs that
   are themselves trusted by a trust authority.  The trust authority MAY
   manage multiple trust lists for use by different relying parties.  In
   this trust authority model, the trust authority acts as a third party
   broker between relying parties and trusted PKIs.

   There are currently no commercially available products that support
   the trust authority model.  However, this model may be useful when a
   number of relying parties within a community of interest wish to
   centrally manage trusted PKIs and where the PKIs that issue
   certificates to EEs within this community of interest do not
   themselves desire to cross-certify.

   Considerations




Shimaoka, et al.        Expires January 10, 2007               [Page 16]

Internet-Draft      multi-domain PKI interoperability          July 2006


      All of the considerations for the relying party trust list model
      apply to the trust authority model.

      Where possible, trust authorities SHOULD register with the PKIs
      they include in their trust lists so that they can be informed of
      changes in PKI certificate policies or revocation of a trust
      anchor CA or the principal CA.

      Relying parties using trust authorities are relying on the
      accuracy of the trust list as maintained by the trust authority.
      Relying parties MAY also be relying on the trust authority to
      provide revocation information for CA and EE certificates.  As a
      result, trust authorities SHOULD provide information to relying
      parties for how additional trust anchors are added to the trust
      list and what network and other security controls are maintained
      by the trust authority to ensure reliability and accuracy of the
      information provided by the trust anchor.


































Shimaoka, et al.        Expires January 10, 2007               [Page 17]

Internet-Draft      multi-domain PKI interoperability          July 2006


4.  PKI Domain

4.1.  Requirements for PKI domain

4.2.  Risk Analysis of non-interoperable PKI domains

4.3.  Trust Relationship Disclosure Requirements for multi-domain PKIs












































Shimaoka, et al.        Expires January 10, 2007               [Page 18]

Internet-Draft      multi-domain PKI interoperability          July 2006


5.  Abbreviations

   PKI: Public Key Infrastructure

   CA: Certification Authority

   EE: End Entity

   CRL: Certificate Revocation List

   ARL: Authority Revocation List

   PCA: Principal Certification Authority

   RP: Relying Party

   CP: Certificate Policy

   CPS: Certification Practice Statement

   DN: Distinguished Name






























Shimaoka, et al.        Expires January 10, 2007               [Page 19]

Internet-Draft      multi-domain PKI interoperability          July 2006


6.  Security Considerations

   TBD.
















































Shimaoka, et al.        Expires January 10, 2007               [Page 20]

Internet-Draft      multi-domain PKI interoperability          July 2006


7.  IANA Considerations

   This document has no actions for IANA.
















































Shimaoka, et al.        Expires January 10, 2007               [Page 21]

Internet-Draft      multi-domain PKI interoperability          July 2006


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]  Shirey, R., "Internet Security Glossary", RFC 2828, May 2000.

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

   [4]  Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol
        (v3): Technical Specification", RFC 3377, September 2002.

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

8.2.  Informative References

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

   [13]  Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R.
         Nicholas, "Internet X.509 Public Key Infrastructure:



Shimaoka, et al.        Expires January 10, 2007               [Page 22]

Internet-Draft      multi-domain PKI interoperability          July 2006


         Certification Path Building", RFC 4158, September 2005.


















































Shimaoka, et al.        Expires January 10, 2007               [Page 23]

Internet-Draft      multi-domain PKI interoperability          July 2006


Authors' Addresses

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

   Email: shimaoka@secom.ne.jp, 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 January 10, 2007               [Page 24]

Internet-Draft      multi-domain PKI interoperability          July 2006


Intellectual Property Statement

   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.


Disclaimer of Validity

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


Copyright Statement

   Copyright (C) The Internet Society (2006).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Shimaoka, et al.        Expires January 10, 2007               [Page 25]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/