[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
Intended status: Informational                               N. Hastings
Expires: July 10, 2007                                              NIST
                                                              R. Nielsen
                                                     Booz Allen Hamilton
                                                         January 6, 2007


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

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

Copyright Notice

   Copyright (C) The Internet Society (2007).











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

Internet-Draft      multi-domain PKI interoperability       January 2007


Abstract

   This document desires to establish a standard terminology and actual
   language for interoperability of multi-domain PKI that consists of
   several PKI domains which are operated under each distinct policy.
   This document describes the relationships between Certification
   Authorities (CAs), the definition and requirements for PKI domain,
   and typical models of multi-domain PKI.











































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

Internet-Draft      multi-domain PKI interoperability       January 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Objective  . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Document Outline . . . . . . . . . . . . . . . . . . . . .  4
     1.3.  Requirements and Assumptions . . . . . . . . . . . . . . .  4
   2.  Public Key Infrastructure (PKI) Basics . . . . . . . . . . . .  5
     2.1.  Basic Concepts . . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  Relationships Between Certification Authorities  . . . . .  5
       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
   3.  PKI Domain . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     3.1.  PKI domain Properties  . . . . . . . . . . . . . . . . . . 13
     3.2.  Requirements for Establishing and Participating in PKI
           domains  . . . . . . . . . . . . . . . . . . . . . . . . . 13
       3.2.1.  PKI Requirements . . . . . . . . . . . . . . . . . . . 14
       3.2.2.  PKI Domain Documentation . . . . . . . . . . . . . . . 14
       3.2.3.  PKI Domain Membership Notification . . . . . . . . . . 15
       3.2.4.  Considerations for PKIs and PKI Domains with
               Multiple Policies  . . . . . . . . . . . . . . . . . . 16
     3.3.  PKI domain Models  . . . . . . . . . . . . . . . . . . . . 16
       3.3.1.  Unifying Trust Point (Unifying Domain) Model . . . . . 16
       3.3.2.  Independent Trust Point Models . . . . . . . . . . . . 17
     3.4.  Operational Considerations . . . . . . . . . . . . . . . . 20
   4.  Trust Models External to PKI Relationships . . . . . . . . . . 21
     4.1.  Trust List Considerations  . . . . . . . . . . . . . . . . 21
       4.1.1.  Considerations for PKI . . . . . . . . . . . . . . . . 21
       4.1.2.  Considerations for Trust List Owners . . . . . . . . . 21
     4.2.  Trust List Models  . . . . . . . . . . . . . . . . . . . . 22
       4.2.1.  Relying Party Local Trust List Model . . . . . . . . . 22
       4.2.2.  Trust Authority Model  . . . . . . . . . . . . . . . . 22
   5.  Terminologies and Abbreviations  . . . . . . . . . . . . . . . 24
     5.1.  Terminologies  . . . . . . . . . . . . . . . . . . . . . . 24
     5.2.  Abbreviations  . . . . . . . . . . . . . . . . . . . . . . 24
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 26
     6.1.  PKI Domain Models  . . . . . . . . . . . . . . . . . . . . 26
     6.2.  Trust List Models  . . . . . . . . . . . . . . . . . . . . 26
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 28
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 29
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 29
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
   Intellectual Property and Copyright Statements . . . . . . . . . . 32





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

Internet-Draft      multi-domain PKI interoperability       January 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 describes the relevance between each entity, and the
   relationship between especially CAs, for understanding of multi-
   domain PKI.  Section 3 describes the definitions and requirements for
   PKI domain, and also describes the typical models of multi-domain
   PKI.  Although it is not focus on PKI domain because they depend on
   not CA-CA trust relationship but RP-CA relationship, Section 4
   considers the Trust List models.  Section 5 shows the terminologies
   and the abbreviations.

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






















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

Internet-Draft      multi-domain PKI interoperability       January 2007


2.  Public Key Infrastructure (PKI) Basics

2.1.  Basic Concepts

   The following terms defining basic constructs are used throughout
   this document.  Where possible, definitions found in RFC 2828 [3]
   have been used.  Additional terms from RFC 2828 [3] and new terms
   that define relationships between these constructs are introduced and
   defined in later sections.

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

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

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

   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]

2.2.  Relationships Between Certification Authorities

   Certification Authorities (CA) establish trust relationships by
   issuing certificates to other CAs.  CA relationships can be either
   hierarchical or peer-to-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.





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

Internet-Draft      multi-domain PKI interoperability       January 2007


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

   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 MUST not have a self-signed certificate and 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 has
      issued its own self-signed 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 [3], 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:  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 CA Relationships

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












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

