[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
Request for Comments: DRAFT                                        SECOM
<draft-shimaoka-multidomain-pki-06.txt>                      N. Hastings
                                                                    NIST
                                                              R. Nielsen
                                                     Booz Allen Hamilton
                                                            January 2006


                      Memorandum for multi-domain
            Public Key Infrastructure (PKI) Interoperability


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/1id-abstracts.html

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

   This Internet-Draft will expire on July 12, 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.
   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



Shimaoka, et al.                                                [Page 1]

INTERNET DRAFT                                              January 2006


   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
   2  Requirements and Assumptions    . . . . . . . . . . . . . . . .  4
   2.1  Abbreviations . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.2  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.3  Assumptions . . . . . . . . . . . . . . . . . . . . . . . . .  8
   3  Trust Relationship  . . . . . . . . . . . . . . . . . . . . . .  8
   3.1  Operation based Trust Relationship  . . . . . . . . . . . . .  9
   3.1.1  User Trust List model . . . . . . . . . . . . . . . . . . . 10
   3.1.2  Authority Trust List model  . . . . . . . . . . . . . . . . 10
   3.2  Certificate based Trust Relationship  . . . . . . . . . . . . 11
   3.2.1  Unilateral Cross-Certification  . . . . . . . . . . . . . . 12
   3.2.2  Mutual Cross-Certification  . . . . . . . . . . . . . . . . 13
   3.3  Subordination (Hierarchy) . . . . . . . . . . . . . . . . . . 14
   4  PKI Domain  . . . . . . . . . . . . . . . . . . . . . . . . . . 16
   4.1  Requirements for PKI domain . . . . . . . . . . . . . . . . . 16
   4.2  Risk Analysis of non-interoperable PKI domains  . . . . . . . 16
   4.3  Trust Relationship Disclosure Requirements
        for multi-domain PKIs  . . . . . . . . . . . . . . . . . . 17
   5  Single-domain PKI . . . . . . . . . . . . . . . . . . . . . . . 18
   5.1  Single CA PKI model . . . . . . . . . . . . . . . . . . . . . 18
   5.2  Hierarchy PKI model . . . . . . . . . . . . . . . . . . . . . 19
   5.3  Mesh PKI model  . . . . . . . . . . . . . . . . . . . . . . . 19
   6  multi-domain PKI  . . . . . . . . . . . . . . . . . . . . . . . 21
   6.1  Multi Trust point model . . . . . . . . . . . . . . . . . . . 21
   6.1.1  Based on User Trust List  . . . . . . . . . . . . . . . . . 22
   6.1.2  Based on Authority Trust List . . . . . . . . . . . . . . . 22
   6.2  Single Trust Point model  . . . . . . . . . . . . . . . . . . 22
   6.2.1  Unified Domain model  . . . . . . . . . . . . . . . . . . . 22
   6.2.2  Bridge model  . . . . . . . . . . . . . . . . . . . . . . . 23
   7  Operational Considerations  . . . . . .  .  . . . . . . . . . . 26
   7.1  Directory . . . . . . . . . . . . . . . . . . . . . . . . . . 26
   7.2  Cross-Certification . . . . . . . . . . . . . . . . . . . . . 27
   7.3  Providing Directory Information Across PKI-domains  . . . . . 28
   8  Security Considerations . . . . . . . .  .  . . . . . . . . . . 28
   8.1  Certificate and CRL Profile . . . . . . . . . . . . . . . . . 28
   8.2  Path Validation . . . . . . . . . . . . . . . . . . . . . . . 29
   8.3  Asymmetric problem  . . . . . . . . . . . . . . . . . . . . . 29
   8.3.1  Hybrid trust model  . . . . . . . . . . . . . . . . . . . . 29
   8.3.2  Asymmetric policy mapping . . . . . . . . . . . . . . . . . 29
   9  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 30



Shimaoka, et al.                                                [Page 2]

INTERNET DRAFT                                              January 2006


   9.1  Normative References  . . . . . . . . . . . . . . . . . . . . 30
   9.2  Informative References  . . . . . . . . . . . . . . . . . . . 30
   10  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
   11 Author's Address  . . . . . . . . . . . . . . . . . . . . . . . 31
   12  Full Copyright Statement . . . . . . . . . . . . . . . . . . . 32

1  Introduction

   PKIs are extendable to realize various architectures, through the way
   in which CAs establish trust relationships with each other.  When a
   CA wishes to establish a trust relationship with another CA, the CAs
   MUST compare the security requirements defined in their certificate
   policies since certificate policies vary greatly across CAs.  Those
   CAs should choose an appropriate trust relationship which satisfies
   both security requirements, as a result of that comparison.  To
   establish appropriate trust relationships, a complete understanding
   of the relationship between the establishment method and a comparison
   of security requirements in each certificate policies is required.
   In addition, all trust relationships fall into the operation based
   one or the certificate based one.  In the multi-domain PKI they are
   called the multi trust point model and the single trust point model.
   In order to establish trust relationships between CAs, technology,
   such as protocol specifications and data formats, alone is
   insufficient.  The existing protocol specifications and data formats
   do not define the PKI architectures and boundary of the PKI domains
   and do leave those decisions up to the designers of specific PKIs.
   Therefore, an understanding of the CAs' PKI architectures and domains
   are required to determine the appropriateness of establishing the
   trust relationship.  This document clarifies the definition of PKI
   domain and its trust relationships for the multi-domain PKI
   interoperability.

   Section 2 describes the terminology necessary to consider multi-
   domain PKI.  Section 3 categorizes the trust relationships between
   CAs as Trust List, Cross-Certification, and Subordination.  Section 4
   defines a PKI domain and requirements for multi-domain
   interoperability.  Section 5 defines major models necessary to
   establish single-domain PKIs.  Section 6 profiles multi-domain PKIs
   as multi-trust point model and single-trust point model.  Multi-trust
   point model is based on trust list model.  Single-trust point model
   is based on the cross-certification model, and is categorized as peer
   model, unified domain model and hub model.  Finally, section 7
   describes considerations focused on Certificate and Certificate
   Revocation List (CRL) profiles, Repositories, and path validation.

     +------------------+               +-------------------+
     |    PKI domain    |               |     PKI domain    |
     |                  | Domain-Domain |                   |



Shimaoka, et al.                                                [Page 3]

INTERNET DRAFT                                              January 2006


     |                  |    Trust      |                   |
     | +-----+          | Relationship  |  +-----+          |
     | | PCA |<===========================>| PCA |          |
     | +-----+          |               |  +-----+          |
     |   ^              |               |    ^              |
     |   | CA-CA Trust  |               |    | CA-CA Trust  |
     |   | Relationship |               |    | Relationship |
     |   v              |               |    v              |
     | +----+           |               |  +----+           |
     | | CA |           |               |  | CA |           |
     | +----+           |               |  +----+           |
     +------------------+               +-------------------+

                Figure 1 - Structure of multi-domain PKI

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

2.1  Abbreviations

   ARL: Authority Revocation List

   CA: Certification Authority

   CP: Certification Policy

   CPS: Certification Practice Statement

   CRL: Certificate Revocation List

   DN: Distinguished Name

   EE: End Entity

   PCA: Principal Certificate Authority

   PKI: Public Key Infrastructure

   RP: Relying Party

2.2  Terminology

   CA-CA Trust Relationship

     ### TBD ###



Shimaoka, et al.                                                [Page 4]

INTERNET DRAFT                                              January 2006


   Cross-Certification

     Cross-certification is a mechanism to recognize the existence of a
     subject CA.  The recognition of the existence means issuing a
     certificate called cross-certificate to a CA who has another
     certificate already.  In this document, this wording is more
     broader than the definition in RFC 2828.  That is, cross-
     certification in RFC 2828 means mutual cross-certification, but
     cross-certification in this document allows unilateral cross-
     certification.

   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.

   EE-CA Trust Relationship

     ### TBD ###

   End Entity (EE)

     The preferred definition of EE is based on the X.509 4th edition
     definition instead of that found in RFC 2828, since it includes
     relying parties and not just subjects of certificates as EEs.  That
     is, a certificate subject that uses its private key for purposes
     other than signing certificates or an entity that is a relying
     party [sic].

   Intermediate Certificate

     Certificates in a certification path except the trust anchor
     certificate and the certificate being validated.

   Irresponsible EE

     Relying party who is not issued a certificate from a certain CA,
     and is irresponsible for that CA.

   Multi-domain PKI

     A set of PKI domains which interoperate each other.




Shimaoka, et al.                                                [Page 5]

INTERNET DRAFT                                              January 2006


   PKI

     In this document, this wording is more limited than the definition
     in RFC 2828.  PKI in this document means a minimal system operated
     under unique policy.

   PKI domain

     PKI domain can consist of a set of CAs which are possibly operated
     by different organizations under shared CP even though each of them
     may have additional CPs that differ.

   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.

   Principal CA

     CA which has a self-signed certificate and is trusted from the
     other PKI domain.  The reason why a principal CA has a self-signed
     certificate is the principal CA must be independent from all other
     certification including inside of its 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.

   Relying Party (RP)

     Entity who trusts a trust anchor and may not be issued the
     certificates.

   Responsible EE

     Relying party who is issued a certificate from a certain CA, and is
     responsible for that CA.



Shimaoka, et al.                                                [Page 6]

INTERNET DRAFT                                              January 2006


   Subordination

     Subordination is a mechanism to authorize the existence of a
     subject CA.  The authorization of the existence means issuing a
     certificate called subordinate (CA) certificate to a CA who has no
     certificate.

   Subscriber

     This is an equivalent term with the responsible EE.

   Subscriber Agreement

     A document used to describe the rights, obligations, and
     responsibilities of a subscriber to a PKI. This may take the form
     of a contract.

   Top CA

     Only CA that is a root in Hierarchy PKI model.  Top CA MUST issue a
     self-signed certificate.  Top CA SHOULD be used for Hierarchy PKI
     model.  For a unified domain model, a unificate CA SHOULD be used
     as defined later in this section.

   Trust Anchor

     Starting point of a certification path specified by a relying
     party.  Relying party SHOULD specify the CA which has self-signed
     certificate as a trust anchor.  In this document, Top CA is used as
     a trust anchor only for Hierarchical PKI.  There may not be Top CA
     in the other trust models.

   Trust List

     Trust list is a list of one or more trust anchors, which MAY be a
     set of the trust anchor certificates in general.  Otherwise, it MAY
     be a set of public keys or Distinguished Names.  Trust list is used
     for specifying a trust anchor by a relying party.

   Trust Relationship

     This word is used for two purposes.  One is the "CA-CA trust
     relationship" which is used for the relationship between CAs.
     Another one is the "EE-CA trust relationship" which is used for the
     relationship between CA and relying parties.

   Validation policy




Shimaoka, et al.                                                [Page 7]

INTERNET DRAFT                                              January 2006


     The concept of this is defined in RFC 3379. In this document, the
     items which should be focused on are the following.
        (c) user-initial-policy-set
        (d) trust anchor information,
        (e) initial-policy-mapping-inhibit
        (f) initial-explicit-policy
        (g) initial-any-policy-inhibit
     These are parts of input for the path validation, which is defined
     in RFC 3280 section 6.1.1.  The reason why this document focuses on
     these items is that these values may be different depending on each
     trust anchor.

   Unificate CA

     CA which has a self-signed certificate and issues unilateral cross-
     certificates to each principal CA of other posterior PKI domains.
     Unificate CA is specified as a trust anchor for the PKI domains
     that are cross-certified with it.

2.3  Assumptions

   In this document, each PKI MUST have a repository for supporting the
   path validation, but this document does not specify whether the
   repository is web server or directory server.

3  Trust Relationship

   This section describes major trust relationships for multiple PKI
   (CA) interconnections.  All PKIs that are going to participate in
   multi-domain PKI SHOULD use these trust relationships for multi-
   domain PKI interoperability.

3.1 Operation based Trust Relationship

   Definition

     Trust List is defined in terminology section 2.2.

   Requirements

     CAs on the same trust list SHOULD NOT cross-certify each other.
     All relying parties in this model MUST have a trust list.  Since
     there should be different policies for every trust anchors whether
     operated by the same body or not, there SHOULD be different
     validation policies for every trust anchors.

   Considerations




Shimaoka, et al.                                                [Page 8]

INTERNET DRAFT                                              January 2006


     A relying party using the trust list MAY trust multiple trust
     anchors, but finding out a revocation of each trust anchor is more
     difficult than finding out it for one.

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

                      Figure 2 - Trust List model

3.1.1  User Trust List model

   Definition

     The model in which a trust list is managed by End Entities (EEs).
     Each EE is able to have its own user trust list.


   Characteristics

     EE is able to manage its own user trust list.  EE is able to add or
     delete a trust anchor from its own user trust list.  This is easier



Shimaoka, et al.                                                [Page 9]

INTERNET DRAFT                                              January 2006


     than cross-certification and is typical method for making a trust
     relationship with another PKI.

     Except for EE itself, no one is able to control the trust
     relationship.  There is a risk that the EE trusts unknown PKI
     domain irresponsibly.  If the EE trusts unknown PKI domains
     irresponsibly, then the issuer CA cannot apply its CP to the EE.  A
     trust anchor MAY not apply its validation policy to the EE.

   Considerations

     EE MUST update its own user trust list when the status of CA which
     is included in the trust list changes, such as revocation or
     updating.

3.1.2  Authority Trust List model

   Definition

     The model in which a trust list is managed by the trust authority,
     which manages the trust anchors that are to be used by a relying
     party.  The trust authority MAY issue multiple trust lists for some
     purposes or parties.  EEs trusting the same trust authority may
     share the authority trust list given by the trust authority.

   Characteristics

     EE does not have control over any trust relationships from its
     trust anchor.  Trust anchor SHOULD control an appropriate trust
     relationship with other CAs keeping the same security level.

   Considerations

     Since there is no standard for the use of this model, management
     methods for authority trust list are not established.  In
     generally, this model MAY not achieve sufficient interoperability.

3.2  Certificate based Trust Relationship

   Certificate based trust relationship is realized by the cross-
   certification unilaterally or mutually.

   Definition

     Cross-certification is defined in terminology section 2.2.

   Requirement




Shimaoka, et al.                                               [Page 10]

INTERNET DRAFT                                              January 2006


     A subject CA in the cross-certification MUST have a self-signed
     certificate.

   Characteristics

     Cross-Certification is a more formal expression of the trust
     relationship than the trust list model, because the trust
     relationship is represented by a certificate, (authority)
     revocation list, and is recorded to an audit log.  Cross-
     certification is able to manage the trust relationship without
     changing the trust list of EEs.  Because all subject CAs have a
     self-signed certificate, revoking a cross-certificate does not
     always mean also compromising the subject CA.

     A PKI which issues a cross-certificate SHOULD have a repository.
     The issuing CA SHOULD publish the cross-certificate in the
     repository for relying parties.  In general, the cross-certificate
     is populated to the crossCertificatePair attribute of a repository
     such as a LDAP or X.500 directory server.  At minimum, a PKI which
     issues a cross-certificate MUST provide a mechanism for obtaining
     the cross-certificate to a relying party, like a caIssuers in
     accessMethod of the AIA extension.

   Considerations

     When a subject CA does not have a self-signed certificate, such
     subject CA is established by another CA issuing the cross-
     certificate to the subject CA.  This, however, means the issuer CA
     of the cross-certificate may not be able to recognize the existence
     of the subject CA because the issuer CA may not have a formal
     agreement or contract to the establishing CA.  Therefore, this
     document strongly recommends that a subject CA SHOULD have a self-
     signed certificate.

     Especially for the inter-domain cross-certification, this document
     recommends that issuer CA SHOULD accept and agree on the way the
     subject CA is operated.

     For path construction

        Because the key identifier of each CA MAY be calculated
        differently, subject CA SHOULD issue a cross-certification
        request that contains subjectKeyIdentifier in extensionRequest,
        with a value that MUST be identical to the subjectKeyIdentifier
        in the self-signed certificate.  Then, issuer CA SHOULD issue a
        cross-certificate with the subjectKeyIdentifier set to the same
        value in the corresponding cross-certification request.




Shimaoka, et al.                                               [Page 11]

INTERNET DRAFT                                              January 2006


     For PKI issuing Revocation List

        Issuing CAs MAY issue Authority Revocation Lists (ARLs), or
        SHOULD at least issue full CRLs.  However, ARL with an
        issuingDistributionPoint extension MAY NOT be processed by some
        applications.

3.2.1  Unilateral cross-certification

   Definition

     The model in which a CA issues a cross-certificate unilaterally to
     another CA which has a self-signed certificate.

   Characteristics

     This certification is used like subordination, but is able to
     establish a more flexible trust relationship than
     subordination.(See 3.2.3) Even if the cross-certificate is revoked,
     subject CA MAY be able to continue its operation.

     If the PKI uses a directory system, the CA MUST publish a
     crossCertificatePair, even when the cross-certification is
     unilateral, to avoid being categorized as subordination.

   Considerations

     Subordination is a special case of unilateral cross-certification.
     Note that unilateral cross-certification is easily established
     without an agreement from the subject CA because a cross-
     certificate can be issued from the public key of the subject CA.

     In the example of figure 3 below, RPs who use the PCA of PKI 1 as
     the trust anchor can trust EEs of PKI 2 as well as EEs of PKI 1.
     But RPs who use the PCA of PKI 2 as the trust anchor cannot trust
     EEs of PKI 1.  This configuration illustrates helping RPs who use
     the PCA of PKI 1 to interoperate with EEs of PKI 2, but not vice
     versa.

        +---------------+                 +----------------------+
        |     PKI 1     |                 |         PKI 2        |
        |               | cross-certified |                      |
        | +-----+       | PKI 1 to PKI 2  |  +-----+             |
        | | PCA |--------------------------->| PCA |<--+         |
        | +-----+       |                 |  +-----+   |         |
        |    |          |                 |    ^       |         |
        |    |          |                 |    |       v         |
        |    |          |                 |    |    +----+       |



Shimaoka, et al.                                               [Page 12]

INTERNET DRAFT                                              January 2006


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

               Figure 3 - Unilateral Cross-Certification

3.2.2  Mutual cross-certification

   Definition

     The model in which two self-signed CAs issue cross-certificates to
     each other.

   Characteristics

     Both CAs cross-certify with each other mutually.

     Both CAs MUST generate a crossCertificatePair that consists of the
     cross-certificate it issued to the other CA and the corresponding
     cross-certificate that it was issued by the other CA.  When either
     CA updates a cross-certificate, each CA MUST re-generate their
     crossCertificatePair synchronously.

     If re-generating asynchronously, the result of the path validation
     may differ by the method of path building, such as forward path
     building and reverse path building.

   Considerations

     Both CAs MUST agree and accept more information in order to issue a
     cross-certificate (e.g., validity, keyUsage, and constraints) and
     MUST exchange the information and place these in the directory
     system.

        +---------------+                 +----------------------+
        |     PKI 1     |                 |         PKI 2        |
        |               | cross-certified |                      |



Shimaoka, et al.                                               [Page 13]

INTERNET DRAFT                                              January 2006


        | +-----+       | PKI 1 and PKI 2 |  +-----+             |
        | | PCA |<-------------------------->| PCA |<--+         |
        | +-----+       |                 |  +-----+   |         |
        |    |          |                 |    ^       |         |
        |    |          |                 |    |       v         |
        |    |          |                 |    |    +----+       |
        |    |          |                 |    |    | CA |---+   |
        |    |          |                 |    |    +----+   |   |
        |    |          |                 |    |     ^ |     |   |
        |    v          |                 |    v     | |     |   |
        | +----+        |                 | +----+   | |     |   |
        | | CA |---+    |                 | | CA |---+ |     |   |
        | +----+   |    |                 | +----+     |     |   |
        |   |      |    |                 |   |        |     |   |
        |   |      |    |                 |   |        |     |   |
        |   v      v    |                 |   v        v     v   |
        | +----+ +----+ |                 | +----+ +----+ +----+ |
        | | EE | | EE | |                 | | EE | | EE | | EE | |
        | +----+ +----+ |                 | +----+ +----+ +----+ |
        +---------------+                 +----------------------+

                 Figure 4 - Mutual Cross-Certification

3.3  Subordination (Hierarchy)

   Subordination is a special subset of unilateral cross-certification.

   Definition

     The model in which a CA issues a certificate to a CA which has no
     self-signed certificate.  The model in which a PKI always has only
     one root CA.

   Requirements

     A subordinate CA MUST have only one superior CA and be managed by
     the superior CA strictly.  A subordinate CA MUST never issue its
     self-signed certificate.

   Characteristics

     EEs can trust all subordinate CAs and their EEs by trusting only
     the root CA.  Subordination is different from unilateral cross-
     certification, in that the subordination model MUST NOT allow a
     subordinate CA to be issued a certificate by more than one issuer
     CAs.  A subordinate CA MAY NOT necessarily require an
     accreditation, such as WebTrust or license under the e-signature
     law.  The accreditation is rather required only for the superior CA



Shimaoka, et al.                                               [Page 14]

INTERNET DRAFT                                              January 2006


     or the root CA.  Although a full third party accreditation of the
     subordinate CA is not required, it is the responsibility of the
     superior or root CA to ensure it issues CA certificates only to CAs
     that operate under its accredited policies and procedures.  In this
     case, accreditation means that the subordinate CA can inherit the
     benefit of the trustworthiness of the superior CA.  An existence of
     the subordinate CA is dependent on the superior CA.  The
     subordinate CA is dependent on the superior CA for its existing.  A
     subordinate CA is able to inherit some policies and constraints
     from its superior CA.  Because a subordinate CA has an explicit
     trust relationship with its superior CA, the subordinate CA is able
     to be trusted easily by all EEs who trust the superior CA.

     Subordinate CAs MUST NOT cross-certify with another PKI domain, but
     MAY just allow a subordination within the same PKI domain.  When a
     subordinate CA certificate is revoked by a superior CA, all
     certificates issued by the subordinate CA are also invalid.

   Considerations

     A subordinate CA MUST NOT override the constraints given by the
     superior CA.  Subordination MUST be used only in single-domain PKI,
     not multi-domain PKI.

     The violation with issuing a self-signed certificate to a
     subordinate CA may be considered as the following two cases.  If
     the subordinate CA issues a self-signed certificate, and if RPs
     change their trust anchor from the original root CA to the former
     subordinate CA, the entities which the RPs can trust will shrink to
     only under the former subordinate CA.

     If the subordinate CA issues a self-signed certificate, but if RPs
     do not change their trust anchor (original root CA), the entities
     which the RPs can trust will still be same but the trust
     relationship will change from the subordination model into the
     unified domain model as described in section 6.2.2.

4  PKI Domain
4.1  Requirements for PKI domain

   PKIs in a PKI domain SHOULD share a common "domain policy" consisting
   of one or more CPs.  The CPs of the domain policy SHOULD be populated
   in the certificate policies extension for each certificate.  The PKI
   domain MUST have at least one principal CA that can be trusted by
   other PKI domains.  The PKI domain MUST have a mechanism to propagate
   certificate status information to other PKI domains.  The PKI domain
   SHOULD agree to a minimum common certificate profile.




Shimaoka, et al.                                               [Page 15]

INTERNET DRAFT                                              January 2006


   All CAs in a PKI domain MUST be operated under a CPS that conforms to
   the domain policy.  All CAs in a PKI domain MUST be able to issue a
   certificate under including a valid CP of the domain policy.

4.2  Risk Analysis of non-interoperable PKI domains

   A PKI domain that satisfies the requirements presented in section 4.1
   of this document MAY be used in the multi-trust or single-trust point
   model.  However when one PKI domain interconnects with another PKI
   domain, the following items need to be considered to reduce the risk
   of being non-interoperable:

     - Namespace Conflicts

        A PKI domain SHOULD agree to use namespaces that do not overlap.
        If the PKI domain namespaces overlap, a namespace conflict
        occurs resulting in the name constraints extension possibly not
        being able to perform the specified name constraint as intended.

     - PKI Domain Policy in Certificates

        CAs of PKI domains SHOULD populate the certificate policy
        extension with the PKI domain policy.  If the PKI domain policy
        is not described in the certificate policies extension, the path
        validation MAY fail when the relying parties use the certificate
        policies extension to identify the PKI domain.  The PKI domain
        policy is necessary in path validation through the PKI domains
        that use policy constraints or policy mapping.

     - Certificate Authority Certification Path Constraints

        A CA that wants to assert constraints for the certification path
        MUST explicitly include the extensions for the constraints in
        the certificates that the CA issues, since that CA assumes the
        validation policy used by a relying party which MAY NOT be under
        the CA's control.  By explicitly including the constraints in
        certificates, a certification path that otherwise would validate
        will fail, regardless of a relying party's path validation
        settings or configuration.

        For example; Assume the CA-X expects its RPs to evaluate an
        appropriate CP in the path validation.  Even if CA-X expects its
        RP to set the initial-explicit-policy flag to TRUE, there is no
        guarantee that RP sets the flag to TRUE because there are
        responsible EEs and irresponsible EEs.  A responsible EE may set
        the flag to TRUE, but an irresponsible EE may not.  Therefore,
        CA-X SHOULD issue a certificate which uses requireExplicitPolicy
        explicitly in the policyConstraints extension.  If CA-X issues



Shimaoka, et al.                                               [Page 16]

INTERNET DRAFT                                              January 2006


        all certificates which use requireExplicitPolicy in the
        policyConstraints extension, RP MUST evaluate the CP whether it
        has responsibility or not.

     - End Entity Certification Path Constraints

        Some PKI domains that require an explicit policy MAY NOT assert
        the requiredExplicitPolicy constraint in certificates they
        issue.  These PKI domains assume the relying parties will
        configure their validation policy appropriately.  A PKI domain
        requiring an explicit domain policy SHOULD set the following
        validation policy for its end entities:
          * user-initial-policy-set which includes its own domain policy
          OID.
          * initial-explicit-policy set to TRUE.
          * trust anchor which is the principal CA of its PKI domain.

     - Distribution of Certificate and Certificate Status Information

        A PKI domain SHOULD make certificate and certificate revocation
        lists (CRLs) available using LDAP or HTTP.  This provides the
        ability for other certificate status protocols such as OCSP and
        SCVP to be implemented without requiring the PKI domain
        providing the certificates and CRLS to implement the protocol.
        If certificate and certificate status information is not made
        available by a PKI domain, certification paths passing through
        that PKI domain MAY not be constructed and validated.

4.3  Trust Relationship Disclosure Requirements for multi-domain PKIs

   For any multi-domain PKI model, each PKI domain SHOULD show the trust
   relationship(s) it has with other PKI domains as follows:

     * Posterior PKI domain X SHOULD show its PKI architecture to the
     prior PKI domain Y, because the trust relationship from the PKI
     domain Y to the PKI domain X MAY depend on such PKI architecture.
     * Posterior PKI domain X SHOULD show all PKI domains that it trusts
     to the prior PKI domain Y, because the prior PKI domain Y MUST NOT
     trust an unnecessary PKI domain.
     * Posterior PKI domain X MAY publish what PKI domains it is trusted
     by to prior PKI domain Y, because PKI domain Y MAY consider the
     other certification paths to PKI domain X.

   In addition, a PKI domain SHOULD give the appropriate policy mappings
   between the prior PKI domains and the posterior PKI domains for
   certificate based trust relationship.

5  Single-domain PKI



Shimaoka, et al.                                               [Page 17]

INTERNET DRAFT                                              January 2006


   This section describes the appropriate PKI architectures for
   establishing a single PKI domain.  All PKIs that are going to
   participate in multi-domain PKI SHOULD adopt any of the following
   models for multi-domain PKI interoperability.

5.1  Single CA PKI model

   This is the simplest PKI model which is a special case of a
   hierarchical PKI which has no subordinate CAs.  All PKIs in this
   model are composed using this building block of a CA and its EE.

   Definition

     Single PKI consists of a single self-signed CA and its EEs.  All
     EEs MUST be issued their certificates by the only CA.

   Trust anchor

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

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

                      Figure 5 - Single PKI model

5.2  Hierarchy PKI model

   This is a typical architecture of PKI.

   Definition

     Hierarchy PKI consists of a single root CA, a number of subordinate
     CAs, and EEs.  Only the root CA MUST issue a self-signed
     certificate.  All subordinate CAs MUST have only one superior CA.

   Trust anchor

     Trust anchor MUST be the root CA.  All EEs SHOULD trust only the
     root CA.

                            +---------+



Shimaoka, et al.                                               [Page 18]

INTERNET DRAFT                                              January 2006


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

                     Figure 6 - Hierarchy PKI model

5.3  Mesh PKI model

   Definition

     Mesh PKI consists of multiple CAs and their EEs.  All CAs MUST be
     cross-certified with more than one CA unilaterally.  Some CAs MAY
     cross-certify mutually.

   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
     CA in the mesh PKI.

   Considerations

     A trust anchor which does not have a self-signed certificate is
     authorized by another CA.  In such a case, the relying parties may
     not recognize the revocation of the CA even if the issuing CA
     publishes the revocation information about that CA.  Therefore,
     this document recommends that relying party SHOULD only trust other
     self-signed CAs.  If there is no self-signed CA in that mesh, i.e.
     all CAs in the mesh certify with each other, the relying parties
     SHOULD choose a trust anchor from those CAs carefully.  For



Shimaoka, et al.                                               [Page 19]

INTERNET DRAFT                                              January 2006


     example, a relying party may choose a CA that is highly unlikely to
     be revoked.

     This model SHOULD be used sparingly, because of the complexity in
     certification path building.  However, one should not assume that
     this model does not exist or is not implemented.  A Full Mesh PKI,
     which is one where all CAs in the PKI mutually cross-certify each
     other directly, MAY be useful for certification path building,
     because it is able to reach any prior PKI domain directly without
     passing through another PKI domain.

             cross certified  +-------+  cross certified
            +---------------->|  CA   |<----------------+
            |                 +-------+                 |
            |                  |     |                  |
            |                  |     |                  |
            |                  v     v                  |
            |               +----+ +----+               |
            |               | EE | | EE |               |
            |               +----+ +----+               |
            v                                           v
         +------+                                   +------+
         |  CA  |<--------------------------------->|  CA  |-----+
         +------+          cross certified          +------+     |
          |     |                                    |    |      |
          |     |                                    |    |      |
          v     v                                    v    v      v
      +----+ +----+                              +----+ +----+ +----+
      | EE | | EE |                              | EE | | EE | | EE |
      +----+ +----+                              +----+ +----+ +----+

                       Figure 7 - Mesh PKI model

6  multi-domain PKI

   Each PKI domain establishes a trust relationship with more than one
   PKI domain.

   This section describes topology models for multi-domain PKI.  To
   achieve interoperability, all PKIs in a multi-domain PKI SHOULD apply
   the following models.

   Considerations

     Multi-domain PKI MAY need policy mapping or constraints to maintain
     each domain policy.  All required information for path validation
     MUST be able to be obtained through some distribution methods.




Shimaoka, et al.                                               [Page 20]

INTERNET DRAFT                                              January 2006


        - Intermediate certificate
        - Target certificate (optional)
        - Revocation information for all certificates

     For this, CAs MAY operate a repository, and SHOULD include
     authorityInfoAccess or cRLDistributionPoints extensions in the
     certificates they issue to maximize PKI interoperability.

6.1  Multi Trust point model (based on Trust List)

   The model in which a relying party trusts multiple PKI domains by a
   trust list.

   Considerations

     If the owner of the trust list adds a CA in the existing
     certification path, it SHOULD do so carefully since a constraint in
     the certification path MAY NOT be evaluated correctly.  The reason
     is the following:

        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 trusts 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, the relying party MUST recognize a risk of
        trusting another CA directly.

     Most of the actual public PKIs establish a multi-trust point model
     without a domain policy.  When using such public PKIs, this
     document recommends:

        - user-initial-policy-set SHOULD NOT be specified,
        - and initial-explicit-policy SHOULD NOT be true.

   In general, since it is difficult for the EE to check if a CA's self-
   signed certificate has been revoked, a CA SHOULD announce it to all
   its EEs when the CA is compromised and MAY issue the CRL.  Anyway,
   for announcement to all its EEs, the CA SHOULD do the best: phoning,
   emailing, press release, and etc.  In the multi-trust point model, a
   compromised trust anchor SHOULD be removed from the trust list, and
   the removal SHOULD be performed by the subject managing the trust
   list.

6.1.1  Based on User Trust List

   Considerations



Shimaoka, et al.                                               [Page 21]

INTERNET DRAFT                                              January 2006


     This is a simple and typical method for making a trust relationship
     to another PKI domain.  The relying party MUST understand the
     certificate status of the trust anchor in the trust list.

6.1.2  Based on Authority Trust List

   Since there is no standard or established method to achieve
   interoperability, this memo does not recommend using this model in
   multi-domain PKI.

6.2  Single Trust Point model (based on Cross-Certification)

   The model in which all PKI domains are related by Cross-
   Certification.  This cross-certification is either mutual or
   unilateral.  In this model, only one trust anchor is required by EEs.

   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.

6.2.1  Unified Domain model (based on unilateral Cross-Certification)

   The model in which multiple PKI domains have a joint superior CA that
   issues cross-certificates to each PKI domain unilaterally.  Such a
   joint superior CA is defined as unificate CA.  This model is used as
   a method to unify or reconfigure the multiple PKI domains to one PKI
   domain by subordinating the individual PKI domains.  Except that
   Principal CAs transformed into subordinate CAs have both self-signed
   certificates and intermediate certificates issued by the Unificate
   CA, this model looks like a subordination model with the Unificate CA
   as the trust anchor across the PKI domains.  Therefore, this model is
   often used like the hierarchy model in multi-domain PKI.

        cross-certified                        cross-certified
     Unificate CA to PKI 1 +--------------+  Unificate CA to PKI 3
                 +---------| Unificate CA |---+
                 |         +--------------+   |



Shimaoka, et al.                                               [Page 22]

INTERNET DRAFT                                              January 2006


                 |                 |          |
                 |  cross-certified|          |
                 |   Unificate CA  |          |
                 |    to PKI 2     |          |
     +-----------|---+ +-----------|---+ +----|-----------------+
     |     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 8 - Unified Domain model

6.2.2  Bridge model

   The model in which every PKI domain trusts each other through a
   Bridge CA by Cross-Certification.  In this model, the trust
   relationship is not established between a subscriber domain and a
   relying party domain directly, but established through the Bridge CA.
   This is useful in reducing the number of cross-certifications
   required for a PKI domain to interoperate with other PKI domains.

   Requirements for Bridge model

     - Bridge CA MUST NOT be used as the trust anchor in any PKI domain.
     - Bridge CA SHOULD issue cross-certificates with other PKI domains
     mutually or MAY issue cross certificates unilaterally.
     - Bridge CA MUST NOT issue EE certificates except when it is
     necessary for the CA's operation.
     - Bridge CA MUST use its own domain policy in the policy mapping
     between a prior PKI domain and a posterior PKI domain.



Shimaoka, et al.                                               [Page 23]

INTERNET DRAFT                                              January 2006


     - The domain policy of Bridge CA MUST be a subset of the prior PKI
     domain policy that is mapped.
     - The domain policy of Bridge CA MUST be a superset of the
     posterior PKI domain policy that is mapped.  - Bridge CA SHOULD be
     a neutral position to all PKI domains which trust through the
     Bridge CA.

        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

     - 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.
     - Cross-certificate issued to Bridge CA SHOULD include the
     requireExplicitPolicy with a value that is greater than zero in the
     policyConstraints extension.
     - Cross-certificate issued by Bridge CA SHOULD NOT include any
     constraints to keep its neutral position.
     - PKI domains cross-certified with Bridge CA SHOULD NOT cross-
     certify directly to other PKI domains cross-certified with the same
     Bridge CA.
     - 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 a neutral trusted third party
     agreed upon by the PKIs or consortium consisting of the PKIs.  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.



Shimaoka, et al.                                               [Page 24]

INTERNET DRAFT                                              January 2006


            Otherwise, the prior PKI domain MUST carefully consider the
            risks involved with accepting certificates with a lower
            security level.

         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 9 - Bridge model

7  Operational Considerations

   This chapter explains the issues one needs to consider about the
   management of cross-certificate(s) and use of a directory.

7.1 Directory


   (1) Unilateral cross-certification




Shimaoka, et al.                                               [Page 25]

INTERNET DRAFT                                              January 2006


     When CA-X cross-certifies CA-Y unilaterally, both CAs SHOULD
     operate their directory server in the following way.

        CA-X SHOULD generate the following crossCertificatePair and
        store it in its own directory entry.
            issuedToThisCA := NULL
            issuedByThisCA := cross-certificate for CA-Y issued by CA-X

        CA-Y MAY generate the following crossCertificatePair and store
        it in its own directory entry.
            issuedToThisCA := cross-certificate for CA-Y issued by CA-X
            issuedByThisCA := NULL

   (2) Mutual cross-certification

     Each CA MUST generate a crossCertificatePair that consists of the
     cross-certificate it issues and the cross-certificate it is issued.

        CA-X SHOULD generate the following crossCertificatePair and
        store it in its own directory entry:
            issuedToThisCA := cross-certificate for CA-X issued by CA-Y
            issuedByThisCA := cross-certificate for CA-Y issued by CA-X

        CA-Y SHOULD generate the following crossCertificatePair and
        store it in its own directory entry:
            issuedToThisCA := cross-certificate for CA-Y issued by CA-X
            issuedByThisCA := cross-certificate for CA-X issued by CA-Y

        In the mutual cross-certification model, each CA SHOULD NOT
        individually generate two crossCertificatePairs each containing
        only one cross-certificate, similar to the unilateral cross-
        certification model.

   (3) Subordination

     A superior CA MAY store a subordinate CA certificate to
     issuedByThisCA element of crossCertificatePair attribute in its own
     entry for the reverse path building.  However, it SHOULD be only
     for compatibility with the reverse path building, since a path
     building for subordination SHOULD be the forward direction.  A
     superior CA SHOULD NOT store a subordinate CA certificate in its
     own entry for the forward path building.  A subordinate CA MAY
     store its own subordinate CA certificate to the issuedToThisCA
     element of the crossCertificatePair attribute in its own
     (subordinate CA) entry for the forward path building.  A
     subordinate CA MUST store its own subordinate CA certificate to the
     cACertificate attribute in its own entry.




Shimaoka, et al.                                               [Page 26]

INTERNET DRAFT                                              January 2006


7.2 Cross-Certification

   When updating the Cross-Certificate:

        There is a standard method for what to do when a cross-
        certificate is updated by modifying some of its contents, e.g.,
        policy identifier.

        When issuer CA-X re-issues a cross-certificate to subject CA-Y
        before the issued cross-certificate expires, both CA-X and CA-Y
        MUST each update their own crossCertificatePair corresponding to
        the cross-certificate, and MUST publish it to their own
        directory system.  Until this is done, the change of cross-
        certification is not reflected completely in certification
        paths.  In addition, CA-X MUST revoke the old cross-certificate
        to CA-Y when CA-X does not intend to enable the old cross-
        certificate.  The reason why both CAs MUST update each
        crossCertificatePair is that the relying party may use the
        issuedToThisCA attribute of the crossCertificatePair (in subject
        CA-Y entry of the repository) for tracing the certification
        path.

   When updating the CA keypair:

        When a CA issues a set of self-issued certificates for key
        rollover, update of the cross-certificate is able to have a
        migration period up to the expiration of the originally issued
        self-issued certificate.

   When the keypair of the subject CA is compromised:

        When the keypair of subject CA-Y is compromised, issuer CA-X
        MUST revoke the cross-certificate for subject CA-Y, then CA-X
        SHOULD remove the crossCertificatePair attribute for CA-Y from
        its repository.

7.3  Providing Directory Information Across PKI-domains

   The directory infrastructures used by individual PKI domains to
   distribute certificates and CRLs usually consist of either a set of
   interconnected or stand alone directories.

   An interconnected directory infrastructure connects directories via
   the use of a directory protocol such as chaining, replicating, or
   shadowing.  An interconnected directory infrastructure allows the
   relying parties to reduce the number of directories they need to be
   aware of in order to obtain certificates and CRLs.  However, this
   technique MAY lead to infrastructure propagation delays as directory



Shimaoka, et al.                                               [Page 27]

INTERNET DRAFT                                              January 2006


   information is updated or changed.

   Directory infrastructures composed of stand alone directories provide
   certificate and CRL information from a set (list) of directories the
   relying parties are aware of.  If a directory is queried but cannot
   satisfy the request, it MAY provide referrals to another directory
   that might be able to provide the requested information.

   To help promote interoperability, the PKI domains SHOULD provide
   access to the PKI domain's directory infrastructure via LDAP or HTTP
   and information to access (e.g. IP address or FQDN) at least one of
   the PKI domain's directories.  EE SHOULD be able to process LDAP
   referrals in order to operate with a set of stand alone directories.

8  Security Considerations

8.1  Certificate and CRL Profile

   Defining the concrete Certificate and CRL profile for multi-domain
   PKI interoperability is not within the scope of this memo.  All
   Certificates and CRLs MUST comply with [RFC 3280].  In addition, CAs
   in a multi-domain PKI SHOULD consider the following for the
   Certificate and CRL profile:

     * Extensions intended for processing only by a local PKI domain
     SHOULD be non-critical.
     * The cRLDistributionPoints extension SHOULD be used for obtaining
     the revocation list.  distributionPoint field SHOULD include also
     the UniformResourceIdentifier.  When the CRL is separated into ARL
     and CRL, the issuingDistributionPoint extension SHOULD also be
     used.
     * The Authority Key Identifier extension and Subject Key Identifier
     extension SHOULD be used for assisting in path construction.
     * The policyIdentifier field of the Certificate Policies extension
     SHOULD be used for identifying each policy domain.
     * The Policy Mapping extension MAY be used for validating that
     mutual domain policies are equivalent.
     * The Name Constraints extension MAY NOT be used for multi-domain
     PKI because the name space of multi-domain PKI is not managed by a
     single authority allowing for the possibility of a name space
     conflict.  If a name space conflict exists, the name constraint
     extension MAY unintentionally exclude a PKI domain.  If a PKI
     domain uses the name constraints in multi-domain PKI, the PKI
     domain SHOULD pay attention for conflicts in the PKI domain name
     spaces.

8.2  Path Validation




Shimaoka, et al.                                               [Page 28]

INTERNET DRAFT                                              January 2006


   Validation policy used for path validation is the intersection of
   authority-constrained parameters and user-constrained parameters.  An
   authority-constrained parameter SHOULD NOT assume the validation
   policy of a relying party, but SHOULD be included in the certificates
   explicitly.

   A Relying party MUST carefully determine its validation policies,
   including the trust anchor.

8.3  Asymmetric problem

8.3.1  Hybrid trust model

   This clause considers the case in which PKI domains trust each other
   by different trust relationship models such as user trust lists and
   unilateral cross-certification trust models.

   Inter-domain trust relationships do not have to be symmetric.  Since
   inter-domain trust relationships in this document are defined as
   directional trust relationships, there is no additional requirement
   for a hybrid trust model.  What each PKI domain does is merely the
   same as a symmetric trust relationship model.  For example when PKI
   domain-X trusts PKI domain-Y by the user trust list model and PKI
   domain-Y trusts PKI domain-X by unilateral cross-certification, PKI
   domain-X merely has to comply with the user trust list model, and PKI
   domain-Y with the unilateral cross-certification model.

8.3.2  Asymmetric policy mapping

   This clause considers the case where a result of the policy mapping
   in mutual cross-certification model is asymmetric.  This document
   does not strongly recommend using asymmetric mapping because the
   following unequivalent mapping often creates a security hole.

                    +-------+  cP-1.1 := cP-2.1  +-------+
                    |       |------------------->|       |
                    | PCA 1 |                    | PCA 2 |
                    |       |<-------------------|       |
                    +-------+  cP-2.1 := cP-1.2  +-------+

                           Figure 10 - Asymmetric policy mapping

   When path building allows the certification path to loop, then cP-1.1
   is mapped to cP-1.2, and such a policy mapping MAY create an
   unforeseen security hole in the certification path.  E.g., CA-X that
   cross-certified to PCA-1 with cP-1.1 MAY be able to grow its
   certification path to another PKI domain via PCA-1 by cP-1.2.  Since
   different policy identifiers managed by the same PKI actually



Shimaoka, et al.                                               [Page 29]

INTERNET DRAFT                                              January 2006


   describe different policies, differing policy identifiers mapped
   unexpectedly in the same entity represent a critical security issue.

   To prevent such a security hole, a loop certification path, one where
   the same DN appears twice and non-continuously on one certification
   path MUST NOT be allowed.

9  References

9.1  Normative References

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

      [RFC 2256]  Wahl, M., "A Summary of the X.500(96) User Schema for
                  use with LDAPv3", RFC 2256, Dec 1997.

      [ISO-X509]  ITU-T Recommendation X.509 (2005 E): Information
                  Technology - Open Systems Interconnection - The
                  Directory: Authentication Framework, August 2005.


9.2  Informative References

      Housley, R. and Polk, W., JOHN WILEY & SONS, INC.,
      "Planning for PKI", Aug 2001.

      Lloyd, S., PKI Forum, "PKI Interoperability Framework",
      March 2001.

      Lloyd, S., PKI Forum,  "CA-CA Interoperability", March 2001.

      Shimaoka, M., Japan Network Security Association, and ISEC,
      Information Technology Promotion Agency, Japan, "Interoperability
      Issues for multi PKI domain", Jul 2002.

      Japan Network Security Association, ISEC, Information Technology
      Promotion Agency, Japan, "Implementation Problems on PKI",
      Feb 2003.

      Japan PKI Forum, Korea PKI Forum, PKI Forum Singapore, Chinese
      Taipei PKI Forum, "Achieving PKI Interoperability 2003",
      Jul 2003.

      Japan PKI Forum, Korea PKI Forum, PKI Forum Singapore, "Achieving
      PKI Interoperability", Apr 2002.




Shimaoka, et al.                                               [Page 30]

INTERNET DRAFT                                              January 2006


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


10  Acknowledgements

   This document is based on some valuable documents and many
   experiences with PKI interoperability experiments.  The authors
   gratefully acknowledge the contributions of members of various multi-
   domain PKI interoperability experiments, in particular: Kenji Nakada,
   Kiyoshi Watanabe, Sang Hwan Park, Ryu Inada, Hiroyuki Yoshida and
   Yasushi Matsumoto.

   The authors are also grateful to members of the Internet Engineering
   Task Force (IETF) Public Key Infrastructure working group (PKIX), and
   the Technical Working Group in Interoperability Working Group, which
   consists of Japan PKI Forum, Korea PKI Forum, Singapore PKI Forum and
   Chinese Taipei PKI Forum (JKST-IWG) for ideas and useful discussions
   which helped us in this effort.  This work is aided by Information-
   technology Promotion Agency Information-technology Security Center
   (IPA/ISEC) and Japan Network Security Association (JNSA).

11  Author's Address

   Masaki SHIMAOKA
   SECOM Co., Ltd. Intelligent Systems Lab.
   SECOM SC Center, 8-10-16, Shimorenjaku
   Mitaka, Tokyo 181-8528
   JAPAN
   Email: shimaoka@secom.ne.jp / m-shimaoka@secom.co.jp

   Nelson E. Hastings
   NIST
   100 Bureau Drive, Stop 8930
   Gaithersburg, MD 20899-8930
   USA
   EMail: nelson.hastings@nist.gov

   Rebecca Nielsen
   Booz Allen Hamilton
   8283 Greensboro Drive
   McLean, VA 22102
   USA
   Email: nielsen_rebecca@bah.com

12  Full Copyright Statement




Shimaoka, et al.                                               [Page 31]

INTERNET DRAFT                                              January 2006


   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.

   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.














Shimaoka, et al.                                               [Page 32]


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