view Side-By-Side changes
Network Working Group M. Shimaoka Request for Comments: DRAFT SECOM Trust.net<draft-shimaoka-multidomain-pki-01.txt> October 2003<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(2003).(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 oncross-certification.cross-certification model. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2 Requirements and Assumptions . . . . . . . . . . . . . . . . . 3 2.1 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . .34 2.3 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . .56 3 Trust Relationship . . . . . . . . . . . . . . . . . . . . . . .56 3.1 Trust List . . . . . . . . . . . . . . . . . . . . . . . . . .56 3.1.1 User Trust List . . . . . . . . . . . . . . . . . . . . . . .67 3.1.2 Authority Trust List . . . . . . . . . . . . . . . . . . . .78 3.2 Cross-Certification . . . . . . . . . . . . . . . . . . . . . .78 3.2.1 Unilateral Cross-Certification . . . . . . . . . . . . . . .89 3.2.2 Mutual Cross-Certification . . . . . . . . . . . . . . . . .1011 3.3 Subordination (Hierarchy) . . . . . . . . . . . . . . . . . . . 12 4 PKI Domain . . . . . . . . . . . . . . . . . . . . . . . . . . .13 SHIMAOKA14 Shimaoka [Page 1] INTERNET DRAFTOctober 2003January 2004 4.1 Requirements for PKI domain . . . . . . . . . . . . . . . . . .1314 4.2 Risk Analysis of non interoperable PKI domain . . . . . . . . .1314 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(based on Trust List). . . . . . . . . . . . . . . . . . . . 18 6.1.1 Based on User Trust List . . . . . . . . . . . . . . . . .1819 6.1.2 Based on Authority Trust List . . . . . . . . . . . . . . . . 19 6.2 Single Trust Point model(based on Cross-Certification). . . . . . . . . . . . . . . . . . . 19 6.2.1 Peer-to-Peer model(based on Cross-Certification). . . . . .19. . . . . . . . . . . . . . . 20 6.2.2SuperUnified Domain model(based on unilateral Cross-Certification). 19. . . . . . . . . . . . . . . . . . . . 20 6.2.3 Hub model (a.k.a Bridge CA) . . . . . . . . . . . . . . . . .2021 6.2.4 Considerations for trusted third CA . . . . . . . . . . . . . 22 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 23 7.1 Certificate and CRL Profile . . . . . . . . . . . . . . . . . . 23 7.2 Repository . . . . . . . . . . . . . . . . . . . . . . . .2324 7.3 Path Validation . . . . . . . . . . . . . . . . . . . . . . . . 24 7.4 Public PKI and Private PKI . . . . . . . . . . . . . . . . . . 24 7.5 Asymmetric problem . . . . . . . . . . . . . . . . . . . . . .24 7.4.125 7.5.1 Hybrid trust model . . . . . . . . . . . . . . . . . . . . .24 7.4.225 7.5.2 Asymmetric policy mapping . . . . . . . . . . . . . . . . . .2425 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . .2426 8.1 Normative References . . . . . . . . . . . . . . . . . . . . .2426 8.2 Informative References . . . . . . . . . . . . . . . . . . . .2526 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . .2527 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . .2527 11 Full Copyright Statement . . . . . . . . . . . . . . . . . . . .2527 1 Introduction PKI is able toachieverealize 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-SHIMAOKA [Page 2] INTERNET DRAFT October 2003domain 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. Section56 profiles multi-domain PKI asmulti trustmulti-trust point model andsingle trustsingle-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,superunified domain model and hub model. Finally, section67 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 ListARL: Authority Revocation List SHIMAOKAShimaoka [Page 3] INTERNET DRAFTOctober 2003January 2004 ARL: Authority Revocation List 2.2 Terminology Subscriber Holder of the certificate which is verified. Relying Party Entity who verifies the certificate.At least, relyingRelying party MUST haveonea set ofatrustanchoranchors andanMAY have a set of acceptable certificatepolicy.policies. InSingle domainsingle-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 onecommon policyprincipal CA and SHOULD have more than oneprincipal CA. Thiscommon certificate policy. Such common policy is named as "domain policy".Essentially, PKI domain is only a view from relying party outside of subscriber domain.Domain Policy More than one common certificate policy (Object Identifier) which shared in a PKI domain.Trust Point Starting point of a certification pathThis Object Identifier is used toSUBSCRIBER certificate. Trust Point MUST bedistinguish 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 PKIdomain.domain directly. Principal CA SHOULD issue a self-signed certificate. Shimaoka [Page 4] INTERNET DRAFT January 2004 Trusted PKI domain PKI domain which is trustedby trustyfrom trusting PKI domain. Usually, trusted PKI domain means a PKI domain of subscriber.TrustyTrusting PKI domainSHIMAOKA [Page 4] INTERNET DRAFT October 2003PKI domain which trusts other PKI domains. Usually,trustytrusting PKI domain means a PKI domain of relying party. Trust Anchor Trust anchor is a principal CA inRELYING PARTYrelying 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 documentdodoes not specify whether the repository is web server or directory server. 3 Trust Relationship This section describes major trust relationships for pluralPKIPKI(CA) interconnection. All PKIs that are going to participate in multi- domain PKI SHOULD use these trust relationships for multi-domain PKI interoperability.SHIMAOKA [Page 5] INTERNET DRAFT October 20033.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. ConsiderationsTBDIn 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 modelSHIMAOKA [Page 6] INTERNET DRAFT October 20033.1.1 User Trust List Definition The model in which a trust list is managed by End Entitiy (EE). EE is able to haveitsown user trust list individually. Shimaoka [Page 7] INTERNET DRAFT January 2004 Advantage EE is able to manageitsown user trust list. EE is able to addanya "trusted CA" certificate toitsown 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 theirsecuritycertificate 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.AllThe trust anchor MAY issue plural trust list for some purpose or some parties. EEs who share the same trust anchorSHOULDMAY 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. DisadvantageManagementIn Internet PKI, there is no standard to use this model. And, management method for authority trust list is notestablished.established generally. ConsiderationsTo consider about a format of the authority trust list thatThis isable to be processed by various applications. To consider about a management methodjust theory forthe authoritycomparison with user trustlist. SHIMAOKAlist model. Since there is no standard, this model MAY NOT achieve interoperability sufficiently. 3.2 Cross-Certification Shimaoka [Page7]8] INTERNET DRAFTOctober 2003 3.2 Cross-CertificationJanuary 2004 Definition Cross-Certification is an issuing certificate to another"trusted CA".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. ConsiderationsforFor path constructionSubjectBecause 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.IssuerThen, issuer CA SHOULD issue across-certificatecross- certificate which contains subjectKeyIdentifier set to the same value in the corresponding cross-certification request.forFor 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 CAKey Rollover TBDkeypair 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-certificationSHIMAOKA [Page 8] INTERNET DRAFT October 2003Definition 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 trustrelationship.relationship than subordination. Even ifcross- certificatecross-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.If a cross-certification request is got by any CA,Note that unilateralcross- certificationcross-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 serveras below. CA-X SHOULD generate a following crossCertificatePair and store it in its 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 its own directory entry. issuedToThisCA := cross-certificate for CA-Y issued by CA-X issuedByThisCA := NULL the following is TBD. - Considerations for updating the keypair of CA-X * When CA-X keeps the cross-certification with CA-Y * When CA-X do not keep the cross-certification with CA-Y SHIMAOKA [Page 9] INTERNET DRAFT October 2003 - Considerations for updating the keypair of CA-Y * When CA-X keeps the cross-certification with CA-Y * When CA-X do not keep the cross-certification with CA-Y - Considerations for compromising the keypair of CA-X - Considerations for compromising the keypair of CA-Yas below. CA-X SHOULDrevoke thegenerate a following crossCertificatePair and store it in own directory entry. issuedToThisCA := NULL issuedByThisCA := cross-certificate forCA-Y, thenCA-Y issued by CA-XMUST remove theCA-Y SHOULD generate a following crossCertificatePairattributeand store it in own directory entry. issuedToThisCA := cross-certificate fortheCA-Yfrom its repository.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 DisadvantageSHIMAOKA [Page 10] INTERNET DRAFT October 2003for 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 initsown 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 initsown 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.the following is TBD. - Considerations for updating the keypair of CA-X * When CA-X keeps the cross-certification with CA-Y * When CA-X do not keep the cross-certification with CA-Y - Considerations for updating the keypair of CA-Y * When CA-X keeps the cross-certification with CA-Y * When CA-X do not keep the cross-certification with CA-Y - Considerations for compromising the keypair of CA-X - Considerations for compromising the keypair of CA-Y CA-XEach CA SHOULDrevoke the cross-certificate for CA-Y, then CA-X MUST remove theNOT generate two crossCertificatePairattribute for the CA-Y from its repository. SHIMAOKA [Page 11] INTERNET DRAFT October 2003like 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.InSubordination is different from unilateral cross-certification,subjectthis model MUST NOT allow that a subordinate CAMAY have someis 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 beSHIMAOKA [Page 12] INTERNET DRAFT October 2003trusted easily by all EEs who trust the superior CA. Disadvantage Subordinate CA MUST NOT cross-certify anyCAs ,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 thesecuritycertificate 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 initsown (superior CA) entry, because path constructionwill work inefficiently.becomes non- efficiency. Subordinate CA MAY storeitsown subordinate CA certificate to issuedToThisCA element of crossCertificatePair attribute initsown (subordinate CA) entry. Subordinate CA MUST storeitsown subordinate CA certificate to cACertificate attribute initsown 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 onecertain commonshared certificate policy and more than one principal CA. Thiscommonshared policy is named as "domain policy". All CAs in a PKI domain MUST be operated by each CP/CPS which is conformed to thecommondomain 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 informationSHIMAOKA [Page 13] INTERNET DRAFT October 20034.2 Risk Analysis of non interoperable PKI domain A PKI domain that satisfies theaboveforegoing 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 haveno identity necessarilyan 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-setis includingwhich includes own domainPolicyId. * initial-explicit-policyisas 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.SHIMAOKA [Page 14] INTERNET DRAFT October 2003(1) Single-trust point model SHOULD give an appropriate policy mapping between thetrustytrusting 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 architecturesforto establish a single PKI domain. All PKIs that are going to participate inmulti-domainmulti- 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 ofset ofthis. Definition Single PKI is composed of an onlytopsingle CA and its EEs. All EEs SHOULD trust only thetopCA. All subscribers MUST be issued their certificate bytheonlytopthe CA. Principal CA Principal CA MUST be thetopsingle CA. Shimaoka [Page 16] INTERNET DRAFT January 2004 Trust anchor Trust anchor MUST be thetopsingle CA. +----+ +---| CA |---+SHIMAOKA [Page 15] INTERNET DRAFT October 2003| +----+ | | | | | | | 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 aToptop 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. +---------+ +---|roottop 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 +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+SHIMAOKA [Page 16] INTERNET DRAFT October 2003| 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 torelying party.them. Considerations All EEs MUST trust only a CA that issued their own certificate.Which SHOULD beDetermine a principal CA for foreign PKIdomain?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 | +----+ +----+ +----+ +----+ +----+SHIMAOKA [Page 17] INTERNET DRAFT October 2003Figure 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.AllTo achieve interoperability, all PKIs that compose multi-domain PKI SHOULDadopt any models of theapply followingfor multi-domain PKI interoperability.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-partyRelying party is able to use trust list for specifying the trust point in other PKI domains. Trust listisMUST 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 aprincipal CArevocation of CA's self-signed certificatein another domain. Considerations Theis difficult, CAin a trustSHOULD announce it to all EE when CA is compromised. In multi-trust listSHOULD not cross-certifymodel, eachother. The validation parametersCA SHOULDbe givenannounce it toeach trust point individually.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 andtypicallytypical method for making a trust relationship to other PKI domain.Relying-PartyRelying Party is able to establish trust relationship with other PKI domain irresponsibly to his trust anchor.WhenRelying party MUST notice whether each CA certificates as trust point updatedthe certificates, what relyingor are revoked. Relying partyrecognizes it is difficult. Relying-partyMAY need to obtain some inputs, e.g., user-initial-policy-set,initial-policy-mapping- inhibit,initial-policy-mapping-inhibit, initial-explicit-policy and initial-any-policy-inhibit,SHIMAOKA [Page 18] INTERNET DRAFT October 2003for path validation from somewhere. 6.1.2 Based on Authority Trust ListAuthority MAY distribute the validation parameters by includingSince there is no standard or established method, this memo does not recommend using this model inthe trust list. Considerations 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.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 forindicatingacrossing differentdomain.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.2SuperUnified Domain model (based on unilateral Cross-Certification)SHIMAOKA [Page 19] INTERNET DRAFT October 2003The model in which plural PKI domains have acommonjoint 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 onecommonshared 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 usedaslike hierarchy model in multi-domain PKI. cross-certified cross-certifiedTopUnificate CA to PKI 1+--------+ Top+--------------+ Unificate CA to PKI 3+-----------| Top+---------| Unificate CA|-------+ | +--------+|---+ | +--------------+ | | | |cross-certified| cross-certified| | |TopUnificate CAto PKI 2| | | 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 -SuperUnified 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.SHIMAOKA [Page 20] INTERNET DRAFT October 2003Requirements for Hub model - Bridge CA MUST NOT be used as the trust anchorforin 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 certificateexceptexcepting 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 atrustytrusting PKI domain and a trusted PKI domain.Trusty Domain PolicyCross-Certificate from Trusting PKI domain to Bridge CA issuerDomainPolicy := Trusting PKI domain policy subjectDomainPolicy := BridgeDomain PolicyCA domain policy Cross-Certificate from BridgeDomain PolicyCA to Trusted PKI domain issuerDomainPolicy := Bridge CA domain policy subjectDomainPolicy := TrustedDomain PolicyPKI domain policy - Cross-Certificate issued by Bridge CA and Cross-Certificate issued to Bridge CA SHOULD include the requireExplicitPolicy more than equal zero inpolicyonstaintspolicyConstaints extension. -Trusty PKI domain MUSTTo trust a trusted PKI domain, trusting PKI domain MUST do viaBridge CA.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 thatcross-certified tocross-certifies with Bridge CA SHOULD NOT use nameConstraints extension because they cannot limit name-spaces via Bridge CA. Bridge CA MUST have an independent certificatepolicy,policy from both PKI domain, and MUST use it for policymapping for both domains.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 |<--+ | | | +-----+ | | +-----+ | | +-----+ | | | | | | | | | | ^ | |SHIMAOKA [Page 21] INTERNET DRAFT October 2003| | | | | | | | | 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, andTopUnificate CA inSuperUnified domain model). Shimaoka [Page 23] INTERNET DRAFT January 2004 (1) Advantage of using trusted third CA -TrustyVia trusted third CA, trusting PKI domain candeployautomaticallythedeploy trusted PKIdomaindomains thathas corresponding security level of ownhave mappable domain policy. -TrustyTrusting PKI domain canpublish aopen its security level of own domain policy bycross-certificationcertifying with trusted third CA. * This means that thetrustytrusting PKI domain passed the criteria for the cross-certification of the trusted third CA. * This means that thetrustytrusting 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 CAby PKI domain- Does the trusted third CA do the policy mapping viaitsown 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 thetrustytrusting PKI domain desired?SHIMAOKA [Page 22] INTERNET DRAFT October 2003* If the domain policy is mapped to lower security level,trustytrusting domain MUST NOT accept it. *TrustyTrusting PKI domain SHOULD requestthat trusted third CA accept the enoughsufficient policy controlto achievefor maintaining its security level. (3) Considerations If trusted third CA cannot keep neutrality,trusty PKItrusting domain will cross-certify with PKI domain that is lower security level. 7 Security Considerations 7.1 Certificate and CRL ProfileTo defineDefining 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 insingle trustsingle-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 DistributionSHIMAOKA [Page 23] INTERNET DRAFT October 2003Points 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 problem7.4.17.5.1 Hybrid trust modelThis clause considersThis 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 caseofthat PKIdomainsdomain-X trusts PKI domain-Y by user trusteach otherlist model and PKI domain- Y trusts PKI domain-X bydifferentunilateral cross-certification, PKI domain-X has merely to comply with user trustrelationship. TBD 7.4.2list 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 mappingTBDWhen 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[PKIX][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.[INTEROP] Lloyd, S., PKI Forum, "PKI Interoperability Framework", March 2001. [CA-CA] Lloyd, S., PKI Forum, "CA-CA Interoperability", March 2001. SHIMAOKA [Page 24] INTERNET DRAFT October 2003[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 ReferencesTBDHousley, 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(2003).(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, thisSHIMAOKA [Page 25] INTERNET DRAFT October 2003document 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.SHIMAOKAShimaoka [Page26]29] ----