[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 Trust.net
<draft-shimaoka-multidomain-pki-02.txt>                     January 2004


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


Status of this Memo

   This memo is a guideline for the multi-domain PKI interoperability.
   This is a best current practice, not a specification. Distribution of
   this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   This memo is used to share the awareness necessary to deployment of
   multi-domain PKI. Scope of this memo is to establish and clear the
   trust relationship and interoperability between plural PKI domains.
   Both single-domain PKI and multi-domain PKI are established by the
   trust relationships between Certification Authorities (CAs).  Typical
   and primitive PKI models are specified as single-domain PKI.  Multi-
   domain PKI established by plural single-domain PKI is categorized as
   multi-trust point model and single-trust point model. Multi-trust
   point model is based on trust list model, and single-trust point
   model is based on cross-certification model.

Table of Contents

   1  Introduction      . . . . . . . . . . . . . . . . . . . . . . . .  2
   2  Requirements and Assumptions    . . . . . . . . . . . . . . . . .  3
   2.1  Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.2  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.3  Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3  Trust Relationship  . . . . . . . . . . . . . . . . . . . . . . .  6
   3.1  Trust List  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.1.1  User Trust List . . . . . . . . . . . . . . . . . . . . . . .  7
   3.1.2  Authority Trust List  . . . . . . . . . . . . . . . . . . . .  8
   3.2  Cross-Certification . . . . . . . . . . . . . . . . . . . . . .  8
   3.2.1  Unilateral Cross-Certification  . . . . . . . . . . . . . . .  9
   3.2.2  Mutual Cross-Certification  . . . . . . . . . . . . . . . . . 11
   3.3  Subordination (Hierarchy) . . . . . . . . . . . . . . . . . . . 12
   4  PKI Domain  . . . . . . . . . . . . . . . . . . . . . . . . . . . 14



Shimaoka                                                        [Page 1]

INTERNET DRAFT                                              January 2004


   4.1  Requirements for PKI domain . . . . . . . . . . . . . . . . . . 14
   4.2  Risk Analysis of non interoperable PKI domain . . . . . . . . . 14
   4.3  Requirements for multi-domain PKI interoperability  . . . . . . 14
   5  Single-domain PKI . . . . . . . . . . . . . . . . . . . . . . . . 15
   5.1  Single PKI model  . . . . . . . . . . . . . . . . . . . . . . . 15
   5.2  Hierarchy PKI model . . . . . . . . . . . . . . . . . . . . . . 16
   5.3  Mesh PKI model  . . . . . . . . . . . . . . . . . . . . . . . . 17
   6  multi-domain PKI  . . . . . . . . . . . . . . . . . . . . . . . . 18
   6.1  Multi Trust point model . . . . . . . . . . . . . . . . . . . . 18
   6.1.1  Based on User Trust List    . . . . . . . . . . . . . . . . . 19
   6.1.2  Based on Authority Trust List . . . . . . . . . . . . . . . . 19
   6.2  Single Trust Point model  . . . . . . . . . . . . . . . . . . . 19
   6.2.1  Peer-to-Peer model  . . . . . . . . . . . . . . . . . . . . . 20
   6.2.2  Unified Domain model  . . . . . . . . . . . . . . . . . . . . 20
   6.2.3  Hub model (a.k.a Bridge CA) . . . . . . . . . . . . . . . . . 21
   6.2.4  Considerations for trusted third CA . . . . . . . . . . . . . 22
   7  Security Considerations . . . . . . . .  .  . . . . . . . . . . . 23
   7.1  Certificate and CRL Profile . . . . . . . . . . . . . . . . . . 23
   7.2  Repository      . . . . . . . . . . . . . . . . . . . . . . . . 24
   7.3  Path Validation . . . . . . . . . . . . . . . . . . . . . . . . 24
   7.4  Public PKI and Private PKI  . . . . . . . . . . . . . . . . . . 24
   7.5  Asymmetric problem  . . . . . . . . . . . . . . . . . . . . . . 25
   7.5.1  Hybrid trust model  . . . . . . . . . . . . . . . . . . . . . 25
   7.5.2  Asymmetric policy mapping . . . . . . . . . . . . . . . . . . 25
   8  References  . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
   8.1  Normative References  . . . . . . . . . . . . . . . . . . . . . 26
   8.2  Informative References  . . . . . . . . . . . . . . . . . . . . 26
   9  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . . 27
   10 Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . 27
   11  Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 27

1  Introduction

   PKI is able to realize various architecture, through the means that
   CAs establish trust relationship with each other.  When a certain CA
   establishes a trust relationship with another CA, the CA MUST compare
   the certificate policy of each CAs carefully because various CAs have
   various certificate policy. So, establishment method for every trust
   relationship MAY differ by the result of comparison.  To establish
   appropriate trust relationship, fully understanding about a
   relationship between such establishment method and comparison is
   required.  In addition, all trust relationships established are able
   to categorize  two patterns, single-domain PKI and multi-domain PKI.
   The technology needed for such an interconnection is insufficient
   with only the specification of conventional protocol and data format
   and need to define the thing such as PKI domain and PKI architecture.
   This document clarifies these definitions for multi-domain PKI
   interoperability.



Shimaoka                                                        [Page 2]

INTERNET DRAFT                                              January 2004


   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 PKI.  Section 6 profiles multi-domain PKI 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 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, Repository, and path validation.

     +------------------+               +-------------------+
     |    PKI domain    |               |     PKI domain    |
     |                  | Domain-Domain |                   |
     |                  |    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

   PKI:  Public Key Infrastructure
     PKI based on X.509 is a set of CA and EE in a narrow sense.
     But in a wide sense, PKI sometime means a PKI domain itself.

   CA:   Certification Authority

   EE:   End Entity

   CRL:  Certificate Revocation List



Shimaoka                                                        [Page 3]

INTERNET DRAFT                                              January 2004


   ARL:  Authority Revocation List

2.2  Terminology

   Subscriber

     Holder of the certificate which is verified.

   Relying Party

     Entity who verifies the certificate.  Relying party MUST have a set
     of trust anchors and MAY have a set of acceptable certificate
     policies.  In single-domain PKI, these MAY be omitted tacitly.

   Top CA

     Only CA that is as a root of hierarchy PKI model.  Top CA MUST
     issue a self-signed certificate.  Top CA SHOULD be used for
     Hierarchy PKI model.  For unified domain model, unificate CA SHOULD
     be used as below.

   PKI domain

     PKI domain is a set of PKIs gathered upon some trust relationship.
     They MUST have more than one principal CA and SHOULD have more than
     one common certificate policy. Such common policy is named as
     "domain policy".

   Domain Policy

     More than one common certificate policy (Object Identifier) which
     shared in a PKI domain.  This Object Identifier is used to
     distinguish each PKI domain.  PKI domain having no certificate
     policy MAY be not distinguished by relying party in another PKI
     domain.

   Trust Point

     Starting point of a certification path to a subscriber certificate.
     Trust Point MUST be a self-signed certificate, except for Mesh PKI
     model.

   Principal CA

     A CA in a PKI domain that trusts other PKI domain directly or is
     trusted from other PKI domain directly.  Principal CA SHOULD issue
     a self-signed certificate.




Shimaoka                                                        [Page 4]

INTERNET DRAFT                                              January 2004


   Trusted PKI domain

     PKI domain which is trusted from trusting PKI domain.  Usually,
     trusted PKI domain means a PKI domain of subscriber.

   Trusting PKI domain

     PKI domain which trusts other PKI domains.  Usually, trusting PKI
     domain means a PKI domain of relying party.

   Trust Anchor

     Trust anchor is a principal CA in relying party domain, and is also
     one of trust points.  Trust Anchor SHOULD be a self-signed
     certificate, except for Mesh PKI model.

     If it is necessary to claim clearly that CA is a trust anchor of an
     issued certificate, CA MAY indicate URI of its published CA
     certificate to caIssuer in AuthorityInformationAccess extension.

   Public PKI

     PKI using the trust point that is registered without user's clear
     agreement.  Generally, trust point is registered to certificate
     store managed by OS or each applications.  Web browser using its
     embedded root certificates for SSL/TLS is typical model of this.

   Private PKI

     PKI using the trust point that is registered with user's clear
     agreement.  Generally, all trust point registration require clear
     user's agreement.  In Private PKI, each PKI domain MUST have a
     domain policy.

   Trust Relationship

     In this document, this means a trust relationship between CAs.
     This relationship is required for tracking from a trust point to a
     subscriber.

   Validation parameters

     This is a term for only this document. Five parameters that are
     part of seven inputs for path validation defined in section 6.1.1
     of RFC3280.
        (c) user-initial-policy-set
        (d) trust anchor information,
        (e) initial-policy-mapping-inhibit



Shimaoka                                                        [Page 5]

INTERNET DRAFT                                              January 2004


        (f) initial-explicit-policy
        (g) initial-any-policy-inhibit
     As these parameters MAY NOT be depended on a built certification
     path and validation time, these parameters are bound to a trust
     point and are able to consider without two parameters '(a) a
     prospective certification path of length n' and '(b) the current
     date/time'.  These parameters SHOULD be bound to a trust point,
     since these except two parameters depending on each certification
     path and validation time.

   Unificate CA

     CA which has self-signed certificate and issued unilateral cross-
     certs to each principal CA of other PKI domains.  Unificate CA is
     specified as a trust point in the PKI domains that is cross-
     certified by this CA unilaterally.

   Trusted third CA

     CA which is as trusted third party for each PKI domains, and is
     necessary to establish a trust model like hub model and unified-
     domain model.

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 plural PKI(CA)
   interconnection.  All PKIs that are going to participate in multi-
   domain PKI SHOULD use these trust relationships for multi-domain PKI
   interoperability.

3.1  Trust List

   Definition

     Trust list is a list of more than one "trusted CA" certificate that
     means a trust point.  Trust list is used for specifying a trust
     point by relying party.

   Requirements

     CA in a trust list SHOULD NOT cross-certify each other.  All
     relying parties in this model MUST have a trust list.  There SHOULD



Shimaoka                                                        [Page 6]

INTERNET DRAFT                                              January 2004


     be each appropriate validation parameters for every trust points in
     trust list.

   Considerations

     In this model, relying party trusts more than one trust points.
     But finding out a revocation of each trust points is more difficult
     than doing it to one trust point.

                               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

   Definition

     The model in which a trust list is managed by End Entitiy (EE).  EE
     is able to have own user trust list individually.




Shimaoka                                                        [Page 7]

INTERNET DRAFT                                              January 2004


   Advantage

     EE is able to manage own user trust list.  EE is able to add a
     "trusted CA" certificate to own user trust list or delete it.  This
     is an easier and typical method for making a trust relationship to
     other PKI.

   Disadvantage

     Except for EE itself, anyone is not able to control the trust
     relationship.  If EE trusts unknown PKI domain irresponsibly, then
     its issuer CA cannot apply their certificate policy to the EE.

   Considerations

     To consider how to update the user trust list, when CA certificate
     in the user trust list is updated.

3.1.2  Authority Trust List

   Definition

     The model in which a trust list is issued by the trust anchor of
     relying party.  The trust anchor MAY issue plural trust list for
     some purpose or some parties.  EEs who share the same trust anchor
     MAY share a unique authority trust list provided by its trust
     anchor.

   Advantage

     EE cannot control its trust relationship from its trust anchor to
     other.  Trust anchor SHOULD control an appropriate trust
     relationship.

   Disadvantage

     In Internet PKI, there is no standard to use this model.  And,
     management method for authority trust list is not established
     generally.

   Considerations

     This is just theory for comparison with user trust list model.
     Since there is no standard, this model MAY NOT achieve
     interoperability sufficiently.

3.2  Cross-Certification




Shimaoka                                                        [Page 8]

INTERNET DRAFT                                              January 2004


   Definition

     Cross-Certification is an issuing certificate to another CA.

   Requirement

     CA that issues a cross-certificate MUST have a self-signed certificate.
     CA issued the cross-certificate also MUST have a self-signed certificate.

   Advantage

     Cross-Certification is stricter trust relationship than the trust
     list model, because the trust relationship is indicated by a
     certificate and (authority) revocation list and is recorded to an
     audit log.  Because all subject CAs have a self-signed certificate,
     a cross-certificate revocation does not always link to the subject
     CA compromise.

   Disadvantage

     CA MUST support cross-certification.  PKI SHOULD have a repository,
     e.g., a directory server to store a crossCertificatePair, and CA
     SHOULD generate a crossCertificatePair attribute.

   Considerations

     For path construction

        Because a calculation method for key identifier of each CA MAY
        NOT be same, subject CA SHOULD issue a cross-certification
        request which contains subjectKeyIdentifier in extensionRequest,
        and its value MUST be identical with subjectKeyIdentifier in
        self-signed certificate. Then, issuer CA SHOULD issue a cross-
        certificate which contains subjectKeyIdentifier set to the same
        value in the corresponding cross-certification request.

     For PKI issuing Revocation List

        Issuer CA MAY issue Authority Revocation List (ARL), or SHOULD
        issue fullCRL at least.  However, ARL including
        issuingDistributionPoint extension MAY NOT be processed by some
        applications.

     When update the Cross-Certificate

        There is no rule for what to do when a certain cross-certificate
        is updated to modify some contents, e.g., policy identifier, of
        cross-certificate.



Shimaoka                                                        [Page 9]

INTERNET DRAFT                                              January 2004


        When issuer CA-X re-issues a cross-certificate to subject CA-Y
        before the issued cross-certificate is expired, CA-X MUST update
        its crossCertificatePair and MUST populate it to directory
        system of CA-X, and CA-Y MUST update its crossCertificatePair
        corresponding to the cross-certificate and MUST populate it to
        directory system of CA-Y.  Until done it, change of cross-
        certification is not reflected completely to certification path.
        In addition, CA-X MUST revoke old cross-certificate to CA-Y when
        CA-X modifies some contents of the cross-certificate.

     When update CA keypair

        When CA issues a set of self-issued certificates for key
        rollover, to update cross-certificate is not required.  When CA
        does not issue a set of self-issued certificates for key
        rollover, to update cross-certificate is required.

        Note that CA DN might not change without a set of self-issued
        certificates for key rollover when CA keypair are compromised.

     When compromise the keypair of subject CA

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

3.2.1  Unilateral cross-certification

   Definition

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

   Advantage

     This certification is able to use like subordination, and is able
     to establish more flexible trust relationship than subordination.
     Even if cross-certificate is revoked, subject CA MAY be able to
     continue its operation.

   Disadvantage

     for PKI using directory system

        CA SHOULD generate a crossCertificatePair, even though
        unilaterally.




Shimaoka                                                       [Page 10]

INTERNET DRAFT                                              January 2004


   Considerations

     Subordination is peculiar case of unilateral cross-certification.
     Note that unilateral cross-certification is established easily
     without agreement from requested CA when a cross-certification
     request is stolen by other CA.

     for PKI using directory system

        When CA-X cross-certify CA-Y unilaterally, Both CA SHOULD
        operate their directory server as below.

           CA-X SHOULD generate a following crossCertificatePair and
           store it in own directory entry.

              issuedToThisCA := NULL
              issuedByThisCA := cross-certificate for CA-Y issued by CA-X

           CA-Y SHOULD generate a following crossCertificatePair and
           store it in own directory entry.

              issuedToThisCA := cross-certificate for CA-Y issued by CA-X
              issuedByThisCA := NULL

        +---------------+                 +----------------------+
        |    Trusting   |                 |        Trusted       |
        |     PKI 1     |                 |         PKI 2        |
        |               | cross-certified |                      |
        | +-----+       | PKI 1 to PKI 2  |  +-----+             |
        | | PCA |--------------------------->| PCA |<--+         |
        | +-----+       |                 |  +-----+   |         |
        |    |          |                 |    ^       |         |
        |    |          |                 |    |       v         |
        |    |          |                 |    |    +----+       |
        |    |          |                 |    |    | CA |---+   |
        |    |          |                 |    |    +----+   |   |
        |    |          |                 |    |     ^ |     |   |
        |    v          |                 |    v     | |     |   |
        | +----+        |                 | +----+   | |     |   |
        | | CA |---+    |                 | | CA |---+ |     |   |
        | +----+   |    |                 | +----+     |     |   |
        |   |      |    |                 |   |        |     |   |
        |   |      |    |                 |   |        |     |   |
        |   v      v    |                 |   v        v     v   |
        | +----+ +----+ |                 | +----+ +----+ +----+ |
        | | EE | | EE | |                 | | EE | | EE | | EE | |
        | +----+ +----+ |                 | +----+ +----+ +----+ |
        +---------------+                 +----------------------+



Shimaoka                                                       [Page 11]

INTERNET DRAFT                                              January 2004


               Figure 3 - Unilateral Cross-Certification

3.2.2  Mutual cross-certification

   Definition

     The model in which a CA issues a cross-certificate to another
     trusted CA mutually.

   Advantage

     TBD

   Disadvantage

     for PKI using directory system

        Both CAs MUST generate a crossCertificatePair that is composed
        of a cross-certificate it issued and the corresponding issued
        cross-certificate.  When either CA updates a cross-certificate,
        each CA MUST re-generate their crossCertificatePair
        synchronously.

   Considerations

     Both CAs MUST agree about more information to issue a cross-
     certificate (e.g., validity, keyUsage, and some constraints) and
     MUST exchange it.

     for PKI using directory system

        Each CAs MUST generate a crossCertificatePair that is composed
        by cross-certificate it issues and issued cross-certificate.

           CA-X SHOULD generate a following crossCertificatePair and
           store it in  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 a following crossCertificatePair and
           store it in own directory entry.

              issuedToThisCA := cross-certificate for CA-Y issued by CA-X
              issuedByThisCA := cross-certificate for CA-X issued by CA-Y

           In mutual cross-certification model, each CA SHOULD NOT
           generate two crossCertificatePair individually, which



Shimaoka                                                       [Page 12]

INTERNET DRAFT                                              January 2004


           includes only one cross-certificate.  Each CA SHOULD NOT
           generate two crossCertificatePair like a unilateral cross-
           certification model individually.

        +---------------+                 +----------------------+
        |     PKI 1     |                 |         PKI 2        |
        |               | cross-certified |                      |
        | +-----+       | 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 peculiar unilateral cross-certification.

   Definition

     Subordination is certificate issuing to CA that has no self-signed
     certificate.  Subordinate CA MUST have only one superior CA.
     Subordinate CA MUST never issue its self-signed certificate.

     Subordination is different from unilateral cross-certification,
     this model MUST NOT allow that a subordinate CA is certified by
     more than one issuer CAs.

   Advantage

     Subordinate CA MAY NOT require any accreditation, rather the
     accreditation is required only for superior CA or top CA.



Shimaoka                                                       [Page 13]

INTERNET DRAFT                                              January 2004


     Subordinate CA is able to inherit some policies and constraints
     from its superior CA.  Because Subordinate CA has clear trust
     relationship with its superior CA, the subordinate CA is able to be
     trusted easily by all EEs who trust the superior CA.

   Disadvantage

     Subordinate CA MUST NOT cross-certify any CAs, MAY just allow
     subordination.  When a subordinate CA certificate is revoked by a
     superior CA, also all certificates issued by the subordinate CA
     MUST NOT be trusted.  Subordinate CA MUST NOT override the
     certificate policy, which the superior CA allowed.

   Considerations

     Subordination MUST be used in Single-domain PKI, not multi-domain
     PKI.  When subordinate CA issues a self-signed certificate, the
     subordinate CA MUST require agreement of its superior CA about
     issuing the certificate, because almost certificates issued by the
     subordinate CA will be not constrained by the superior CA.

     for PKI using directory system

        Superior CA MUST NOT store a subordinate CA certificate to
        issuedByThisCA element of crossCertificatePair attribute in own
        (superior CA) entry, because path construction becomes non-
        efficiency.  Subordinate CA MAY store own subordinate CA
        certificate to issuedToThisCA element of crossCertificatePair
        attribute in own (subordinate CA) entry.  Subordinate CA MUST
        store own subordinate CA certificate to cACertificate attribute
        in own entry.

4  PKI Domain

   PKI domain is a set of PKIs gathered upon some trust relationship.

4.1  Requirements for PKI domain

   PKIs in a PKI domain MUST have more than one shared certificate
   policy and more than one principal CA. This shared policy is named as
   "domain policy".  All CAs in a PKI domain MUST be operated by each
   CP/CPS which is conformed to the domain policy.  There SHOULD be more
   than one principal CA that issued self-signed certificate in a PKI
   domain.  All CAs in a PKI domain MUST be able to issue a verifiable
   certificate by using the principal CA as trust anchor.

   PKI domain MUST publish the trust information below to domain EEs
   securely.



Shimaoka                                                       [Page 14]

INTERNET DRAFT                                              January 2004


     - Principal CA certificate and its fingerprint
     - CP/CPS for Principal CA
     - Obtaining method of revocation information

4.2  Risk Analysis of non interoperable PKI domain

   A PKI domain that satisfies the foregoing requirements MAY be used in
   multi-trust point model.  But such requirements are not sufficient
   for single-trust point model.  To use PKI domain in single-trust
   point model, more requirement is necessary.

   However, such a PKI domain SHOULD NOT be used in single-trust point
   model.  If such a PKI domain makes the single-trust point model, the
   following problem will be considered.

     - Lack of the PKI Domain identification method for the third party

        All certificates in the PKI domain MAY NOT have an
        identification information for the PKI domain.
        Distinguished Name cannot use as the identity for the PKI
        domain, because nobody administers the name space.

     - Case of that a PKI domain is not trusted by another PKI domain

        When a relying party specifies a certificate policy as one of
        the validation parameters, the certification path validation
        will fail because the policy of the relying party cannot map to
        an appropriate certificate policy.

4.3  Requirements for multi-domain PKI interoperability

   To achieve more multi-domain PKI interoperability, the following
   requirements are necessary for PKI domain.

     - PKI domain MUST have the policyId of the domain policy for
     mapping to other PKI domain.
          * policyId MUST be unique with a domain policy.
          * policyId MUST NOT be any-policy.

     - All CAs in a PKI domain MUST be able to issue a verifiable
     certificate by using the following validation parameters.
          * user-initial-policy-set which includes own domainPolicyId.
          * initial-explicit-policy as TRUE.
          * trust anchor which is principal CA certificate of the own
          PKI domain.

     - PKI domain SHOULD publish the trust relationship with other PKI
     domain.



Shimaoka                                                       [Page 15]

INTERNET DRAFT                                              January 2004


          * PKI domain MUST publish what kind of PKI it includes.
          * PKI domain SHOULD publish what kind of other PKI domain it
          trusts.
          * PKI domain MAY publish what kind of other PKI domain it is
          trusted by.

   In addition, the following requirements MAY be necessary depending on
   trust relationship with other PKI domain.

     (1) Single-trust point model

          SHOULD give an appropriate policy mapping between the trusting
          PKI domain and a trusted PKI domain to cross-certification.

     (2) Multi-trust point model

          SHOULD give an appropriate validation parameters conforming to
          domain policy to relying party.

            - Appropriate (it may be newest) trust anchor certificate
               * MAY be principal CA of subscriber PKI domain

            - Appropriate acceptable policy
               * MAY be domain policy of subscriber PKI domain
               * MUST NOT be any-policy

            - Appropriate other validation parameters if necessary

5  Single-domain PKI

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

5.1  Single PKI model

   This is simplest PKI model. All PKI models are composed of this.

   Definition

     Single PKI is composed of an only single CA and its EEs.  All EEs
     SHOULD trust only the CA.  All subscribers MUST be issued their
     certificate by only the CA.

   Principal CA

     Principal CA MUST be the single CA.



Shimaoka                                                       [Page 16]

INTERNET DRAFT                                              January 2004


   Trust anchor

     Trust anchor MUST be the single 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 is composed of an only top CA, some subordinate CAs
     and EEs.  Only a top CA MUST issue a self-signed certificate.  All
     subordinate CAs MUST have only one superior CA.

   Principal CA

     Principal CA MUST be the top CA.

   Trust anchor

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

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



Shimaoka                                                       [Page 17]

INTERNET DRAFT                                              January 2004


         +--| 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 is composed of plural CAs and their EEs.  All CAs MUST
     cross-certify more than one CA unilaterally, and MUST be cross-
     certified by more than one CA unilaterally. Some CAs MAY cross-
     certify mutually.

     In Internet PKI, there is no standard to propose this model.

   Principal CA

     Principal CA SHOULD be unique in the PKI domain.


   Trust anchor

     Trust anchor for relying party SHOULD be a CA which issued a
     certificate to them.

   Considerations

     All EEs MUST trust only a CA that issued their own certificate.
     Determine a principal CA for foreign PKI domain.  This model SHOULD
     NOT be designed intentionally, but MAY be formed for some reason.

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



Shimaoka                                                       [Page 18]

INTERNET DRAFT                                              January 2004


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

                       Figure 7 - Mesh PKI model

6  multi-domain PKI

   Multi-domain PKI is composed of plural PKI domain that MUST have
   different domain policy which is able to map each other.  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 that compose multi-domain PKI
   SHOULD apply following models.

   Considerations

     Required all information for path validation MUST be able to be
     obtained through Internet.
        - Intermediate certificate
        - Revocation information
     For this, CA MAY operate a repository, and SHOULD include
     authorityInfoAccess or cRLDistributionPoints extensions in the
     certificates it issues.

6.1  Multi Trust point model (based on Trust List)

   The model in which a relying party trusts plural PKI domains by a
   trust list.  Relying party is able to use trust list for specifying
   the trust point in other PKI domains.  Trust list MUST be more than
   one principal CA certificate, as a trust point, of other PKI domain,
   and SHOULD have individually appropriate validation parameters
   including acceptable policy for each trust point.  CAs in a trust
   list SHOULD not cross-certify each other.

   Considerations

     The format of trust list, which SHOULD be more than one pair of a
     trust point and the corresponded validation parameters, has no
     standard.  The format of trust list has no standard. The list MUST



Shimaoka                                                       [Page 19]

INTERNET DRAFT                                              January 2004


     be more than one trusted CA (self-signed) certificate as trust
     point, which SHOULD include validation parameters for each trust
     point.  Actual most public PKIs establish on multi-trust point
     model without domain policy.  When using such public PKI, user-
     initial-policy-set SHOULD NOT be specified, and initial-explicit-
     policy SHOULD NOT be true.

     Generally, since that EE checks a revocation of CA's self-signed
     certificate is difficult, CA SHOULD announce it to all EE when CA
     is compromised.  In multi-trust list model, each CA SHOULD announce
     it to all EEs in not its PKI domain but all trusted PKI domain.

6.1.1  Based on User Trust List

   Considerations

     This is an easier and typical method for making a trust
     relationship to other PKI domain.  Relying Party is able to
     establish trust relationship with other PKI domain irresponsibly to
     his trust anchor.  Relying party MUST notice whether each CA
     certificates as trust point updated or are revoked.  Relying party
     MAY need to obtain some inputs, e.g., user-initial-policy-set,
     initial-policy-mapping-inhibit, initial-explicit-policy and
     initial-any-policy-inhibit, for path validation from somewhere.

6.1.2  Based on Authority Trust List

   Since there is no standard or established method, 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 related by Cross-Certification.
   In this model, a trust point is just a trust anchor. Therefore,
   certification path always start from trust anchor of relying party.

   Considerations

     Each PKI domain SHOULD use policy mapping for acrossing different
     PKI domains. In addition, cross-certificate SHOULD set zero to
     requireExplicitPolicy in the policyConstraints extension, and MAY
     set any value to inhibitPolicyMappings in the policyConstraints
     extension. If the PKI domain does not use policy mapping, it MAY
     seem same PKI domain.

     All certification path MUST be started from the only trust anchor,
     then validation parameters MAY be an only set.




Shimaoka                                                       [Page 20]

INTERNET DRAFT                                              January 2004


     Cross-Certificate SHOULD use authorityKeyIdentifier extension and
     subjectKeyIdentifier extension for path construction.

6.2.1  Peer-to-Peer model (based on Cross-Certification)

   The model in which two peer PKI domains trust each other by Cross-
   Certification.  This trust relationship SHOULD be established by
   mutual Cross-Certification, or MAY be established by unilateral
   Cross-certification.

   In Cross-Certification model, because trust-anchor is an only one,
   the validation parameters SHOULD be authority-constrained things.

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

   The model in which plural PKI domains have a joint superior CA that
   issues cross-certificates to each PKI domain unilaterally.  Such
   joint superior CA is defined as unificate CA.  Each PKI domain MUST
   have more than one shared certificate policy at least.

   This model looks like a subordination model, except for that the
   intermediate CA has a self-signed certificate.  Therefore, often this
   model is used like hierarchy model in multi-domain PKI.

        cross-certified                        cross-certified
     Unificate CA to PKI 1 +--------------+  Unificate CA to PKI 3
                 +---------| Unificate CA |---+
                 |         +--------------+   |
                 |                 |          |
                 |  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 |---+ |     |   |
     |   |      |    | |   |   +----+  | | +----+     |     |   |



Shimaoka                                                       [Page 21]

INTERNET DRAFT                                              January 2004


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

                    Figure 8 - Unified Domain model

6.2.3  Hub model (a.k.a Bridge CA)

   The model in which every PKI domains trust each other through a
   Bridge CA by Cross-Certification.  This is useful to reduce the
   complexity of cross-certification.

   Requirements for Hub model

     - Bridge CA MUST NOT be used as the trust anchor in any PKI domain.
     - Bridge CA MUST issue cross-certificate with other PKI domain
     mutually.
     - Bridge CA SHOULD issue ARL and CRL, or MAY issue fullCRL.
     - Bridge CA MUST NOT issue EE certificate excepting necessary one
     for the CA operation.  And at least, the EE certificate MUST be
     constrained to fail in the path validation from other PKI domain.
     - Bridge CA MUST use own domain policy in the policy mapping
     between a trusting PKI domain and a trusted PKI domain.

        Cross-Certificate from Trusting PKI domain to Bridge CA
          issuerDomainPolicy := Trusting PKI domain policy
          subjectDomainPolicy := Bridge CA domain policy

        Cross-Certificate from Bridge CA to Trusted PKI domain
          issuerDomainPolicy := Bridge CA domain policy
          subjectDomainPolicy := Trusted PKI domain policy

     - Cross-Certificate issued by Bridge CA and Cross-Certificate
     issued to Bridge CA SHOULD include the requireExplicitPolicy more
     than equal zero in policyConstaints extension.
     - To trust a trusted PKI domain, trusting PKI domain MUST do via
     BCA.
     - PKI domain cross-certified with Bridge CA SHOULD NOT cross-
     certify directly to other PKI domain cross-certified with the same
     Bridge CA.
     - Bridge CA SHOULD clarify the method for the policy mapping of
     cross-certification.

   Considerations



Shimaoka                                                       [Page 22]

INTERNET DRAFT                                              January 2004


     Bridge CA SHOULD be operated by neutral trusted third party.
     Bridge CA SHOULD do policy mapping appropriately with both PKI
     domains.  Both PKI domains that cross-certifies with Bridge CA
     SHOULD NOT use nameConstraints extension because they cannot limit
     name-spaces via Bridge CA.  Bridge CA MUST have an independent
     certificate policy from both PKI domain, and MUST use it for policy
     mapping.

         cross-certified                 cross-certified
         PKI 1 with BCA   +-----------+  PKI3 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 - Hub model

6.2.4  Considerations for trusted third CA

   This clause considers the case of that trust relationship is not
   established between subscriber domain and relying party domain
   directly, but established via trusted third CA (e.g., Bridge CA in
   Hub model, and Unificate CA in Unified domain model).



Shimaoka                                                       [Page 23]

INTERNET DRAFT                                              January 2004


   (1) Advantage of using trusted third CA

      - Via trusted third CA, trusting PKI domain can automatically
      deploy trusted PKI domains that have mappable domain policy.
      - Trusting PKI domain can open its security level of own domain
      policy by certifying with trusted third CA.
          * This means that the trusting PKI domain passed the criteria
          for the cross-certification of the trusted third CA.
          * This means that the trusting PKI domain has no risk of
          mismapping with other PKI domain which is lower security
          level.
      - PKI domain can suggest the cross-certification with trusted
      third CA as index to be trusted from other PKI domains.  - What CA
      cross-certifies with trusted third CA suggests that such CAs are
      able to be trusted by third PKI domain.

   (2) Confirmation for trusting the trusted third CA

      - Does the trusted third CA do the policy mapping via own domain
      policy?
      - Does the trusted third CA clear the method of policy mapping in
      cross-certification?
      - Is the trusted third CA able to accept the domain policy that
      the trusting PKI domain desired?
          * If the domain policy is mapped to lower security level,
          trusting domain MUST NOT accept it.
          * Trusting PKI domain SHOULD request sufficient policy control
          for maintaining its security level.

   (3) Considerations

     If trusted third CA cannot keep neutrality, trusting domain will
     cross-certify with PKI domain that is lower security level.

7  Security Considerations

7.1  Certificate and CRL Profile

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

     * The extensions for only processing in local PKI domain MUST be
     non-critical.

     * cRLDistributionPoint extension SHOULD be used for obtaining the



Shimaoka                                                       [Page 24]

INTERNET DRAFT                                              January 2004


     revocation list. distributionPoint field SHOULD prefer
     UniformResourceIdentifier. When the CRL is separated to CARL and
     EPRL, issuingDistributionPoint extension also SHOULD be used.

     * Authority Key Identifier extension and Subject Key Identifier
     extension SHOULD be used for aiding a path construction.

     * Certificate Policies extension SHOULD be used for identifying
     each policy domain.

     * Policy Mapping extension MAY be used for policy mapping in
     single-trust point model.

     * Name Constraints extension MAY NOT be used for multi-domain PKI
     because name space of multi-domain PKI is not managed by anyone.

     * Policy Constraints extension MAY be used for path validation of
     foreign PKI domain.

7.2  Repository

   Relying party MUST obtain all required information for path
   construction and validation.  If necessary, CA issues a certificate
   including Authority Information Access extension or CRL Distribution
   Points extension for aiding in that a relying party does the path
   construction.

7.3  Path Validation

   Validation parameters used for path validation SHOULD be intersection
   between authority-constrained parameters and user-constrained
   parameters.  Therefore, CAs SHOULD design an validation parameters so
   that it is divided as user-constrainted parameters and authority-
   constrained parameters.

   Non certificate holders MUST determine carefully their validation
   parameters including the trust anchor.

7.4 Public PKI and Private PKI

   Public PKI is more important for interoperability since many
   certificates are issued and distributed already.  Public PKI MUST
   keep interoperability with existing certification path, and alot of
   current paths still have no domain policy. Therefore, relying party
   using such Public PKI SHOULD NOT specify user-initial-policy-set and
   initial-explicit-policy.  Any certificates in Public PKI SHOULD NOT
   be designed assuming processing such certificate policies, policy
   mapping, or policyConstraints extension.  In fact, some CA softwares



Shimaoka                                                       [Page 25]

INTERNET DRAFT                                              January 2004


   cannot issue a certificate including such extensions.  Private PKI
   has less impact to re-issue the certificates than Public PKI since
   the deployments are limited. On the other hand, Private PKI may
   require more strict path validation because it may be used for more
   critical transaction.  When a certificate is used to both and has
   certificate policies extension, the extension SHOULD be non-critical.
   Relying party using the certificate as Private PKI MAY specify user-
   initial-policy-set and initial-require-policy, but relying party
   using it as Public PKI SHOULD NOT specify them.

7.5  Asymmetric problem

7.5.1  Hybrid trust model

   This clause considers a case of that PKI domains trust each other by
   different trust relationship.

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

7.5.2  Asymmetric policy mapping

   This clause considers a case of that result of the policy mapping in
   mutual cross-certification model is asymmetric.

                    +-------+  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 a loop of certification path, then cP-1.1
   is mapped to cP-1.2 and such a policy mapping MAY derive an
   unforeseen security hole of 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 same PKI mean different



Shimaoka                                                       [Page 26]

INTERNET DRAFT                                              January 2004


   policies, what different policy identifiers are mapped unexpectedly
   in same entity is an essential issue.
   To prevent such security hole, a loop certification path, what the
   same DN appears twice and non-continuously on one certification path
   MUST NOT be allowed.

8  References

8.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]  ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information
                  Technology - Open Systems Interconnection: The Directory:
                  Authentication Framework," 2001 edition.

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

      Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S. and Nicholas, R.,
      "Internet X.509 Public Key Infrastructure: Certification Path
      Building", Work in Progress, Oct 2003.





Shimaoka                                                       [Page 27]

INTERNET DRAFT                                              January 2004


9  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 author 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
   is consisted 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).

10  Author's Address

   Masaki SHIMAOKA
   SECOM Trust.net Co., Ltd.
   SECOM SC Center, 8-10-16, Shimorenjaku
   Mitaka, Tokyo JAPAN

   Email: shimaoka@secom.ne.jp



11  Full Copyright Statement

   "Copyright (C) The Internet Society (2004).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.




Shimaoka                                                       [Page 28]

INTERNET DRAFT                                              January 2004


   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.










































Shimaoka                                                       [Page 29]


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