[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-03.txt>                        July 2004



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



Status of this Memo


   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.


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


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 relationship and interoperability
   between multiple PKI domains.  Certification Authority (CA) is able
   to extend a certification path by trusting from/by other CAs.  Both
   single-domain PKI and multi-domain PKI are established by such trust
   relationships between CAs.  Typical and primitive PKI models are
   specified as single-domain PKIs.  A multi-domain PKI established from
   more than one single-domain PKI is categorized as either a multi-
   trust point model or single-trust point model. The multi-trust point
   model is based on the trust list model, and the single-trust point
   model is based on the Cross-Certification model.






Shimaoka                                                        [Page 1]

INTERNET DRAFT                                              January 2004



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  Operation based Trust Relationship  . . . . . . . . . . . . . .  6
   3.1.1  User Trust List model . . . . . . . . . . . . . . . . . . . .  7
   3.1.2  Authority Trust List model  . . . . . . . . . . . . . . . . .  8
   3.2  Certificate based Trust Relationship  . . . . . . . . . . . . .  8
   3.2.1  Unilateral Cross-Certification  . . . . . . . . . . . . . . .  9
   3.2.2  Mutual Cross-Certification  . . . . . . . . . . . . . . . . . 11
   3.3  Subordination (Hierarchy) . . . . . . . . . . . . . . . . . . . 12
   4  PKI Domain  . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   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.2  Unified Domain model  . . . . . . . . . . . . . . . . . . . . 20
   6.2.3  Bridge model  . . . . . . . . . . . . . . . . . . . . . . . . 21
   7  Operational Considerations  . . . . . .  .  . . . . . . . . . . . 23
   7.1  Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
   7.2  Cross-Certification . . . . . . . . . . . . . . . . . . . . . . 24
   8  Security Considerations . . . . . . . .  .  . . . . . . . . . . . 23
   8.1  Certificate and CRL Profile . . . . . . . . . . . . . . . . . . 23
   8.2  Path Validation . . . . . . . . . . . . . . . . . . . . . . . . 24
   8.3  Asymmetric problem  . . . . . . . . . . . . . . . . . . . . . . 25
   8.3.1  Hybrid trust model  . . . . . . . . . . . . . . . . . . . . . 25
   8.3.2  Asymmetric policy mapping . . . . . . . . . . . . . . . . . . 25
   9  References  . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
   9.1  Normative References  . . . . . . . . . . . . . . . . . . . . . 26
   9.2  Informative References  . . . . . . . . . . . . . . . . . . . . 26
   10  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27
   11 Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . 27
   12  Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 27







Shimaoka                                                        [Page 2]

INTERNET DRAFT                                              January 2004



1  Introduction


   PKI is extendable to realize various architectures, through the way
   in which CAs establish a trust relationships with each other.  When a
   certain CA establishes a trust relationship with another CA, the CAs
   MUST compare the security level as certificate policy of the other
   carefully because various CAs have various certificate policies. So,
   the method of establishment of every trust relationship MAY differ,
   as a result of such comparison.  To establish appropriate trust
   relationships, full understanding of the relationship between the
   establishment method and comparison is required.  In addition, all
   established trust relationships fall into one of two patterns:
   single-domain PKI and multi-domain PKI.  The technology needed for
   such an interconnection is insufficient with only the specifications
   of conventional protocols and data formats; elements such as PKI
   domain and PKI architecture require definitions.  This document
   clarifies these definitions for 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 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 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 |                   |
     |                  |    Trust      |                   |
     | +-----+          | Relationship  |  +-----+          |
     | | PCA |<===========================>| PCA |          |
     | +-----+          |               |  +-----+          |
     |   ^              |               |    ^              |
     |   | CA-CA Trust  |               |    | CA-CA Trust  |
     |   | Relationship |               |    | Relationship |
     |   v              |               |    v              |
     | +----+           |               |  +----+           |
     | | CA |           |               |  | CA |           |
     | +----+           |               |  +----+           |
     +------------------+               +-------------------+


                Figure 1 - Structure of multi-domain PKI




Shimaoka                                                        [Page 3]

INTERNET DRAFT                                              January 2004



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 EEs in a narrow sense.
     But in a broader sense, PKI sometime means a PKI domain itself.


   CA:   Certification Authority


   EE:   End Entity


   CRL:  Certificate Revocation List


   ARL:  Authority Revocation List


2.2  Terminology


   Relying Party


     Entity who verifies the certificate.  Relying party MUST have one
     or more trust anchors and MAY have a set of validation policies.
     In single-domain PKI, these MAY be omitted implicitly.


   Intermediate Certificate


     Whole certificates in a certification path excepting a trust anchor
     and a target certificate.


   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 unified domain model, unificate CA SHOULD be used as
     defined later in this section.


   PKI domain


     PKI domain is a set of PKIs for identifying the PKI operated on the
     same certificate policy.  Such certificate policy is called a
     "domain policy".  PKI domain MUST have one or more principal CAs
     and SHOULD have one or more domain policy.


   Domain Policy




Shimaoka                                                        [Page 4]

INTERNET DRAFT                                              January 2004



     A common certificate policy (Object Identifier) that is shared in a
     PKI domain.  There can be multiple domain policies in a PKI domain.
     The Object Identifier(s) belonging to a PKI domain is used to
     distinguish that PKI domain from another.  A PKI domain having no
     certificate policy MAY not be identified by the relying party in
     another PKI domain.


   Trust Anchor


     Starting point of a certification path to a subscriber certificate,
     which is specified by a relying party.  If a relying party have to
     perform a validation of the trust anchor, it SHOULD be verified by
     some trustworthy out-of-band procedure, and is not within the scope
     of this memo.  In addition, trust anchor SHOULD be a CA issuing a
     self-signed  certificate for an operational reason, which is
     capable of verifying easily the binding of the private key and the
     public key.


   Trusted PKI domain


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


   Trusting PKI domain


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


   Trust Relationship


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


   Validation parameters


     This is a term for only this document. Five parameters that are a
     subset of the 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
        (f) initial-explicit-policy
        (g) initial-any-policy-inhibit
     As these five parameters MAY NOT be dependent on a built
     certification path and validation time, they SHOULD be bound to a
     trust anchor and are able to be considered without two parameters
     '(a) a prospective certification path of length n' and '(b) the




Shimaoka                                                        [Page 5]

INTERNET DRAFT                                              January 2004



     current date/time'.  These two above mentioned parameters, however,
     are not dependent on a trust anchor, since they each depend on
     certification path or validation time.


   Unificate CA


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


   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.  Trust list is
     used for specifying a trust anchor by a relying party.


   Cross-Certification


     Cross-Ceritification is an issuing certificate to another CA.


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


     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.  There
     SHOULD be different validation policies for every trust anchor.


   Considerations





Shimaoka                                                        [Page 6]

INTERNET DRAFT                                              January 2004



     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 an




Shimaoka                                                        [Page 7]

INTERNET DRAFT                                              January 2004



     easier and 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 EE trusts unknown PKI domain
     irresponsibility.  If EE trusts unknown PKI domains irresponsibly,
     then its issuer CA cannot apply its certificate policy to the EE.
     A trust anchor MAY not apply its validation policy to the EE.


   Considerations


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


3.1.2  Authority Trust List model


   Definition


     The model in which a trust list is managed by the trust anchor of
     relying party.  The trust anchor MAY issue multiple trust lists for
     some purposes or parties.  EEs trusting the same trust anchor may
     share the authority trust list given by the trust anchor.


   Characteristics


     EE does not have control over any trust relationships from its
     trust anchor.  Trust anchor SHOULD control an appropriate trust
     relationship.



   Considerations


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


3.2  Certificate based Trust Relationship


   Definition


     defined in terminology section 2.2


   Requirement


     CA issued the cross-certificate MUST have a self-signed certificate
     except for subordination model.
     If cross-certifying to the CA, issuer CA MUST require the
     responsibility for existing of the CA, like the subordination




Shimaoka                                                        [Page 8]

INTERNET DRAFT                                              January 2004



     model.


   Characteristics


     Cross-Certification is a stricter trust relationship than the trust
     list model, because the trust relationship is represented by a
     certificate and (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.


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


     For PKI issuing Revocation List


        Issuer CA MAY issue Authority Revocation List (ARL), or SHOULD
        at least issue fullCRL.  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 to another CA
     unilaterally.


   Characteristics


     This certification is usable like subordination, but is able to
     establish a more flexible trust relationship than subordination;
     even if the cross-certificate is revoked, subject CA MAY be able to
     continue its operation.




Shimaoka                                                        [Page 9]

INTERNET DRAFT                                              January 2004



     If the PKI use a directory system, the CA MUST generate a
     crossCertificatePair, even if it means unilaterally, 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 requested CA when a cross-
     certification request is stolen by other CA.


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


               Figure 3 - Unilateral Cross-Certification


3.2.2  Mutual cross-certification


   Definition


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


   Characteristics


     Both CAs cross-certify with each other mutually.




Shimaoka                                                       [Page 10]

INTERNET DRAFT                                              January 2004



     for PKI using directory system


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


   Considerations


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


        +---------------+                 +----------------------+
        |     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 special unilateral cross-certification.
   Subordination is to issue a certificate to a CA that has no self-
   signed certificate.


   Definition





Shimaoka                                                       [Page 11]

INTERNET DRAFT                                              January 2004



     The model in which a PKI has always only one superior 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


     Subordination is different from unilateral cross-certification, in
     that this model MUST NOT allow a subordinate CA to be certified by
     more than one issuer CAs.  A subordinate CA MAY NOT require any
     accreditation, rather, the accreditation is required only for the
     superior CA or the top CA.  An existence of the subordinate CA is
     dependent on the superior CA.  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 domains,
     but MAY just allow a subordination to the same PKI domain.  When a
     subordinate CA certificate is revoked by a superior CA, all
     certificates issued by the subordinate CA MUST NOT be trusted.


   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.  When a subordinate CA issues a self-signed
     certificate, the subordinate CA MUST need an agreement from its
     superior CA on issuing the certificate, because certificates issued
     by the subordinate CA will be not constrained by the superior CA.
     When the subordinate CA issues a self-signed certificate, the PKI
     changes from the subordination model into the unified domain model.


4  PKI Domain
4.1  Requirements for PKI domain


   PKIs in a PKI domain SHOULD share one or more certificate policy, and
   the PKI domain MUST have a principal CA.  This shared policy is
   called the "domain policy".  The domain policy SHOULD be described in
   the policyIdentifier of the certificate policies extension for each
   certificate.


   All CAs in a PKI domain MUST be operated under each CP/CPS that
   conform to the domain policy.  All CAs in a PKI domain MUST be able




Shimaoka                                                       [Page 12]

INTERNET DRAFT                                              January 2004



   to issue a verifiable certificate by using the principal CA as the
   trust anchor.


4.2  Risk Analysis of non-interoperable PKI domain


   A PKI domain that satisfies the foregoing requirements MAY be used in
   the multi-trust point model.  However, such requirements are
   insufficient for the single-trust point model.  To use a PKI domain
   under the single-trust point model, more requirements are necessary.


   Therefore, 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 problems will be considered:


     - A lack of the PKI Domain identification method for the third
     party


        All certificates in the PKI domain MAY NOT have the
        identification information of the PKI domain.
        Distinguished Name cannot be used as the identity for the PKI
        domain, because no one administers the name space.


     - Case in which 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 MAY
        fail, because the policy of the relying party is incapable of
        mapping to an appropriate certificate policy.


     If a PKI domain interconnects to another PKI domain, In addition to
     the above requirements in section 4.1, the following consideration
     is necessary.


     - Conflict of a name space


        The name constraints extension MAY not perform the constraint
        that PKI intended, if no one manages a name space.


     - Policy management


        When validating a certification path crossing the PKI domains,
        relying party MAY identify the PKI domains by referring the
        certificate policies extensions.  If the domain policy is not
        described in the certificate policies extension, the path
        validation MAY fail.  Especially the domain policy is necessary
        in the path validation through the PKI that use some constraints
        or policy mapping.





Shimaoka                                                       [Page 13]

INTERNET DRAFT                                              January 2004



     - Authority constrained


        A CA that wants to constrain something for the certification
        path MUST include explicitly the extensions for the constraints
        in the certificates that the CA issues, since that a CA assumes
        the validation policy used by a relying party is difficult.


        For example;
          Alice in PKI domain A: She does not specify an user-initial-
          policy-set.
          Bob in PKI domain B: PKI domain B assumes specifying a certain
          certificate policy (cP-B.1) in the user-intial-policy-set to a
          relying party.  A certificate issued in PKI domain B does not
          include the policyConstraints extension.  Bob's certificate
          includes cP-B.1 in the policyIdentifier of the certificate
          policies extension.


          PKI domain B assumes specifying a certain certificate policy
          in the user-intial-policy-set to a relying party.  a
          certificate issued in PKI domain B does not include the
          policyConstraints extension.  Bob's certificate includes cP-
          B.1 in the policyIdentifier of the certificate policies
          extension.  PKI domain B assumes no using cP-B.1 outside the
          PKI domain B.  Alice can validate successfully the
          certification path to Bob without user-initial-policy-set.  It
          is different from a result to expect of PKI domain B.  Domain
          B has to specify explicit-policy on the certificate to have
          you inspect it according to the expectation of PKI domain B.
          to make a result according to the expectation of the PKI
          domain B, PKI domain B MUST use the requireExplicitPolicy in
          the policy constraints extension of a certificate that PKI
          domain B issues.
          Alice can succeed the certification path to Bob with no
          specified user-initial-policy-set.  It is different from a
          result to expect of PKI domain B.  Domain B has to specify
          explicit-policy on the certificate to have you inspect it
          according to the expectation of PKI domain B.  To make a
          result according to the expectation of the PKI domain B, PKI
          domain B MUST use the requireExplicitPolicy in the policy
          constraints extension of a certificate that PKI domain B
          issues.


4.3  Requirements for multi-domain PKI interoperability


   In multi-domain PKI, there MAY be a PKI domain that assumes requiring
   the explicit policy.  To validate correctly such certification path,
   the following requirements are necessary for the PKI domains:





Shimaoka                                                       [Page 14]

INTERNET DRAFT                                              January 2004



     - All CAs in a PKI domain that has explicit domain policy as
     policyIdentifier SHOULD be able to issue a certificate which is
     verifiable with the following validation policy:
          * user-initial-policy-set which includes its own
          domainPolicyId.
          * initial-explicit-policy set to TRUE.
          * trust anchor which is the principal CA of its PKI domain.


     - Each PKI domain SHOULD show the trust relationship with other PKI
     domains as follows:
          * Trusted PKI domain SHOULD show to the trusting PKI domain
          what kind of PKI it includes.
          * Trusted PKI domain SHOULD show to trusting PKI domain what
          kind of other PKI domains it trusts.
          * Trusted PKI domain MAY publish to the trusting PKI domain
          what kind of other PKI domains it is trusted by.


   In addition, the following requirements MAY be necessary for the
   certificate based trust relationship.


     SHOULD give an appropriate policy mapping between the trusting PKI
     domain and the trusted PKI domain for certificate based trust
     relationship.


5  Single-domain PKI


   This section describes 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 PKI model


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


   Definition


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


   Trust anchor


     The trust anchor MUST be the single self-signed CA.


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




Shimaoka                                                       [Page 15]

INTERNET DRAFT                                              January 2004



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


   Trust anchor


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


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





Shimaoka                                                       [Page 16]

INTERNET DRAFT                                              January 2004



5.3  Mesh PKI model


   Definition


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



   Trust anchor


     The trust anchor for a relying party SHOULD be a CA who issued it a
     certificate.


   Considerations


     A trust anchor SHOULD be self-signed CA by some reason on the
     operation.  For example, a self-signed CA is verifiable about the
     binding of the private key and the public key by itself.
     This model SHOULD be avoided as possible, because it may be complex
     to the certification path building.  However, do not assume that
     there is not this model.
     Full Mesh PKI MAY be useful conversely for the certification path
     building, because it is able to reach certainly to the trusting PKI
     domain with one path.


             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




Shimaoka                                                       [Page 17]

INTERNET DRAFT                                              January 2004



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


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


     A CA in the existing certification path SHOULD NOT be added to the
     trust list, since a constraint in the certification path MAY not be
     evaluated correctly.


     Most of the actual public PKIs establish a multi-trust point model
     without a domain policy.  When using such public PKI, 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 EEs when the CA is compromised.  In the multi-trust point
     model, a compromised trust anchor SHOULD be removed from the trust
     list, and the removing SHOULD be performed by the subject of
     managing the trust list.


6.1.1  Based on User Trust List


   Considerations





Shimaoka                                                       [Page 18]

INTERNET DRAFT                                              January 2004



     This is an easier and typical method for making a trust
     relationship to another PKI domain.  The relying party MUST
     understand a 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, 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, a trust anchor is only one.


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


     For example, when each PKI domain wants to effect always 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 can not effect
     the constraints always.


6.2.2  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 a method
   to unify or fake the multiple PKI domains to one PKI domain, or is a
   method for transforming from subordinaion.  Except for that there is
   a self-signed certificate as the intermediate certificate, this model
   looks like a subordination model.  Therefore, often this model is
   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 |---+
                 |         +--------------+   |
                 |                 |          |
                 |  cross-certified|          |




Shimaoka                                                       [Page 19]

INTERNET DRAFT                                              January 2004



                 |   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.3  Bridge model


   The model in which every PKI domain trust each other through a Bridge
   CA by Cross-Certification.  In this model, 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-certification.


   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 it 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 trusting PKI domain and a trusted PKI domain.
     - The domain policy of Bridge CA MUST be a subset of the trusting
     PKI domain policy that is mapped.
     - The domain policy of Bridge CA MUST be a superset of the trusted




Shimaoka                                                       [Page 20]

INTERNET DRAFT                                              January 2004



     PKI domain policy that is mapped.


        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-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 policyConstaints extension.
     - Cross-certificate issued to Bridge CA SHOULD include the
     requireExplicitPolicy with a value that is greater than zero in the
     policyConstratints extension.
     - Cross-certificate issued by Bridge CA SHOULD NOT include any
     constraints to keep its transparency.
     - 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 neutral trusted third party.
     The Bridge CA SHOULD do policy mapping appropriately with both PKI
     domains.  For using the name constraints, 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 Bridge CA
     SHOULD confirm the following:


        - Does the trusted third CA perform the policy mapping via its
        own domain policy?
        - Does the trusted third CA clarify the method of policy mapping
        in cross-certification?
        - Is the trusted third CA able to accept the domain policy that
        the trusting PKI domain desires?
            * If the domain policy is mapped to one with a lower
            security level, the trusting PKI domain MUST NOT accept it.


         cross-certified                 cross-certified
         PKI 1 with BCA   +-----------+  PKI3 with BCA
                 +------->| Bridge CA |<------+
                 |        +-----------+       |




Shimaoka                                                       [Page 21]

INTERNET DRAFT                                              January 2004



                 |                 ^          |
                 | 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 point that you should pay attention to
   about management of a mutual certification certificate and use of a
   directory.


7.1 Directory



   (1) Unilateral cross-certification


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


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


              issuedToThisCA := NULL




Shimaoka                                                       [Page 22]

INTERNET DRAFT                                              January 2004



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


           CA-Y MAY generate a 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.


7.2 Cross-Certification





Shimaoka                                                       [Page 23]

INTERNET DRAFT                                              January 2004



   When updating 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
        the cross-certificate.


        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 populate it to their own
        directory system.  Until this is done, change of cross-
        certification is not reflected completely to certification path.
        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
        either.


   When updating the CA keypair


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


        When a CA keypair is compromised, the CA DN SHOULD NOT be re-
        used by the same CA without issuing the self-issued certificate.


   When the keypair of subject CA is compromised


        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 CA-Y from its
        repository.


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 multi-domain PKI SHOULD consider the following for the Certificate
   and CRL profile:


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


     * The cRLDistributionPoint extension SHOULD be used for obtaining




Shimaoka                                                       [Page 24]

INTERNET DRAFT                                              January 2004



     the revocation list.  distributionPoint field SHOULD include also
     the UniformResourceIdentifier.  When the CRL is separated into CARL
     and EPRL, 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 the 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
     anyone.


        If a PKI domain use the name constraints in multi-domain PKI,
        the PKI domain SHOULD pay attention to preventing a conflict of
        each name space.


8.2  Path Validation


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


   A Relying party MUST carefully determine their validation parameters,
   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 a different trust relationship.


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




Shimaoka                                                       [Page 25]

INTERNET DRAFT                                              January 2004



   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 results 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 the certification path to loop, then cP-1.1
   is mapped to cP-1.2, and such a policy mapping MAY derive 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 same PKI actually describes
   different policies, differing policy identifiers mapped unexpectedly
   in the same entity represents an 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]  ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information
                  Technology - Open Systems Interconnection: The Directory:
                  Authentication Framework," 2001 edition.


9.2  Informative References


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




Shimaoka                                                       [Page 26]

INTERNET DRAFT                                              January 2004



      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.



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


11  Author's Address


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




Shimaoka                                                       [Page 27]

INTERNET DRAFT                                              January 2004



   Mitaka, Tokyo JAPAN


   Email: shimaoka@secom.ne.jp




12  Full Copyright Statement


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

































Shimaoka                                                       [Page 28]


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