Internet-Draft      multi-domain PKI interoperability       January 2007


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

                  Figure 1: Hierarchical CA 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 SHOULD
      not issue certificates to end entities (except those required for
      its own operation) but issues subordinate CA certificates to one
      or more CAs.  A Root CA MUST NOT permit its subordinate CAs to
      issue self-signed certificates.

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




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

Internet-Draft      multi-domain PKI interoperability       January 2007


                  Figure 2: Peer-to-peer CA Relationships

   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) Architectures

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



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

Internet-Draft      multi-domain PKI interoperability       January 2007


   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 MUST have a self-signed certificate, is
      designated as the CA that will issue peer cross-certificates to
      principal CAs in other PKIs, and MAY 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
      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







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

Internet-Draft      multi-domain PKI interoperability       January 2007


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.  The root
      CA MUST have a self-signed certificate and all subordinate CAs
      MUST have subordinate CA certificates, as shown in Figure 5.

   Trust Anchor:  The trust anchor MUST be root CA.

   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 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 July 10, 2007                [Page 10]

Internet-Draft      multi-domain PKI interoperability       January 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 July 10, 2007                [Page 11]

Internet-Draft      multi-domain PKI interoperability       January 2007


   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 a
      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, 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 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 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 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 hybrid PKI MAY be any self-
      signed CA in the PKI.  However, because of the potential
      complexity of a hybrid PKI, the PKI SHOULD provide guidance to
      relying parties regarding the selection of the trust anchor.

   Principal CA:  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 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.






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

