Network Working Group M. Shimaoka Request for Comments: DRAFT SECOM N. Hastings NIST January 2005 Memorandum for multi-domain Public Key Infrastructure (PKI) Interoperability Status of this Memo By submitting this Internet-Draft, each author certifies that any applicable patent or other IPR claims of which he or she is aware have been disclosed, or will be disclosed, and any of which he or she is become aware will be disclosed, in accordance with RFC 3668. By submitting this Internet-Draft, each author accepts the provisions of Section 3 of RFC 3667. 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." This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on July 10, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Shimaoka, et al. [Page 1] INTERNET DRAFT January 2005 Abstract This memo is intended to describe the foundation necessary to the deployment of a multi-domain PKI. The scope of this memo is to establish and clarify the trust relationships and interoperability between multiple PKI domains. A Certification Authority (CA) is able to extend a certification path by establishing trust with other CAs. Both single- and multi-domain PKIs are established by such trust relationships between CAs. Typical and primitive PKI model is a single-domain PKI that shares the same certificate policy at a specified trust level. A multi-domain PKI is established by combining more than one single-domain PKI. A multi-domain PKI can be categorized as either a multi-trust point model based on the trust list model; or single-trust point model based on the Cross- Certification model. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 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 Shimaoka, et al. [Page 2] INTERNET DRAFT January 2005 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 1 Introduction PKI is extendable to realize various architectures, through the way in which CAs establish trust relationships with each other. When a CA wishes to establish a trust relationship with another CA, the CAs MUST compare the security requirements defined in their certificate policies since certificate policies vary greatly across CAs. Those CAs should choose an appropriate trust relationship which satisfies both security requirements, as a result of that comparison. To establish appropriate trust relationships, full understanding of the relationship between the establishment method and comparison is required. In addition, all established trust relationships fall into one of two categories: a single- or multi-domain PKI. In order to establish trust relationships between CAs, technology, such as protocol specifications and data formats, alone is insufficient. The existing protocol specifications and data formats do not define the PKI architectures and boundary of the PKI domains, designing them are left up to the individual PKIs. Therefore, an understanding of the CAs' PKI architectures and domains are required to determine the appropriateness of establishing the trust relationship. This document clarifies 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 PKIs. Section 6 profiles multi-domain PKIs as multi-trust point model and single-trust point model. Multi-trust point model is based on trust list model. Single-trust point model is based on the cross-certification model, and is categorized as peer model, unified domain model and hub model. Finally, section 7 describes considerations focused on Certificate and Certificate Shimaoka, et al. [Page 3] INTERNET DRAFT January 2005 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 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 CA: Certification Authority EE: End Entity CRL: Certificate Revocation List ARL: Authority Revocation List PCA: Principal Certificate Authority RP: Relying Party CP: Certificate Policy CPS: Certification Practice Statement DN: Distinguished Name Shimaoka, et al. [Page 4] INTERNET DRAFT January 2005 2.2 Terminology Subscriber Holder of the verified certificate. End Entity (EE) The definition of EE prefers X.509 4th edition to RFC 2828, since X.509 defines more clearly about relying party. That is, a certificate subject that uses its private key for purposes other than signing certificates or an entity that is a relying party [sic]. Relying Party (RP) Entity who verifies the certificate. RP MUST have one or more trust anchors and MAY have a set of validation policies. In single-domain PKI, these MAY be omitted implicitly. Responsible EE Responsible EE directly trusts the CA that issued a self-signed certificate used as a trust anchor and has been issued a certificate by the CA under its subscriber agreement. Responsible EE assumes a responsibility based on a contract with the trust anchor, and has some rights from the trust anchor. For example, the responsible EE is issued its certificate by the contract with the trust anchor, and must specify a certain validation policy in the path validation. Irresponsible EE Against a responsible EE, Irresponsible EE trusts directly the trust anchor but has no contract with the trust anchor. In other words, irresponsible EE trusts the trust anchor one-sidedly. Subscriber An entity that is the subject identified within a public key certificate issued by a certificate authority of a PKI. Subscriber Agreement A document used to describe the rights, obligations, and responsibilities of a subscriber to a PKI. This may take the form of a contract. Shimaoka, et al. [Page 5] INTERNET DRAFT January 2005 Intermediate Certificate Certificates in a certification path except the trust anchor and target certificate. PKI domain The word "PKI domain" is used to represent and identify a set of PKIs which share the same trust level. The scale of the PKI domain MAY vary by the required trust level. For example, a PKI domain which requires the high trust level may be quite narrow and a PKI domain which requires the low trust level may be broad. PKI domain is established by the specific trust relationship which is achieved by the agreement on the certificate policy representing the shared trust level. Domain Policy A common certificate policy or agreed upon certificate policy that are shared in a PKI domain. When the PKIs in a PKI domain can share the multiple certificate policies of different levels, there can be multiple domain policies within the 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. 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 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. Shimaoka, et al. [Page 6] INTERNET DRAFT January 2005 Trust Anchor Starting point of a certification path to a subscriber certificate, which is specified by a relying party. If a relying party has 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. Posterior PKI domain This word is used to describe the relative trust relationship of adjoined PKI domain in the certification path, in combination with the word "prior PKI domain". This is a posterior (next) PKI domain in the certification path from the trust anchor to the target certificate. That is, the posterior PKI domain is trusted from the prior PKI domain. Prior PKI domain This word is used to describe the relative trust relationship of adjoined PKI domain in the certification path, in combination with the word "posterior PKI domain". This is a prior (previous) PKI domain in the certification path from the trust anchor to the target certificate. That is, the prior PKI domain trusts the posterior PKI domain. First prior PKI domain in the certification path means the PKI domain trusted directly by a relying party. Trust Relationship Generally, trust relationship in PKI means a relationship between each CA or between CA and EE. In this document however, this means a trust relationship between CAs. This relationship is required for tracing trust from a trust anchor to a subscriber. Validation policy The concept of this is defined in RFC 3379. In this document, the items which should be focused on are the following. (c) user-initial-policy-set (d) trust anchor information, (e) initial-policy-mapping-inhibit (f) initial-explicit-policy (g) initial-any-policy-inhibit Shimaoka, et al. [Page 7] INTERNET DRAFT January 2005 These are parts of input for the path validation, which is defined in RFC 3280 section 6.1.1. The reason why this document focuses on these items is that these values may be different depending on each trust anchor. Principal CA CA which has a self-signed certificate and is trusted from the other PKI domain. The reason why a principal CA has a self-signed certificate is the principal CA must be independent from all other certification including inside of its PKI domain. Unificate CA CA which has a self-signed certificate and issues unilateral cross- certificates to each principal CA of other posterior PKI domains. Unificate CA is specified as a trust anchor for the PKI domains that are cross-certified with it. Trust List Trust list is a list of one or more trust anchors, which MAY be a set of the trust anchor certificates in general. Otherwise, it MAY be a set of public keys or Distinguished Names. Trust list is used for specifying a trust anchor by a relying party. Subordination Subordination is a mechanism to authorize the existence of a subject CA. The authorization of the existence means issuing a certificate called esubordinate (CA) certificatef to a CA who has no certificate. Cross-Certification Cross-certification is a mechanism to recognize the existence of a subject CA. The recognition of the existence means issuing a certificate called ecross-certificatef to a CA who has another certificate already. In this document, this wording is more limited than the definition in RFC 2828. That is, cross- certification in RFC 2828 means mutual cross-certification, but cross-certification in this document allows unilateral cross- certification. 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 Shimaoka, et al. [Page 8] INTERNET DRAFT January 2005 repository is web server or directory server. 3 Trust Relationship This section describes major trust relationships for multiple PKI(CA) interconnections. All PKIs that are going to participate in multi- domain PKI SHOULD use these trust relationships for multi-domain PKI interoperability. 3.1 Operation based Trust Relationship Definition Trust List is defined in terminology section 2.2. Requirements CAs on the same trust list SHOULD NOT cross-certify each other. All relying parties in this model MUST have a trust list. There SHOULD be different validation policies for every trust anchor. Considerations 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 |---+ | | | Shimaoka, et al. [Page 9] INTERNET DRAFT January 2005 | | | | | +----+ | | | +----+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 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 Shimaoka, et al. [Page 10] INTERNET DRAFT January 2005 EE does not have control over any trust relationships from its trust anchor. Trust anchor SHOULD control an appropriate trust relationship with other CAs keeping the same security level. Considerations Since there is no standard for the use of this model, management methods for authority trust list are not established. In generally, this model MAY not achieve sufficient interoperability. 3.2 Certificate based Trust Relationship Certificate based trust relationship is realized by the cross- certification unilaterally or mutually. Definition Cross-certification is defined in terminology section 2.2. Requirement A subject CA in the cross-certification MUST have a certificate other than the cross-certificate. Characteristics Cross-Certification is a more formal expression of the trust relationship than the trust list model, because the trust relationship is represented by a certificate 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. A PKI which issues a cross-certificate SHOULD have a repository and CA SHOULD publish the cross-certificate to a relying party. The formal way to publish the cross-certificate is to use the crossCertificatePair attribute with the directory server like a LDAP. At least, a PKI which issues a cross-certificate MUST provide a mechanism for obtaining the cross-certificate to a relying party, like a caIssuers in accessMethod of the AIA extension. Considerations A subject CA which has not a self-signed certificate has been authorized by another CA. This means the issuer CA of the cross- Shimaoka, et al. [Page 11] INTERNET DRAFT January 2005 certificate may not be able to recognize the existence of the subject CA. Therefore, this document strongly recommends that a subject CA SHOULD have a self-signed certificate. Especially for the inter-domain cross-certification, this document recommends that issuer CA SHOULD accept and agree on the way the subject CA is operated. For path construction Because the key identifier of each CA MAY be calculated differently, subject CA SHOULD issue a cross-certification request that contains subjectKeyIdentifier in extensionRequest, with a value that MUST be identical to the subjectKeyIdentifier in the self-signed certificate. Then, issuer CA SHOULD issue a cross-certificate with the subjectKeyIdentifier set to the same value in the corresponding cross-certification request. For PKI issuing Revocation List Issuing CAs MAY issue Authority Revocation Lists (ARLs), or SHOULD at least issue fullCRLs. However, ARL with an issuingDistributionPoint extension MAY NOT be processed by some applications. 3.2.1 Unilateral cross-certification Definition The model in which a CA issues a cross-certificate unilaterally to another CA which has a self-signed certificate. Characteristics This certification is used like subordination, but is able to establish a more flexible trust relationship than subordination; even if the cross-certificate is revoked, subject CA MAY be able to continue its operation. If the PKI uses a directory system, the CA MUST populate a crossCertificatePair, even when the cross-certification is unilateral, to avoid being categorized as subordination. Considerations Subordination is a special case of unilateral cross-certification. Note that unilateral cross-certification is easily established without an agreement from the subject CA because a cross- Shimaoka, et al. [Page 12] INTERNET DRAFT January 2005 certificate can be issued from the public key of the subject CA. In the example of figure 3 below, RPs who use the PCA of PKI 1 as the trust anchor can trust EEs of PKI 2 not only EEs of PKI 1. And RPs who use the PCA of PKI 2 as the trust anchor cannot trust EEs of PKI 1. This configuration means helping RPs who use PCA of PKI 1 to interoperate with EEs of PKI 2, but not vice versa. +---------------+ +----------------------+ | PKI 1 | | PKI 2 | | | cross-certified | | | +-----+ | PKI 1 to PKI 2 | +-----+ | | | PCA |--------------------------->| PCA |<--+ | | +-----+ | | +-----+ | | | | | | ^ | | | | | | | v | | | | | | +----+ | | | | | | | 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 self-signed CA issues a cross-certificate to the other self-signed CA, and vice versa. Characteristics Both CAs cross-certify with each other mutually. For PKI using directory system Both CAs MUST generate a crossCertificatePair that consists of Shimaoka, et al. [Page 13] INTERNET DRAFT January 2005 the cross-certificate it issued to the other CA and the corresponding cross-certificate that it was issued by the other CA. When either CA updates a cross-certificate, each CA MUST re-generate their crossCertificatePair synchronously. If re-generating asynchronously, the result of the path validation may differ by the method of path building, such as forward path building and reverse path building. Considerations Both CAs MUST 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. Definition The model in which a CA issues a certificate to a CA which has no Shimaoka, et al. [Page 14] INTERNET DRAFT January 2005 self-signed certificate. The model in which a PKI has always only one root CA. Requirements A subordinate CA MUST have only one superior CA and be managed by the superior CA strictly. A subordinate CA MUST never issue its self-signed certificate. Characteristics EEs can trust all following subordinate CA and its EEs by trusting only the root CA. Subordination is different from unilateral cross-certification, in that this model MUST NOT allow a subordinate CA to be issued a certificate by more than one issuer CAs. A subordinate CA MAY NOT require an accreditation necessarily, such as WebTrust or license under the e-signature law. The accreditation is rather required only for the superior CA or the root CA. In this case, accreditation means that the subordinate CA can succeed the benefit on the trustworthiness of the superior 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 within the same PKI domain. When a subordinate CA certificate is revoked by a superior CA, all certificates issued by the subordinate CA are also invalid. Considerations A subordinate CA MUST NOT override the constraints given by the superior CA. Subordination MUST be used only in single-domain PKI, not multi-domain PKI. The violation with issuing a self-signed certificate to a subordinate CA may be considered as the following two cases. If the subordinate CA issues a self-signed certificate, and if RPs change their trust anchor from the original root CA to the former subordinate CA, the entities which the RPs can trust will shrink to only under the former subordinate CA. If the subordinate CA issues a self-signed certificate, but if RPs do not change their trust anchor (original root CA), the entities which the RPs can trust will still be same but the trust Shimaoka, et al. [Page 15] INTERNET DRAFT January 2005 relationship will change 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 ACPS that conforms to the domain policy. All CAs in a PKI domain MUST be able to issue a certificate including a valid policy. 4.2 Risk Analysis of non-interoperable PKI domain A PKI domain that satisfies the requirements presented in the sections ??? of this document 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 policies, 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 Shimaoka, et al. [Page 16] INTERNET DRAFT January 2005 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. - Authority constrained A CA that wants to assert constraints for the certification path MUST include explicitly the extensions for the constraints in the certificates that the CA issues, since that CA assumes the validation policy used by a relying party which MAY NOT be under the CAfs control. For example; Assume the CA-X expects its RPs to evaluate an appropriate certificate policy in the path validation. Even if the CA-X expects its RP to set the initial-explicit-policy flag to TRUE, there is no guarantee that RP sets the flag to TRUE because there are responsible EE and irresponsible EE. A responsible EE may set the flag to TRUE, but an irresponsible EE may not set it. Therefore, CA-X SHOULD issue a certificate which uses requireExplicitPolicy explicitly in the policyConstraints extension. If CA-X issues all certificates which use requireExplicitPolicy in the policyConstraints extension, RP MUST evaluate the certificate policy whether it has responsibility or not. 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: - 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 Shimaoka, et al. [Page 17] INTERNET DRAFT January 2005 domains as follows: * Posterior PKI domain X SHOULD show its PKI architecture to the prior PKI domain Y, because the trust relationship from the PKI domain Y to the PKI domain X may depend on such PKI architecture. * Posterior PKI domain X should show all PKI domains that it trusts to the prior PKI domain Y, because the prior PKI domain Y MUST consider not to trust an unnecessary PKI domain. * Posterior PKI domain X MAY publish what kind of all PKI domain it is trusted by to the prior PKI domain Y, because the PKI domain Y may consider the other certification path to the PKI domain X. In addition, the following requirements MAY be necessary for the certificate based trust relationship. SHOULD give an appropriate policy mapping between the prior PKI domain and the posterior 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. It is similar to a special case of a hierarchical PKI which has no subordinate CAs. Definition Single PKI consists of a single self-signed CA and its EEs. All EEs MUST be issued their certificates by the only CA. Trust anchor The trust anchor MUST be the self-signed certificate of the CA. +----+ +---| CA |---+ | +----+ | | | | | | | Shimaoka, et al. [Page 18] INTERNET DRAFT January 2005 v v v +----+ +----+ +----+ | EE | | EE | | EE | +----+ +----+ +----+ Figure 5 - Single PKI model 5.2 Hierarchy PKI model This is a typical architecture of PKI. Definition Hierarchy PKI consists of a single root CA, a number of subordinate CAs, and EEs. Only the root CA MUST issue a self-signed certificate. All subordinate CAs MUST have only one superior CA. Trust anchor Trust anchor MUST be the root CA. All EEs SHOULD trust only the root CA. +---------+ +---| top CA |---+ | +---------+ | | | | | v v +----+ +----+ +-----| CA | +-----| CA |------+ | +----+ | +----+ | | | | v v v +----+ +----+ +----+ +--| CA |-----+ | CA |-+ +---| CA |---+ | +----+ | +----+ | | +----+ | | | | | | | | | | | | | | | | | v v v v v v v v +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ | EE | | EE | | EE | | EE | | EE | | EE | | EE | | EE | +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ Figure 6 - Hierarchy PKI model 5.3 Mesh PKI model Definition Shimaoka, et al. [Page 19] INTERNET DRAFT January 2005 Mesh PKI consists of multiple CAs and their EEs. All CAs MUST cross-certified with more than one CA unilaterally. Some CAs MAY cross-certify mutually. Trust anchor The trust anchor for a relying party who is issued a certificate from a CA in the mesh PKI SHOULD be a CA who issued it a certificate. The trust anchor for the other relying party who is not issued a certificate from the mesh PKI MAY be any CA in the mesh PKI. Considerations A trust anchor which has not a self-signed certificate means that trust anchor is authorized by another CA. In such a case, this document recommends that relying party SHOULD trust the CA which authorizes that trust anchor. If there is no self-signed CA in that mesh, such as what all CAs in the mesh certify with each other, relying party SHOULD choose a trust anchor from those CAs carefully. This model SHOULD be used sparingly, because of the complexity in certification path building. However, one should not assume that this model does not exist or is implemented. Full Mesh, which is that all CAs in the PKI mutually cross-certify each other directly, PKI MAY be useful conversely for the certification path building, because it is able to reach to the prior 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 | +----+ +----+ +----+ +----+ +----+ Shimaoka, et al. [Page 20] INTERNET DRAFT January 2005 Figure 7 - Mesh PKI model 6 multi-domain PKI Each PKI domain establishes a trust relationship with more than one PKI domain. This section describes topology models for multi-domain PKI. To achieve interoperability, all PKIs in a multi-domain PKI SHOULD apply the following models. Considerations Multi-domain PKI MAY need policy mapping or constraints to maintain each domain policy. All required information for path validation MUST be able to be obtained through some distribution methods. - Intermediate certificate - Target certificate (optional) - Revocation information for all certificates For this, CAs MAY operate a repository, and SHOULD include authorityInfoAccess or cRLDistributionPoints extensions in the certificates they issue to maximize PKI interoperability. 6.1 Multi Trust point model (based on Trust List) The model in which a relying party trusts multiple PKI domains by a trust list. Considerations If the owner of the trust list add a CA in the existing certification path, it SHOULD do carefully since a constraints in the certification path MAY NOT be evaluated correctly. The reason is the following: Assumes that the certification path X->Y->Z->EE(Z) exists. When cross-certificate X->Y includes pathLenConstraints=1, CA-Z cannot extend the certification path started from CA-X by more cross-certificate, and a relying party who trusts CA-Z as the trust anchor cannot trust beyond CA-Z. In that case, if the relying party trusts CA-Y directly, the constraint is ignored. Thus, relying party MUST recognize a risk of trusting another CA directly. Most of the actual public PKIs establish a multi-trust point model without a domain policy. When using such public PKI, this document Shimaoka, et al. [Page 21] INTERNET DRAFT January 2005 recommends: - user-initial-policy-set SHOULD NOT be specified, - and initial-explicit-policy SHOULD NOT be true. In general, since it is difficult for the EE to check if a CA's self- signed certificate has been revoked, a CA SHOULD announce it to all its EEs when the CA is compromised and MAY issue the CRL, and so on. Anyway CA SHOULD do the best. In the multi-trust point model, a compromised trust anchor SHOULD be removed from the trust list, and the removal SHOULD be performed by the subject managing the trust list. 6.1.1 Based on User Trust List Considerations This is an easier and typical method for making a trust relationship to another PKI domain. The relying party MUST understand the certificate status of the trust anchor in the trust list. 6.1.2 Based on Authority Trust List Since there is no standard or established method to achieve interoperability, this memo does not recommend using this model in multi-domain PKI. 6.2 Single Trust Point model (based on Cross-Certification) The model in which all PKI domains are related by Cross- Certification. This cross-certification is either mutual or unilateral. In this model, only one trust anchor is required by EEs. Considerations Each PKI domain MAY use policy mapping for crossing different PKI domains. If a PKI domain wants to restrict a certification path, the PKI domain SHOULD NOT rely on the validation policy of the relying party, but SHOULD include the constraints in the cross- certificate explicitly. For example, when each PKI domain wants to effect 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. Shimaoka, et al. [Page 22] INTERNET DRAFT January 2005 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 used as a method to unify or fake the multiple PKI domains to one PKI domain, or is used as a method for transforming from subordination. Except for that there are CAs who have both self-signed certificates and intermediate certificates issued by the Unificate CA, this model looks like a subordination model since unificate CA is a trust anchor across the PKI domains. 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| | | 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 Shimaoka, et al. [Page 23] INTERNET DRAFT January 2005 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 cross certificates unilaterally. - Bridge CA MUST NOT issue EE certificates except when it is necessary for the CA's operation. - Bridge CA MUST use its own domain policy in the policy mapping between a prior PKI domain and a posterior PKI domain. - The domain policy of Bridge CA MUST be a subset of the prior PKI domain policy that is mapped. - The domain policy of Bridge CA MUST be a superset of the posterior PKI domain policy that is mapped. Cross-Certificate from prior PKI domain to Bridge CA issuerDomainPolicy := Prior PKI domain policy subjectDomainPolicy := Bridge CA domain policy Cross-Certificate from Bridge CA to posterior PKI domain issuerDomainPolicy := Bridge CA domain policy subjectDomainPolicy := Posterior PKI domain policy - Cross-Certificates issued by Bridge CA and Cross-Certificate issued to Bridge CA SHOULD include the requireExplicitPolicy with a value that is greater than zero in the 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 agreed upon by the PKIs or consortium consisting of the PKIs. The Bridge CA SHOULD do policy mapping appropriately with all PKI domains. For using the name constraints, Bridge CA SHOULD pay Shimaoka, et al. [Page 24] INTERNET DRAFT January 2005 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 Bridge CA perform the policy mapping via its own domain policy? - Does the Bridge CA clarify the method of policy mapping in cross-certification? - Is the Bridge CA able to accept the domain policy that the prior PKI domain desires? * If the domain policy is mapped to one with a lower security level, the prior PKI domain SHOULD NOT accept it. If it accepts, the prior PKI domain MUST consider its risk carefully. cross-certified cross-certified PKI 1 with BCA +-----------+ PKI3 with BCA +------->| Bridge CA |<------+ | +-----------+ | | ^ | | cross-certified | | | PKI 2 with BCA | | | | | +-----------|---+ +-----------|---+ +----|-----------------+ | PKI 1 | | | PKI 2 | | | | PKI 3 | | v | | v | | v | | +-----+ | | +-----+ | | +-----+ | | +---| PCA | | | | PCA | | | | PCA |<--+ | | | +-----+ | | +-----+ | | +-----+ | | | | | | | | | | ^ | | | | | | | | | | | v | | | | | | | | | | +----+ | | | | | | | | | | | CA |---+ | | | | | | | | | | +----+ | | | | | | | | | | | ^ | | | | | | | | v | | v | | | | | | | | | +----+ | | +----+ | | | | | | | | | +---| CA | | | | CA |---+ | | | | | | | | | +----+ | | +----+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | v v | | v v | | v v v | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ | | | EE | | EE | | | | EE | | EE | | | | EE | | EE | | EE | | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ | +---------------+ +---------------+ +----------------------+ Shimaoka, et al. [Page 25] INTERNET DRAFT January 2005 Figure 9 - Bridge model 7 Operational Considerations This chapter explains the issues one needs to consider about the management of cross-certificate(s) and use of a directory. 7.1 Directory (1) Unilateral cross-certification 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 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 Shimaoka, et al. [Page 26] INTERNET DRAFT January 2005 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 When updating the Cross-Certificate: There is standard method for what to do when a cross-certificate is updated by modifying some of its contents, e.g., policy identifier When issuer CA-X re-issues a cross-certificate to subject CA-Y before the issued cross-certificate expires, both CA-X and CA-Y MUST each update their own crossCertificatePair corresponding to the cross-certificate, and MUST 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. The reason why both CA MUST update each crossCertificatePair is relying party may use the issuedToThisCA attribute of the crossCertificatePair (in subject CA-Y entry of the repository) for tracing the certification path. When updating the CA keypair: When a CA issues a set of self-issued certificates for key rollover, update of the cross-certificate is able to have a migration period up to the expiration of the self-issued certificate. However, when a CA does not issue a set of self- issued certificates for key rollover, update of the cross- certificate is required as quickly as possible. When a CA keypair is compromised, the CA DN SHOULD NOT be re- used by the same CA without issuing the self-issued certificate. The reason why CA DN should not be re-used is that relying party can not identify which is the compromised CA certificate. When the keypair of subject CA is compromised: Shimaoka, et al. [Page 27] INTERNET DRAFT January 2005 When the keypair of subject CA-Y is compromised, issuer CA-X MUST revoke the cross-certificate for subject CA-Y, then CA-X SHOULD remove the crossCertificatePair attribute for CA-Y from its repository. 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 the revocation list. distributionPoint field SHOULD include also the UniformResourceIdentifier. When the CRL is separated into ARL and CRL, the issuingDistributionPoint extension SHOULD also be used. * The Authority Key Identifier extension and Subject Key Identifier extension SHOULD be used for assisting in path construction. * The policyIdentifier field of the Certificate Policies extension SHOULD be used for identifying each policy domain. * The Policy Mapping extension MAY be used for 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 a single authority. If a PKI domain uses 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 policy 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 policies, including the trust anchor. 8.3 Asymmetric problem Shimaoka, et al. [Page 28] INTERNET DRAFT January 2005 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 user trust list model and PKI domain-Y trusts PKI domain-X by unilateral cross-certification, PKI domain-X merely has to comply with the user trust list model, and PKI domain-Y with the unilateral cross-certification model. 8.3.2 Asymmetric policy mapping This clause considers the case where a result of the policy mapping in mutual cross-certification model is asymmetric. +-------+ 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 a critical security issue. To prevent such a security hole, a loop certification path, one where the same DN appears twice and non-continuously on one certification path MUST NOT be allowed. 9 References 9.1 Normative References [RFC 3280] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet Shimaoka, et al. [Page 29] INTERNET DRAFT January 2005 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", 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 Shimaoka, et al. [Page 30] INTERNET DRAFT January 2005 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 Co., Ltd. Intelligent Systems Lab. SECOM SC Center, 8-10-16, Shimorenjaku Mitaka, Tokyo 181-8528 JAPAN Email: shimaoka@secom.ne.jp Nelson E. Hastings NIST 100 Bureau Drive, Stop 8930 Gaithersburg, MD 20899-8930 USA EMail: nelson.hastings@nist.gov 12 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Shimaoka, et al. [Page 31] INTERNET DRAFT January 2005 Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Shimaoka, et al. [Page 32]