Network Working Group M. Shimaoka Request for Comments: DRAFT SECOM Trust.net July 2004 # snapshot for review in 60th IETF Memorandum for multi-domain Public Key Infrastructure (PKI) Interoperability Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than a "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This memo is intended to describe the foundation necessary to the deployment of a multi-domain PKI. The scope of this memo is to establish and clarify the trust relationship and interoperability between multiple PKI domains. Certification Authority (CA) is able to extend a certification path by trusting from/by other CAs. Both single-domain PKI and multi-domain PKI are established by such trust relationships between CAs. Typical and primitive PKI models are specified as single-domain PKIs. A multi-domain PKI established from more than one single-domain PKI is categorized as either a multi- trust point model or single-trust point model. The multi-trust point model is based on the trust list model, and the single-trust point model is based on the Cross-Certification model. Shimaoka [Page 1] INTERNET DRAFT January 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements and Assumptions . . . . . . . . . . . . . . . . 4 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . 10 3.3. Subordination . . . . . . . . . . . . . . . . . . . . . . . 12 4. PKI Domain . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Requirements for PKI domain . . . . . . . . . . . . . . . . 13 4.2. Risk Analysis of non-interoperable PKI domain . . . . . . . 13 4.3. Requirements for multi-domain PKI interoperability . . . . 15 5. Single-domain PKI . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Single PKI model . . . . . . . . . . . . . . . . . . . . . 16 5.2. Hierarchy PKI model . . . . . . . . . . . . . . . . . . . . 16 5.3. Mesh PKI model . . . . . . . . . . . . . . . . . . . . . . 17 5.4. Trust List PKI . . . . . . . . . . . . . . . . . . . . . . 18 6. multi-domain PKI . . . . . . . . . . . . . . . . . . . . . . 19 6.1. Multi Trust point model . . . . . . . . . . . . . . . . . . 19 6.1.1. Based on User Trust List . . . . . . . . . . . . . . . . 20 6.1.2. Based on Authority Trust List . . . . . . . . . . . . . . 20 6.2. Single Trust Point model . . . . . . . . . . . . . . . . . 20 6.2.1. Unified Domain model . . . . . . . . . . . . . . . . . . 20 6.2.2. Bridge model . . . . . . . . . . . . . . . . . . . . . . 21 6.3. Hybrid trust model . . . . . . . . . . . . . . . . . . . . 23 7. Operational Considerations . . . . . . . . . . . . . . . . . 24 7.1. Directory system . . . . . . . . . . . . . . . . . . . . . 24 7.2. Cross-Certification . . . . . . . . . . . . . . . . . . . . 25 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 8.1. Certificate and CRL Profile . . . . . . . . . . . . . . . . 25 8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . . 27 8.2.1. Asymmetric policy mapping . . . . . . . . . . . . . . . . 27 9. To Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 10.1. Normative References . . . . . . . . . . . . . . . . . . . 28 10.2. Informative References . . . . . . . . . . . . . . . . . . 28 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 12. Author's Address . . . . . . . . . . . . . . . . . . . . . . 29 13. Full Copyright Statement . . . . . . . . . . . . . . . . . . 29 Shimaoka [Page 2] INTERNET DRAFT January 2004 1. Introduction PKI is extendable to realize various architectures, through the way in which CAs establish a trust relationships with each other. When a certain CA establishes a trust relationship with another CA, the CAs MUST compare the security level as certificate policy of the other carefully because various CAs have various certificate policies. So, the method of establishment of every trust relationship MAY differ, as a result of such comparison. To establish appropriate trust rela- tionships, full understanding of the relationship between the estab- lishment method and comparison is required. In addition, all estab- lished trust relationships fall into one of two patterns: single- domain PKI and multi-domain PKI. The technology needed for such an interconnection is insufficient with only the specifications of con- ventional protocols and data formats; elements such as PKI domain and PKI architecture require definitions. This document clarifies these definitions for multi-domain PKI interoperability. Section 2 describes the terminology necessary to consider multi- domain PKI. Section 3 categorizes the trust relationships between CAs as Trust List, Cross-Certification, and Subordination. Section 4 defines a PKI domain and requirements for multi-domain interoperabil- ity. Section 5 defines major models necessary to establish single- domain PKI. Section 6 profiles multi-domain PKI as multi-trust point model and single-trust point model. Multi-trust point model is based on trust list model. Single-trust point model is based on the cross- certification model , and is categorized as peer model, unified domain model and hub model. Section 7 describes considerations for some operational issues, such as managing the crossCertificatePair and populating the certificates in the directory system. Finally, section 8 describes considerations focused on Certificate and Cer- tificate Revocation List (CRL) profiles, Repositories, and path vali- dation. +------------------+ +-------------------+ | PKI domain | | PKI domain | | | Domain-Domain | | | | Trust | | | +-----+ | Relationship | +-----+ | | | PCA |<===========================>| PCA | | | +-----+ | | +-----+ | | ^ | | ^ | | | CA-CA Trust | | | CA-CA Trust | | | Relationship | | | Relationship | | v | | v | | +----+ | | +----+ | | | CA | | | | CA | | | +----+ | | +----+ | Shimaoka [Page 3] INTERNET DRAFT January 2004 +------------------+ +-------------------+ 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. Basically a terminology in this document follows [RFC 2828] excepting the following. 2.1. Abbreviations EE: End Entity 2.2. Terminology PKI (Public-Key Infrastructure) PKI based on X.509 is a set of CA and end entities in a narrow sense. But in a broader sense, PKI sometimes means a PKI domain itself. Relying Party Entity who verifies the certificate. Relying party MUST have one or more trust anchors and MAY have a set of validation policies. In single-domain PKI, these MAY be omitted implicitly. Intermediate Certificate Whole certificates in a certification path excepting a trust anchor and a target certificate. Top CA Only CA that is a root in Hierarchy PKI model. Top CA MUST issue a self-signed certificate. Top CA SHOULD be used for Hierarchy PKI model. For unified domain model, unificate CA SHOULD be used as defined later in this section. PKI domain PKI domain is a set of PKIs for identifying the PKI operated on the same certificate policy. Such certificate policy is called a Shimaoka [Page 4] INTERNET DRAFT January 2004 "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. Trust Anchor Starting point of a certification path to a subscriber certifi- cate, which is specified by a relying party. If a relying party have to perform a validation of the trust anchor, it SHOULD be verified by some trustworthy out-of-band procedure, and is outside the scope of this memo. However, relying party SHOULD consider at least the following to select its trust anchor: In the case that trust anchor has no self-signed certificate, what assures the binding of the private key and the public key of the trust anchor MAY be not the trust anchor self. There- fore, trust anchor SHOULD be a CA issuing a self-signed cer- tificate. Trusted PKI domain PKI domain which is trusted from trusting PKI domain. Usually, trusted PKI domain means the PKI domain of the subscriber. Trusting PKI domain PKI domain which trusts other PKI domains. Usually, trusting PKI domain means the PKI domain of the relying party. Trust Relationship In this document, this means a trust relationship between CAs. This relationship is required for trailing from a trust anchor to a subscriber. Unificate CA CA which has a self-signed certificate and issued unilateral cross-certificates to each principal CA of other PKI domains. Shimaoka [Page 5] INTERNET DRAFT January 2004 Unificate CA is specified as a trust anchor for the PKI domains that are cross-certified by this CA unilaterally. Trust List Trust list is a list of one or more trust anchors, which MAY be a set of the trust anchor certificates in general. Trust list is used for specifying a trust anchor by a relying party. Trust List looks like "trust-file PKI" defined in [RFC 2828], but the trust list does not have to be a file. Cross-Certification Cross-Ceritification is an issuing certificate to another CA. 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. The following trust relationship is used for con- necting CAs or used for connecting PKI domains. 3.1. Operation based Trust Relationship Definition Defined as Trust List 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 MAY form a PKI domain, or form multiple PKI domains. Trust List +--------------------------------------------------------------+ | Trusted CA | | | | +---------------+ +---------------+ +----------------------+ | Shimaoka [Page 6] INTERNET DRAFT January 2004 | | PKI 1 | | PKI 2 | | PKI 3 | | | | | | | | | | | | +-----+ | | +-----+ | | +-----+ | | | | +---| PCA | | | | PCA | | | | PCA |<--+ | | | | | +-----+ | | +-----+ | | +-----+ | | | | | | | | | | | | ^ | | | +-----|------|-----------|----------------|-------|------------+ | | | | | | | | | | | | | | | | | | | | v | | | | | | | | | | +----+ | | | | | | | | | | | CA |---+ | | | | | | | | | | +----+ | | | | | | | | | | | ^ | | | | | | | | v | | v | | | | | | | | | +----+ | | +----+ | | | | | | | | | | CA |---+ | | | CA |---+ | | | | | | | | +----+ | | | +----+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | v v | | v v | | v v v | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ | | | EE | | EE | | | | EE | | EE | | | | EE | | EE | | EE | | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ | +---------------+ +---------------+ +----------------------+ Figure 2 - Trust List model 3.1.1. User Trust List model Definition The model in which a trust list is managed by end entities. This is similar to "trust-file PKI" defined in [RFC 2828]. Each end entity is able to have its own user trust list. Characteristics End entity is able to manage its own user trust list. End entity 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. Considerations Except for end entity itself, no one is able to control the trust relationship. There is a risk that end entity trusts unknown PKI domain irresponsibly. If end entity trusts unknown PKI domains irresponsibly, then its issuer CA cannot apply its certificate Shimaoka [Page 7] INTERNET DRAFT January 2004 policy to the end entity. A trust anchor MAY not apply its vali- dation policy to the end entity. 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 trusted organi- zation, which is as authority of relying party. The trusted orga- nization MAY issue multiple trust lists for some purposes or par- ties. End entities trusting the same organization MAY share the authority trust list given by the trusted organization. Characteristics End entity does not have control over any trust relationships from its trusted organization. Trusted organization MUST control an appropriate trust relationship. Considerations Since there is no standard for the use of this model and manage- ment methods for authority trust list are not established gener- ally, this model MAY not achieve interoperability sufficiently. How to trust the authority trust list is outside the scope of this document. When the trusted organization issuing the authority trust list performs a cross-certification with another PKI, the method of the cross-certification SHOULD be considered carefully. SHALL that PKI cross-certify individually with a trust anchor in the trust list? 3.2. Certificate based Trust Relationship Definition Trust relationship established by the cross-certification. Requirement CA issued the cross-certificate MUST have a self-signed certifi- cate except for subordination model. If cross-certifying to the CA, issuer CA MUST be responsible for existing of the CA, like the subordination model. CA SHOULD generate a cross-certification pair for populating it as crossCertificatePair attribute in the directory system. Shimaoka [Page 8] INTERNET DRAFT January 2004 Characteristics Cross-Certification is a stricter trust relationship than the trust list model, because the trust relationship is represented by a certificate and (authority) revocation list and is recorded to an audit log. Cross-certification is able to manage the trust relationship without changing the trust list of end entities. Because all subject CAs have a self-signed certificate, revoking a cross-certificate does not always mean also compromising the sub- ject CA. Cross-certification is used for interconnecting between multiple PKI domains, and may be used for connecting between CAs in one PKI domain. Considerations For path building Since some path building applications use the key identifier for path building, the value of the keyIdentifier in the cross- certificate SHOULD be identical. E.g., in a cross-ceritifica- tion request, subject CA SHOULD include subjectKeyIdentifier extension that is same value with the keyIdentifier of authori- tyKeyIdentifier extension in the certificate it issued, and issuer CA SHOULD issue a cross-certificate including the sub- jectKeyIdentifier extension which has identical keyIdentifier to the request. For PKI issuing Revocation List Issuer CA MAY issue ARL. However, ARL with an issuingDistribu- tionPoint extension MAY NOT be processed by some applications. If issuer CA does not issue ARL, it MUST issue fullCRL at least. 3.2.1. Unilateral cross-certification Definition The model in which a CA issues a cross-certificate to another CA unilaterally. Characteristics This certification is usable like subordination, and is able to establish a more flexible trust relationship than subordination; even if the cross-certificate is revoked, subject CA MAY be able to continue its operation. Shimaoka [Page 9] INTERNET DRAFT January 2004 If the PKI use a directory system, the issuer CA MUST generate a crossCertificatePair to avoid being categorized as subordination, even if it means unilateral. Example There are PKI domain A trusted by Alice, and PKI domain B trusted by Bob. PKI domain A trusts PKI domain B, but PKI domain B does not trust PKI domain A. Therefore, only PKI domain A issues a cross-certificate to PKI domain B. As the result, Alice can trust Bob, but Bob cannot trust Alice. +---------------+ +----------------------+ | Trusting | | Trusted | | PKI 1 | | PKI 2 | | | cross-certified | | | +-----+ | PKI 1 to PKI 2 | +-----+ | | | PCA |--------------------------->| PCA |<--+ | | +-----+ | | +-----+ | | | | | | ^ | | | | | | | v | | | | | | +----+ | | | | | | | CA |---+ | | | | | | +----+ | | | | | | | ^ | | | | v | | v | | | | | +----+ | | +----+ | | | | | | CA |---+ | | | CA |---+ | | | | +----+ | | | +----+ | | | | | | | | | | | | | | | | | | | | | | v v | | v v v | | +----+ +----+ | | +----+ +----+ +----+ | | | EE | | EE | | | | EE | | EE | | EE | | | +----+ +----+ | | +----+ +----+ +----+ | +---------------+ +----------------------+ Figure 3 - Unilateral Cross-Certification 3.2.2. Mutual cross-certification Definition The model in which a CA issues a cross-certificate to another CA mutually. Characteristics Shimaoka [Page 10] INTERNET DRAFT January 2004 Both CAs issue the cross-certificate each other. For PKI using directory system Both CAs MUST generate a crossCertificatePair that consist of the cross-certificate it issued and the corresponding cross- certificate that was issued. When either CA updates a cross- certificate, each CA MUST re-generate their crossCertifi- catePair synchronously. Example There is PKI domain A trusted by Alice, and is PKI domain B trusted by Bob. PKI domain A trusts PKI domain B, and PKI domain B also trusts PKI domain A. Therefore, PKI domain A and PKI domain B issue the cross-certificate each other. As the result, Alice and Bob can trust each other. 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 | | | +----+ +----+ | | +----+ +----+ +----+ | +---------------+ +----------------------+ Shimaoka [Page 11] INTERNET DRAFT January 2004 Figure 4 - Mutual Cross-Certification 3.3. Subordination (Hierarchy) Subordination is a special unilateral cross-certification. This is only used for connecting CAs in a PKI domain, not used for intercon- necting PKI domains. Definition The model in which a PKI that any CA has only one superior CA. Requirements A subordinate CA MUST have only one superior CA and be managed by the superior CA strictly. A subordinate CA MUST never issue its self-signed certificate. Characteristics An existence of the subordinate CA is dependent on the superior CA. Subordinate CA MAY be an authority that is delegated some privileges and policies from the superior CA. A subordinate CA MAY 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 end entities who trust the superior CA. Subordinate CAs MUST NOT issue the cross-certificate to other PKI domains, but MAY just allow a subordination to the same PKI domain. When a subordinate CA certificate is revoked by a supe- rior CA, all certificates issued by the subordinate CA MUST NOT be trusted. Considerations A subordinate CA MUST NOT override the constraints given by the superior CA. When a subordinate CA issues a self-signed certifi- cate, the subordinate CA MUST need an agreement from its superior CA on issuing the certificate, because certificates issued by the subordinate CA will be not constrained by the superior CA. Typical scenario is shown as below: Superior CA A issued the certificate to Alice, and subordinate CA B issued the certificate to Bob. Alice and Bob trust the superior CA A as their trust anchor. Subordinate CA B can issue only end entity certificate practically, because the cer- tificate issued from CA A to CA B includes pathLenConstraints Shimaoka [Page 12] INTERNET DRAFT January 2004 as zero. If CA B issue a self-signed certificate and dis- tribute it as trust anchor to Bob, CA B can issue a subordinate CA certificate, and Bob can trust it. As a result, CA A cannot constrain the length of path to CA B. When the subordinate CA issues a self-signed certificate, the PKI changes from the subordination model into the unified domain model. 4. PKI Domain 4.1. Requirements for PKI domain PKIs in a PKI domain SHOULD share one or more certificate policy, and the PKI domain MUST have a principal CA. This shared policy is called the "domain policy". The domain policy SHOULD be described in the policyIdentifier of the certificate policies extension for each certificate. All CAs in a PKI domain MUST be operated under each CP/CPS that con- forms to the domain policy. All CAs in a PKI domain MUST be able to issue a verifiable certificate by using the principal CA as the trust anchor. 4.2. Risk Analysis of non-interoperable PKI domain A PKI domain that satisfies the requirements in section 4.1 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 the 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 identifica- tion 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 Each PKI domain MAY NOT clarify each domain policy and perform policy mapping. In such a case, path validation using initial- explicit-policy will fail. Shimaoka [Page 13] INTERNET DRAFT January 2004 If a PKI domain interconnects to another PKI domain, In addition to the above requirements in section 4.1, the following considera- tion is necessary. * Conflict of a name space A trusting PKI domain that establishes a trust relationship with other PKI domains MUST not conflict about the name space with others. If not, a name constraints in path validation may not function according to certificate. * Policy management When validating a certification path crossing the PKI domains, relying party MAY identify the PKI domains by checking the cer- tificate policies extensions. If the domain policy is not described in the certificate policies extension, the path vali- dation MAY fail. Especially the domain policy is necessary in the path validation through the PKI that use some constraints or policy mapping. * Constraints by intermediate CA Intermediate CA cannot assume the validation policy used by a relying party. Therefore, the intermediate CA that wants to constrain something, e.g., path length, name spaces, and poli- cies, for the certification path MUST include explicitly the extensions for the constraints in the certificate issued. For example; Alice in PKI domain A: She does not specify an user-initial- policy-set. Bob in PKI domain B: PKI domain B assumes specifying a cer- tain certificate policy (cP-B.1) in the user-intial-policy- set to a relying party. A certificate issued in PKI domain B does not include the policyConstraints extension. Bob's certificate includes cP-B.1 in the policyIdentifier of the certificate policies extension. PKI domain B assumes specifying a certain certificate policy in the user-intial-policy-set to a relying party. A cer- tificate issued in PKI domain B does not include the policy- Constraints extension. Bob's certificate includes cP-B.1 in the policyIdentifier of the certificate policies extension. PKI domain B assumes no using cP-B.1 outside the PKI domain B. Alice can validate successfully the certification path to Bob without user-initial-policy-set. It is different from a result to expect of PKI domain B. Domain B has to Shimaoka [Page 14] INTERNET DRAFT January 2004 specify explicit-policy on the certificate to have you inspect it according to the expectation of PKI domain B. to make a result according to the expectation of the PKI domain B, PKI domain B MUST use the requireExplicitPolicy in the policy constraints extension of a certificate that PKI domain B issues. Alice can validate successfully the certification path to Bob with no specified user-initial-policy-set. It is dif- ferent from a result to expect of PKI domain B. Domain B must specify explicit-policy on the certificate so that any- one validates such domain policy correctly. To make a result expected of PKI domain B, PKI domain B MUST use the requireExplicitPolicy in the policy constraints extension of a certificate that PKI domain B issues. 4.3. Requirements for multi-domain PKI interoperability In multi-domain PKI, there MAY be a PKI domain that assumes requiring the explicit policy. To validate correctly such certification path without depending on some assuming validation policy, the following requirements are necessary for the PKI domains: * Each PKI domain has a repository for supporting the path valida- tion, but this document does not specify whether the repository is web server or directory server. * All CAs in a PKI domain that has explicit domain policy as poli- cyIdentifier MUST be able to issue a certificate which is verifi- able with the following validation policy: $ user-initial-policy-set which includes its own domainPoli- cyId. $ initial-explicit-policy set to TRUE. $ trust anchor which is the principal CA of its PKI domain. * As operational issues, each PKI domain SHOULD show the trust relationship with other PKI domains as follows: $ Trusted PKI domain SHOULD show to the trusting PKI domain what kind of PKI it includes. $ Trusted PKI domain SHOULD show to trusting PKI domain what kind of other PKI domains it trusts. $ Trusted PKI domain MAY publish to the trusting PKI domain what kind of other PKI domains it is trusted by. In addition, the following requirements MAY be necessary for the cer- tificate based trust relationship. * SHOULD give an appropriate policy mapping between the trusting Shimaoka [Page 15] INTERNET DRAFT January 2004 PKI domain and the trusted PKI domain for certificate based trust relationship. 5. Single-domain PKI This section describes appropriate PKI architectures for establishing a single PKI domain. All PKIs that are going to participate in multi-domain PKI SHOULD adopt either one of the following models for multi-domain PKI interoperability. 5.1. Single PKI model This is the simplest PKI model. This model is used as a minimal com- ponent of all PKI models. Or, this model itself MAY be used as one PKI domain. Definition Single PKI consists of a single self-signed CA and its end enti- ties. All end entities SHOULD trust only the CA. All subscribers MUST be issued their certificates by the only CA. Trust anchor The trust anchor MUST be the single self-signed CA. +----+ +---| CA |---+ | +----+ | | | | | | | v v v +----+ +----+ +----+ | EE | | EE | | EE | +----+ +----+ +----+ Figure 5 - Single PKI model 5.2. Hierarchy PKI model This is a typical architecture of PKI. This model is basically used as one PKI domain. Or, this model itself MAY be used as a component of other PKI models, such as Mesh PKI or trust list model. Definition Hierarchy PKI consits of a single top CA, some subordinate CAs, Shimaoka [Page 16] INTERNET DRAFT January 2004 and end entities. Only the top CA MUST issue a self-signed cer- tificate. All subordinate CAs MUST have only one superior CA. Trust anchor Trust anchor MUST be the top CA. All end entities SHOULD trust only the top CA. +---------+ +---| top CA |---+ | +---------+ | | | | | v v +----+ +----+ +-----| CA | +-----| CA |------+ | +----+ | +----+ | | | | v v v +----+ +----+ +----+ +--| CA |-----+ | CA |-+ +---| CA |---+ | +----+ | +----+ | | +----+ | | | | | | | | | | | | | | | | | v v v v v v v v +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ | EE | | EE | | EE | | EE | | EE | | EE | | EE | | EE | +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ Figure 6 - Hierarchy PKI model 5.3. Mesh PKI model Definition Mesh PKI consists of multiple CAs and their end entities. All CAs MUST cross-certify more than one CA unilaterally, or MUST be cross-certified by more than one CA unilaterally. Some CAs MAY cross-certify mutually. Trust anchor Trust Anchor SHOULD be a CA which issued the relying party cer- tificate. Considerations This model SHOULD NOT be used as single PKI domain, because it is Shimaoka [Page 17] INTERNET DRAFT January 2004 difficult to clarify the following considerations. * Difficult to determine a principal CA, * Difficult that any relying party can obtain a same result for path validation, * Difficult to simplify a certification path. On the other hand, this is often used in multi-domain PKI as a result of that some PKI domains cross-certified each other. Therefore, relying party applications SHOULD be able to perform the validation for such a path. This model SHOULD be avoided as possible, because it may be com- plex to the certification path building. However, do not assume that this model is not existing. Full Mesh PKI MAY be useful conversely for the certification path building, because it is able to reach certainly to the trusting PKI domain with one path. cross certified +-------+ cross certified +---------------->| CA |<----------------+ | +-------+ | | | | | | | | | | v v | | +----+ +----+ | | | EE | | EE | | | +----+ +----+ | v v +------+ +------+ | CA |<--------------------------------->| CA |-----+ +------+ cross certified +------+ | | | | | | | | | | | v v v v v +----+ +----+ +----+ +----+ +----+ | EE | | EE | | EE | | EE | | EE | +----+ +----+ +----+ +----+ +----+ Figure 7 - Mesh PKI model 5.4. Trust List PKI This is a major model of PKI used in a popular web browser. Definition Trust List PKI is a set of PKIs, and its trust list consists of the trust anchor of each PKI. Shimaoka [Page 18] INTERNET DRAFT January 2004 Trust Anchor In each certification path, relying party specifies a trust anchor from its trust list. Trust anchor MAY be specified by the relying party application automatically, or by the relying party self man- ually. Considerations A intermediate CA in the existing certification path SHOULD NOT be added to the trust list, since a constraint in the certification path MAY not be evaluated correctly. Since it is difficult for the end entity to check if a CA's self-signed certificate has been revoked, a CA SHOULD announce it to all end entities when the CA is compromised. Compromised trust anchor SHOULD be removed from the trust list, and the removing SHOULD be performed by the sub- ject of managing the trust list, which is user or authority. 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 main- tain each domain policy. All required information for path vali- dation MUST be able to be obtained through the internet. * Intermediate certificate * Target certificate (optional) * Revocation information for all certificates For this, CAs MAY operate a repository, and SHOULD include author- ityInfoAccess or cRLDistributionPoints extensions in the certifi- cates they issue. 6.1. Multi Trust point model (based on Trust List) The model in which a relying party trusts multiple PKI domains by a trust list. Considerations Most of the actual PKIs establish a multi-trust point model with- out a domain policy. When using such PKI, initial-explicit-policy Shimaoka [Page 19] INTERNET DRAFT January 2004 SHOULD NOT be true. 6.1.1. Based on User Trust List This is an easier and typical method for making a trust relationship to another PKI domain. The relying party MUST recognize a certifi- cate status of the trust anchor in the trust list. 6.1.2. Based on Authority Trust List Since there is no standard or established method, this memo does not recommend using this model in multi-domain PKI. 6.2. Single Trust Point model (based on Cross-Certification) The model in which all PKI domains are trusting/trusted each other by Cross-Certification. This cross-certification is either mutual or unilateral. In this model, a trust anchor is only one. Considerations Each PKI domain MAY use policy mapping for crossing different PKI domains. If a PKI domain wants to restrict a certification path, the PKI domain SHOULD NOT rely on the validation policy of the relying party, but SHOULD include the constraints in the certifi- cate explicitly. For example, when each PKI domain wants to effect always the con- straints to a certification path, it SHOULD set the requireExplic- itPolicy to zero in the policyConstraints extension of any cross- certificates. A PKI domain, which relies on the validation policy of the relying party, may not effect the constraints. 6.2.1. Unified Domain model (based on unilateral Cross-Certification) The model in which multiple PKI domains have a joint superior CA that issues cross-certificates to each PKI domain unilaterally. Such a joint superior CA is defined as unificate CA. This model is a method to unify or represent the multiple PKI domains to one PKI domain, or is a method for transforming from subordinaion. Except a thing that a self-signed CA is existing as the intermediate CA, this model looks like a subordination model. Therefore, often this model is used like the hierarchy model in multi-domain PKI. cross-certified cross-certified Unificate CA to PKI 1 +--------------+ Unificate CA to PKI 3 +---------| Unificate CA |---+ Shimaoka [Page 20] INTERNET DRAFT January 2004 | +--------------+ | | | | | cross-certified| | | Unificate CA | | | to PKI 2 | | +-----------|---+ +-----------|---+ +----|-----------------+ | PKI 1 | | | PKI 2 | | | | PKI 3 | | v | | v | | v | | +-----+ | | +-----+ | | +-----+ | | +---| PCA | | | | PCA | | | | PCA |<--+ | | | +-----+ | | +-----+ | | +-----+ | | | | | | | | | | ^ | | | | | | | | | | | v | | | | | | | | | | +----+ | | | | | | | | | | | CA |---+ | | | | | | | | | | +----+ | | | | | | | | | | | ^ | | | | | | | | v | | v | | | | | | | | | +----+ | | +----+ | | | | | | | | | +---| CA | | | | CA |---+ | | | | | | | | | +----+ | | +----+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | v v | | v v | | v v v | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ | | | EE | | EE | | | | EE | | EE | | | | EE | | EE | | EE | | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ | +---------------+ +---------------+ +----------------------+ Figure 8 - Unified Domain model 6.2.2. Bridge model The model in which every PKI domain 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. This model is used in Federal PKI in USA, Government PKI in Japan, and so on. Requirements for Bridge model * Bridge CA MUST NOT be used as the trust anchor in any PKI domain. * Bridge CA SHOULD issue cross-certificates with other PKI domains mutually or MAY issue it unilaterally. * Bridge CA MUST NOT issue end entity certificates except when it is necessary for the CA's operation. Shimaoka [Page 21] INTERNET DRAFT January 2004 * Bridge CA MUST use its own domain policy in the policy mapping between a trusting PKI domain and a trusted PKI domain. * The domain policy of Bridge CA MUST be a subset of the trusting PKI domain policy that is mapped. * The domain policy of Bridge CA MUST be a superset of the trusted PKI domain policy that is mapped. Cross-Certificate from Trusting PKI domain to Bridge CA issuerDomainPolicy := Trusting PKI domain policy subjectDomainPolicy := Bridge CA domain policy Cross-Certificate from Bridge CA to Trusted PKI domain issuerDomainPolicy := Bridge CA domain policy subjectDomainPolicy := Trusted PKI domain policy * Cross-Certificates issued by Bridge CA and Cross-Certificate issued to Bridge CA SHOULD specify the requireExplicitPolicy in the policyConstaints 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-cer- tify directly to other PKI domains cross-certified with the same Bridge CA. * Bridge CA MUST clarify the method for the policy mapping of cross-certification to keep its transparency. Considerations The Bridge CA SHOULD be operated by neutral trusted third party. The Bridge CA SHOULD do policy mapping appropriately with both PKI domains. If using the name constraints, Bridge CA MUST prevente 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 of the PKI domain it is going to cross-certify? $ If the domain policy is mapped to one with a lower secu- rity level, the trusting PKI domain MUST NOT accept it. cross-certified cross-certified PKI 1 with BCA +-----------+ PKI3 with BCA +------->| Bridge CA |<------+ Shimaoka [Page 22] INTERNET DRAFT January 2004 | +-----------+ | | ^ | | cross-certified | | | PKI 2 with BCA | | | | | +-----------|---+ +-----------|---+ +----|-----------------+ | PKI 1 | | | PKI 2 | | | | PKI 3 | | v | | v | | v | | +-----+ | | +-----+ | | +-----+ | | +---| PCA | | | | PCA | | | | PCA |<--+ | | | +-----+ | | +-----+ | | +-----+ | | | | | | | | | | ^ | | | | | | | | | | | v | | | | | | | | | | +----+ | | | | | | | | | | | CA |---+ | | | | | | | | | | +----+ | | | | | | | | | | | ^ | | | | | | | | v | | v | | | | | | | | | +----+ | | +----+ | | | | | | | | | +---| CA | | | | CA |---+ | | | | | | | | | +----+ | | +----+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | v v | | v v | | v v v | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ | | | EE | | EE | | | | EE | | EE | | | | EE | | EE | | EE | | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ | +---------------+ +---------------+ +----------------------+ Figure 9 - Bridge model 6.3. Hybrid trust model This section 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 uni- lateral 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-certi- fication, PKI domain-X merely has to comply with the user trust list model, and PKI domain-Y with the unilateral cross-certification Shimaoka [Page 23] INTERNET DRAFT January 2004 model. 7. Operational Considerations This section explains the point that you should pay attention about management of a cross-certificate and use of a directory system. 7.1. Directory system (1) Unilateral cross-certification When CA-X cross-certifies CA-Y unilaterally, both CAs SHOULD oper- ate 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 MUST 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 MUST 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 MUST NOT indi- vidually generate two crossCertificatePairs each containing only one cross-certificate, similar to the unilateral cross- Shimaoka [Page 24] INTERNET DRAFT January 2004 certification model. 7.2. Cross-Certification (1) When updating the Cross-Certificate "Certificate update" is defined in [RFC 2828]. However, there is no rule for what to do when a certain cross-certificate is updated to modify some contents, e.g., policy identifier of the cross-cer- tificate. 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 generate their own crossCertificatePair corresponding to the cross-certificate, and MUST populate it to their own directory system. Until this is done, change of cross-certification is not reflected completely to certification path. In addition, CA-X MUST revoke the old cross-certificate to CA-Y when CA-X does not intend to enable the old cross-certificate either. (2) When rekeying the CA key pair When a CA issues a set of self-issued certificates for rekeying, update of the cross-certificate MAY be not required. However, when a CA does not issue a set of self-issued certificates for rekeying, cross-certificate MUST be updated. (3) When the key pair of subject CA is compromised When the key pair 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 repos- itory. 8. Security Considerations In PKI, there are certificate issuer and certificate verifier in PKI. To issuer, certificate issued MUST be what it intended. And to veri- fier, certificate it validates MUST be evaluated correctly. If some parties could not perform these, the PKI of that parties SHOULD NOT be trusted from other. This section describes the considerations to perform these for multi-domain PKI interoperability. 8.1. Certificate and CRL Profile All Certificates and CRLs MUST comply with [RFC 3280]. In addition, certificate issuer MUST design its certificate and CRL profile with the following considerations for multi-domain PKI interoperability. Shimaoka [Page 25] INTERNET DRAFT January 2004 * The extensions for processing only in local PKI domain SHOULD be non-critical. Do not assume that all PKI applications outside the PKI domain can process the critical extensions correctly. * The cRLDistributionPoint extension SHOULD be used for obtaining the revocation list. distributionPoint field SHOULD include also the UniformResourceIdentifier. When the CRL is separated into CARL and EPRL, the issuingDistributionPoint extension SHOULD also be used. When a relying party obtains the revocation information, the relying party MAY obtain it directly, or have to know how to obtain it. E.g., the former may be given as local-file, but this may be difficult to a relying party outside the PKI domain. The latter MAY be given as URI of cRL Distribution Point or OCSP responder, and this is easier method for the relying party outside the PKI domain. * The Authority Key Identifier extension and Subject Key Identi- fier extension SHOULD be used for assisting in path building. * The policyIdentifier field of the Certificate Policies extension SHOULD be used for identifying each domain. Some relying parties MAY require policy validation for identi- fying the security level when validate the path to other PKI domain. In that case, the PKI domain SHOULD show its security level as policyIdentifier. If relying party specifies initial- explicit-policy in validation policy or a intermediate certifi- cate gives requireExplicitPolicy as smaller than the rest of path length, the path validation to the PKI domain, which does not describe its domain policy in policyIdentifier, is failed. * The Policy Mapping extension MAY be used for the validating that mutual domain policies are equivalent. Some relying parties MAY require policy validation for evaluat- ing that the security level of subscriber is equivalent to the relying party. Excepting the case that an user-initial-policy- set that relying party specifies includes the domain policy of the subscriber, a certification path without using policy Map- ping may not satisfy the validation policy. * When a PKI domain uses the nameConstraints extension in multi- domain PKI, it MUST confirm that the subject PKI domain is manag- ing its name space. If the subject PKI domain does not manage its name space, the nameConstraints extension may not constrain as what issuer Shimaoka [Page 26] INTERNET DRAFT January 2004 intended. 8.2. Path Validation Validation parameters used for path validation is the intersection of constraints by CA and relying party. Constraints which CA intends SHOULD NOT suppose any constraints by relying party, but SHOULD be included in the certificates explicitly. # To describe with concrete example 8.2.1. Asymmetric policy mapping # To need more consideration This section considers the case where results of the policy mapping in mutual cross-certification model is asymmetric. +-------+ cP-1.1 := cP-2.1 +-------+ | |------------------->| | | PCA 1 | | PCA 2 | | |<-------------------| | +-------+ cP-2.1 := cP-1.2 +-------+ Figure 10 - Asymmetric policy mapping When path building allows the certification path to loop, then cP-1.1 is mapped to cP-1.2, and such a policy mapping MAY derive an unfore- seen 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 pol- icy identifiers managed by same PKI actually describes different policies, differing policy identifiers mapped unexpectedly in the same entity represents an critical security issue. To prevent such a security hole, a loop certification path, one where the same DN appears twice and non-continuously on one certification path MUST NOT be allowed. 9. To Do * Make a consistency with RFC 2828 Trust List vs. trust-file PKI, and so on. * Need more consideration about the word "trust relationship" Trust List is not trust relationship between CAs. It is used for increasing/expanding a PKI domain by relying party self. * Figure the concept of PKI domain in section 4.1 Shimaoka [Page 27] INTERNET DRAFT January 2004 * Simplify the example in "Constraints by intermediate CA" Need to replace by another simple example. * Describe with concrete example in section 8.2 * Need more consideration for section 8.2.1 10. References 10.1. Normative References [RFC 2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, May 2000. [RFC 3280] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 3280, April 2002. [RFC 2256] Wahl, M., "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, Dec 1997. [ISO-X509] ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information Technology - Open Systems Interconnection: The Directory: Authentication Framework," 2001 edition. 10.2. Informative References 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. Asia PKI Forum, "Asia PKI Interoperability Guideline", Version 1.0, Mar 2004. 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 Shimaoka [Page 28] INTERNET DRAFT January 2004 Promotion Agency, Japan, "Implementation Problems on PKI", Feb 2003. 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. Hesse, P., Lemire, D., "Managing Interoperability in Non-Hierarchical Public Key Infrastructures", Feb 2002. 11. Acknowledgements This document is based on some valuable documents and many experi- ences 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 discus- sions which helped us in this effort. This work is aided by Informa- tion-technology Promotion Agency Information-technology Security Cen- ter (IPA/ISEC) and Japan Network Security Association (JNSA). 12. 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 13. Full Copyright Statement Copyright (C) The Internet Society (2004). 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, Shimaoka [Page 29] INTERNET DRAFT January 2004 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Shimaoka [Page 30]