Internet-Draft      multi-domain PKI interoperability       January 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
   Certificate Policy 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 CP(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.

   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.

   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.




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

Internet-Draft      multi-domain PKI interoperability       January 2007


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 CP documenting the requirements for operation of that PKI.  The
      CP SHOULD be in RFC 3647 [2] format.

   o  One or more Policy OIDs defined in the CP 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.  Although the
   complexity of this documentation may vary greatly depending on the
   type 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.

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

   Examples of governance documents that PKI Domains MAY choose to use



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

Internet-Draft      multi-domain PKI interoperability       January 2007


   are:

   o  Statement of intent between two or more parties

   o  Memorandum of Agreement between two or more parties

   o  Certificate Policy 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 it's member PKIs
   participate in.  Figure 8 illustrates this concept.

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

              Figure 8: Participation in Multiple PKI Domains

   As shown in Figure 8, 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



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

Internet-Draft      multi-domain PKI interoperability       January 2007


   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 CP 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
   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
   having their common trust anchor or by bridging their principal CAs.

3.3.1.  Unifying Trust Point (Unifying Domain) Model

   The model in which multiple PKI domains have a joint superior CA that
   issues unilateral cross-certificates to each PKI domain, as shown in
   Figure 9.  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.  This model may be used for
   merging multiple PKI domains to single PKI domain with less change to



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

Internet-Draft      multi-domain PKI interoperability       January 2007


   existing PKI domains, or be used for assuming multiple PKI domains as
   one PKI domain to a relying party.  As against the hierarchical PKI
   architecture designed on the assumption that operates under a single
   certificate policy, the unilateral cross-certificate issued by
   unifying CA to the principal CAs in each PKI domain may include any
   policy mapping.

              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 9: Unifying Trust Point (Unifying Domain) Model

3.3.2.  Independent Trust Point Models







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

Internet-Draft      multi-domain PKI interoperability       January 2007


3.3.2.1.  Direct Cross-Certification Model

   ### TBD ###

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

   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 in the policy mapping
      between a prior PKI domain and a posterior PKI domain.

   o  The domain policy of Bridge CA MUST be a subset of the prior PKI
      domain policy that is mapped.

   o  The domain policy of Bridge CA MUST be a superset of the posterior
      PKI domain policy that is mapped.

   o  Bridge CA SHOULD be a neutral position to all PKI domains which
      trust through the Bridge CA, such as the following policy mapping:

         Cross-Certificate from prior PKI domain to Bridge CA:

            issuerDomainPolicy := Prior PKI domain policy

            subjectDomainPolicy := Bridge CA domain policy

         Cross-Certificate from Bridge CA to posterior PKI domain:

            issuerDomainPolicy := Bridge CA domain policy

            subjectDomainPolicy := Posterior PKI domain policy




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

Internet-Draft      multi-domain PKI interoperability       January 2007


   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  Cross-certificate issued by Bridge CA SHOULD NOT include any
      constraints to keep its neutral position, excepting above
      requirement.

   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 such as a
      neutral trusted third party agreed upon by the PKI domains or a
      consortium consisting of the PKI domains.  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 confirm the
      following:

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

      *  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
         prior PKI domain desires?

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










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

Internet-Draft      multi-domain PKI interoperability       January 2007


            cross-certified                 cross-certified
            PKI 1 with BCA   +-----------+  PKI 3 with BCA
                    +------->| Bridge CA |<------+
                    |        +-----------+       |
                    |                 ^          |
                    | cross-certified |          |
                    |  PKI 2 with BCA |          |
                    |                 |          |
        +-----------|---+ +-----------|---+ +----|-----------------+
        |     PKI 1 |   | |     PKI 2 |   | |    |    PKI 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: Multiple Trust Point (Bridge) Model

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 July 10, 2007                [Page 20]

Internet-Draft      multi-domain PKI interoperability       January 2007


4.  Trust Models External to PKI Relationships

   As opposed to PKI Domain trust relationships entered into by PKIs
   themselves, trust across multiple PKIs can be created by entities
   external to the PKIs.  These trust relationships are developed
   through the use of trust lists.

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

4.1.  Trust List Considerations

4.1.1.  Considerations for PKI

   PKIs that intend to support trust lists SHOULD publish their CPs so
   that trust list owners and relying parties can determine if their use
   is supported under the CP.  PKIs SHOULD also broadly publicize any
   revocation of a Trust Anchor CA or Principal CA through notice on
   their web page, press release, or other appropriate mechanisms.

4.1.2.  Considerations for Trust List Owners

   Trust lists can be created without the knowledge of any of the PKIs
   that are included in the list.  As a result, the following
   considerations MUST be taken with regards to the use of trust lists:

   o  A PKI cannot be held responsible for informing the owner of the
      trust list of any changes in the status of that PKI, especially
      with regards to the membership of the PKI in one or more PKI
      Domains.

   o  The owner of a trust list MUST regularly check each PKI's
      repository to verify the status of the trust anchor and the status
      of membership in one or more PKI Domain membership.

   o  The owner of a trust list MUST implement appropriate controls
      within the trust list to prevent inadvertent trust in the event
      that a PKI chooses to join one or more PKI Domains that are
      outside the Trust Anchors in the trust list.

   o  The owner of a trust list SHOULD determine if the intended use of
      certificates issued by PKIs included in the trust list is in
      accordance with the CP of that PKI.  In the event that a CP is not
      available to the owner of the trust list, the owner of the trust
      list SHOULD inform relying parties that use of these certificates
      is entirely at their own risk.





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

Internet-Draft      multi-domain PKI interoperability       January 2007


4.2.  Trust List Models

   Trust lists may be created locally by a single relying party or may
   be operated for the purpose of supporting multiple relying parties.

4.2.1.  Relying Party Local Trust List Model

   Any relying party MAY choose to trust certificates issued by any PKI
   by installing a trust anchor for that PKI into its local trust list.
   Figure 11 illustrates a trust list within a relying party
   application.

                   +-----------------------------------+
                   | RP                                |
                   | +------------------------------+  |
                   | | TRUST LIST                   |  |
                   | | +------+  +------+  +------+ |  |
                   | | | PKI1 |  | PKI2 |  | PKI3 | |  |
                   | | +------+  +------+  +------+ |  |
                   | +------------------------------+  |
                   +-----------------------------------+

              Figure 11: Relying Party Local Trust List Model

   Installing a PKI's trust anchor into a local trust list 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 PKI that issued the EE's certificate.  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.

4.2.2.  Trust Authority Model

   Instead of each relying party managing their own trust list, an
   entity may choose to establish a trust list that can be accessed by
   multiple relying parties, known as a trust authority.

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

   A Trust Authority may be operated by a PKI, or may be operated by an
   independent entity.  Figure 12 illustrates a Trust Authority.  Note
   that the Trust Authority replaces the PKIs as the trust anchor for
   each participating relying party.





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

Internet-Draft      multi-domain PKI interoperability       January 2007


                    +-----------------------------------+
                    | Trust Authority                   |
                    | +------------------------------+  |
                    | | TRUST LIST                   |  |
                    | | +------+  +------+  +------+ |  |
                    | | | PKI1 |  | PKI2 |  | PKI3 | |  |
                    | | +------+  +------+  +------+ |  |
                    | +------------------------------+  |
                    +-----------------------------------+

                  +-----------------+  +-----------------+
                  | RP1             |  | RP2             |
                  | +------------+  |  | +------------+  |
                  | | TRUST LIST |  |  | | TRUST LIST |  |
                  | | +----+     |  |  | | +----+     |  |
                  | | | TA |     |  |  | | | TA |     |  |
                  | | +----+     |  |  | | +----+     |  |
                  | +------------+  |  | +------------+  |
                  +-----------------+  +-----------------+

                     Figure 12: Trust Authority Model

   Because a trust authority is a centralized entity that will be used
   by multiple relying parties, the following additional considerations
   apply:

   o  Trust authorities SHOULD register with the PKIs they include in
      their trust lists so that they can be informed of changes in CPs,
      changes in PKI Domain membership, or revocation of a trust anchor
      CA or the principal CA.

   o  Trust authorities SHOULD provide information to their relying
      parties for how and when trust anchors are added or removed from
      its trust list.

   o  Since trust authorities replace CA certificates as the trust
      anchor for their relying parties, the trust authority MUST be
      operated to an acceptable level of assurance for its relying
      parties.  Unless the trust authority is itself operated by the
      relying parties, it MUST provide information to its relying
      parties regarding its own operations.










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

Internet-Draft      multi-domain PKI interoperability       January 2007


5.  Terminologies and Abbreviations

5.1.  Terminologies

   ### any comments? ###

   Domain Policy:  Domain Policy is a common certificate policy (Object
      Identifier) that is shared in a PKI domain.  Each CAs in the PKI
      domain MUST be operated under the domain policy at least.  Each
      CAs is able to have another policy for itself in addition to the
      domain policy.  In such a case, the CAs MUST comply with both
      policies.  The policy OID of the domain policy is used to
      distinguish the PKI domain from another.

   Posterior PKI domain:  This term is used to describe the relative
      trust relationship of adjoined PKI domains in the certification
      path and is used in combination with the term "prior PKI domain".
      The next trusted PKI domain(s) in the certification path from the
      trust anchor to the target certificate is called the posterior PKI
      domain.  That is, the posterior PKI domain is trusted from the
      prior PKI domain.

   Prior PKI domain:  This term is used to describe the relative trust
      relationship of adjoined PKI domains in the certification path and
      is used in combination with the term "posterior PKI domain".  The
      previous PKI domain in the certification path from the trust
      anchor to the target certificate is called the prior PKI domain.
      That is, the prior PKI domain trusts the posterior PKI domain.
      First prior PKI domain in the certification path is the PKI domain
      trusted directly by a relying party.

5.2.  Abbreviations

   PKI:  Public Key Infrastructure

   CA:  Certification Authority

   EE:  End Entity

   CRL:  Certificate Revocation List

   ARL:  Authority Revocation List

   PCA:  Principal Certification Authority







Shimaoka, et al.          Expires July 10, 2007                [Page 24]

Internet-Draft      multi-domain PKI interoperability       January 2007


   RP:  Relying Party

   CP:  Certificate Policy

   CPS:  Certification Practice Statement

   DN:  Distinguished Name












































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

Internet-Draft      multi-domain PKI interoperability       January 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, detailed security considerations
   are not applicable.  However, a high level discussion of applicable
   security considerations is warranted.

   As certificates are generally considered public, confidentiality and
   eavesdropping are not applicable to this RFC.  Replay attacks are
   also not applicable as the creation and maintenance of a PKI or a PKI
   domain does not involve actions that can be replayed.

6.1.  PKI Domain Models

   For all PKI domain models 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.

6.2.  Trust List Models

   Additional security considerations apply when trust is created
   through trust lists.  In these models, a relying party or a trust
   anchor creates a trust domain by directly trusting one or more PKIs.
   Since certificates are digitally signed, many standard attacks are
   not applicable.




Shimaoka, et al.          Expires July 10, 2007                [Page 26]

Internet-Draft      multi-domain PKI interoperability       January 2007


   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 authenticated.  To prevent this
   attack, access to trust lists MUST be adequately protected against
   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 anchor 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 anchor providers.  In addition, applications MAY choose to
   locally cache the list of CAs maintained by the trust anchor as a
   backup in the even that the trust anchor is not available.


































Shimaoka, et al.          Expires July 10, 2007                [Page 27]

Internet-Draft      multi-domain PKI interoperability       January 2007


7.  IANA Considerations

   This document has no actions for IANA.
















































Shimaoka, et al.          Expires July 10, 2007                [Page 28]

Internet-Draft      multi-domain PKI interoperability       January 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]  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.

   [3]  Shirey, R., "Internet Security Glossary", RFC 2828, May 2000.

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

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

   [6]  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

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

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

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

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

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

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

   [13]  Japan PKI Forum, Korea PKI Forum, and PKI Forum Singapore,



Shimaoka, et al.          Expires July 10, 2007                [Page 29]

Internet-Draft      multi-domain PKI interoperability       January 2007


         "Achieving PKI Interoperability", April 2002.

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

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











































Shimaoka, et al.          Expires July 10, 2007                [Page 30]

Internet-Draft      multi-domain PKI interoperability       January 2007


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 July 10, 2007                [Page 31]

Internet-Draft      multi-domain PKI interoperability       January 2007


Full Copyright Statement

   Copyright (C) The Internet Society (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 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 July 10, 2007                [Page 32]


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