view Side-By-Side changes
Network Working Group M. ShimaokaRequest for Comments: DRAFTInternet-Draft SECOM<draft-shimaoka-multidomain-pki-06.txt>Expires: January 10, 2007 N. Hastings NIST R. Nielsen Booz Allen HamiltonJanuaryJuly 9, 2006 Memorandum for multi-domain Public Key Infrastructure(PKI)Interoperability draft-shimaoka-multidomain-pki-07 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 as "work in progress." The list of current Internet-Drafts can be accessed athttp://www.ietf.org/1id-abstracts.htmlhttp://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed athttp://www.ietf.org/shadow.htmlhttp://www.ietf.org/shadow.html. This Internet-Draft will expire onJuly 12, 2006.January 10, 2007. Copyright Notice Copyright (C) The Internet Society (2006). 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. Shimaoka, et al. Expires January 10, 2007 [Page 1] Internet-Draft multi-domain PKI interoperability July 2006 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 (CP) at aShimaoka, et al. [Page 1] INTERNET DRAFT January 2006specified 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 Contents11. Introduction . . . . . . . . . . . . . . . . . . . . . . .3 2 Requirements and Assumptions .. . 3 1.1. Objective . . . . . . . . . . . . .4 2.1 Abbreviations. . . . . . . . . . . 3 1.2. Document Outline . . . . . . . . . . . . .4 2.2 Terminology. . . . . . . . 3 1.3. Requirements and Assumptions . . . . . . . . . . . . . . . 3 2. Terminology . .4 2.3 Assumptions. . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Basic Concepts . .8 3 Trust Relationship. . . . . . . . . . . . . . . . . . . . 4 2.2. Certification Authority Relationships . .8 3.1 Operation based Trust Relationship. . . . . . . . 5 2.2.1. Hierarchical . . . . .9 3.1.1 User Trust List model. . . . . . . . . . . . . . . . 6 2.2.2. Peer . . .10 3.1.2 Authority Trust List model. . . . . . . . . . . . . . . .10 3.2 Certificate based Trust Relationship. . . . . . 7 2.3. Public Key Infrastructure (PKI) . . . . . .11 3.2.1 Unilateral Cross-Certification. . . . . . . 7 2.3.1. Simple PKI . . . . . . .12 3.2.2 Mutual Cross-Certification. . . . . . . . . . . . . . . 8 2.3.2. Hierarchical PKI .13 3.3 Subordination (Hierarchy). . . . . . . . . . . . . . . . . .14 49 2.3.3. Mesh PKIDomain . .. . . . . . . . . . . . . . . . . . . . . . .. 16 4.1 Requirements for10 2.3.4. Hybrid PKIdomain .. . . . . . . . . . . . . . . .16 4.2 Risk Analysis of non-interoperable PKI domains .. . . . . .16 4.312 3. TrustRelationship Disclosure Requirements for multi-domain PKIs . . . . .Lists . . . . . . . . . . . . .17 5 Single-domain PKI. . . . . . . . . . . . 14 3.1. Relying Party Trust List Model . . . . . . . . . . .18 5.1 Single CA PKI model. . . 15 3.2. Trust Authority Model . . . . . . . . . . . . . . . . . .18 5.2 Hierarchy16 4. PKImodel . . . . . . . . . . . . . . . . . .Domain . . .19 5.3 Mesh PKI model. . . . . . . . . . . . . . . . . . . . . . .19 6 multi-domain18 4.1. Requirements for PKI domain . . . . . . . . . . . . . . . 18 4.2. Risk Analysis of non-interoperable PKI domains . . . . . .. . 21 6.1 Multi18 4.3. Trustpoint model . . . . . . .Relationship Disclosure Requirements for multi-domain PKIs . . . . . . . . . . . .21 6.1.1 Based on User Trust List. . . . . . . . 18 5. Abbreviations . . . . . . . . .22 6.1.2 Based on Authority Trust List. . . . . . . . . . . . . . .22 6.2 Single Trust Point model19 6. Security Considerations . . . . . . . . . . . . . . . . . .22 6.2.1 Unified Domain model. 20 7. IANA Considerations . . . . . . . . . . . . . . . . . .22 6.2.2 Bridge model. . . 21 8. References . . . . . . . . . . . . . . . . . . . .23 7 Operational Considerations. . . . . . 22 8.1. Normative References . . . . . . . . . . .26 7.1 Directory. . . . . . . . 22 8.2. Informative References . . . . . . . . . . . . . . . . . .26 7.2 Cross-Certification22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . .27 7.3 Providing Directory Information Across PKI-domains. . . 24 Intellectual Property and Copyright Statements . .28 8 Security Considerations. . . . . . . .. . . . . . . . . . . 28 8.1 Certificate and CRL Profile . . . . . . . . . . . . . . . . . 28 8.2 Path Validation . . . . . . . . . . . . . . . . . . . . . . . 29 8.3 Asymmetric problem . . . . . . . . . . . . . . . . . . . . . 29 8.3.1 Hybrid trust model . . . . . . . . . . . . . . . . . . . . 29 8.3.2 Asymmetric policy mapping . . . . . . . . . . . . . . . . . 29 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Shimaoka, et al. [Page 2] INTERNET DRAFT January 2006 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 30 9.2 Informative References . . . . . . . . . . . . . . . . . . . 30 10 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 31 12 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 32 1 Introduction PKIs are 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, a complete understanding of the relationship between the establishment method and a comparison of security requirements in each certificate policies is required. In addition, all trust relationships fall into the operation based one or the certificate based one. In the multi-domain PKI they are called the multi trust point model and the single trust point model. 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 and do leave those decisions up to the designers of specific 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 the definition of PKI domain and its trust relationships for the 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 Revocation List (CRL) profiles, Repositories, and path validation. +------------------+ +-------------------+ | PKI domain | | PKI domain | | | Domain-Domain | | Shimaoka, et al. [Page 3] INTERNET DRAFT January 2006 | | 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 ARL: Authority Revocation List CA: Certification Authority CP: Certification Policy CPS: Certification Practice Statement CRL: Certificate Revocation List DN: Distinguished Name EE: End Entity PCA: Principal Certificate Authority PKI: Public Key Infrastructure RP: Relying Party 2.2 Terminology CA-CA Trust Relationship ### TBD ### Shimaoka, et al. [Page 4] INTERNET DRAFT January 2006 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 cross-certificate to a CA who has another certificate already. In this document, this wording is more broader 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. Domain Policy Domain Policy is a common certificate policy (Object Identifier) that is shared in a PKI domain. Each CAs in the PKI domain MUST be operated under the domain policy at least. Each CAs is able to have another policy for itself in addition to the domain policy. In such a case, the CAs MUST comply with both policies. The policy OID of the domain policy is used to distinguish the PKI domain from another. EE-CA Trust Relationship ### TBD ### End Entity (EE) The preferred definition of EE is based on the X.509 4th edition definition instead of that found in RFC 2828, since it includes relying parties and not just subjects of certificates as EEs. 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]. Intermediate Certificate Certificates in a certification path except the trust anchor certificate and the certificate being validated. Irresponsible EE Relying party who is not issued a certificate from a certain CA, and is irresponsible for that CA. Multi-domain PKI A set of PKI domains which interoperate each other. Shimaoka, et al. [Page 5] INTERNET DRAFT January 2006 PKI In this document, this wording is more limited than the definition in RFC 2828. PKI in this document means a minimal system operated under unique policy. PKI domain PKI domain can consist of a set of CAs which are possibly operated by different organizations under shared CP even though each of them may have additional CPs that differ. Posterior PKI domain This term is used to describe the relative trust relationship of adjoined PKI domains in the certification path and is used in combination with the term "prior PKI domain". The next trusted PKI domain(s) in the certification path from the trust anchor to the target certificate is called the posterior PKI domain. That is, the posterior PKI domain is trusted from the prior PKI domain. 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. Prior PKI domain This term is used to describe the relative trust relationship of adjoined PKI domains in the certification path and is used in combination with the term "posterior PKI domain". The previous PKI domain in the certification path from the trust anchor to the target certificate is called the prior PKI domain. That is, the prior PKI domain trusts the posterior PKI domain. First prior PKI domain in the certification path is the PKI domain trusted directly by a relying party. Relying Party (RP) Entity who trusts a trust anchor and may not be issued the certificates. Responsible EE Relying party who is issued a certificate from a certain CA, and is responsible for that CA. Shimaoka, et al. [Page 6] INTERNET DRAFT January 2006 Subordination Subordination is a mechanism to authorize the existence of a subject CA. The authorization of the existence means issuing a certificate called subordinate (CA) certificate to a CA who has no certificate. Subscriber This is an equivalent term with the responsible EE. 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. 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 a unified domain model, a unificate CA SHOULD be used as defined later in this section. Trust Anchor Starting point of a certification path specified by a relying party. Relying party SHOULD specify the CA which has self-signed certificate as a trust anchor. In this document, Top CA is used as a trust anchor only for Hierarchical PKI. There may not be Top CA in the other trust models. 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. Trust Relationship This word is used for two purposes. One is the "CA-CA trust relationship" which is used for the relationship between CAs. Another one is the "EE-CA trust relationship" which is used for the relationship between CA and relying parties. Validation policy Shimaoka, et al. [Page 7] INTERNET DRAFT January 2006 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 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. 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. 2.3 Assumptions In this document, each PKI MUST have a repository for supporting the path validation, but this document does not specify whether the repository is web server or directory server. 3 Trust Relationship This section describes major trust relationships for multiple PKI (CA) interconnections. All PKIs that are going to participate in multi-domain PKI SHOULD use these trust relationships for multi- domain PKI interoperability. 3.1 Operation based Trust Relationship Definition 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. Since there should be different policies for every trust anchors whether operated by the same body or not, there SHOULD be different validation policies for every trust anchors. Considerations Shimaoka, et al. [Page 8] INTERNET DRAFT January 2006 A relying party using the trust list MAY trust multiple trust anchors, but finding out a revocation of each trust anchor is more difficult than finding out it for one. Trust List +--------------------------------------------------------------+ | Trusted CA | | | | +---------------+ +---------------+ +----------------------+ | | | PKI 1 | | PKI 2 | | PKI 3 | | | | | | | | | | | | +-----+ | | +-----+ | | +-----+ | | | | +---| PCA | | | | PCA | | | | PCA |<--+ | | | | | +-----+ | | +-----+ | | +-----+ | | | | | | | | | | | | ^ | | | +-----|------|-----------|----------------|-------|------------+ | | | | | | | | | | | | | | | | | | | | v | | | | | | | | | | +----+ | | | | | | | | | | | CA |---+ | | | | | | | | | | +----+ | | | | | | | | | | | ^ | | | | | | | | v | | v | | | | | | | | | +----+ | | +----+ | | | | | | | | | | CA |---+ | | | CA |---+ | | | | | | | | +----+ | | | +----+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | v v | | v v | | v v v | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ | | | EE | | EE | | | | EE | | EE | | | | EE | | EE | | EE | | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ | +---------------+ +---------------+ +----------------------+ Figure 2 - Trust List model 3.1.1 User Trust List model Definition The model in which a trust list is managed by End Entities (EEs). Each EE is able to have its own user trust list. Characteristics EE is able to manage its own user trust list. EE is able to add or delete a trust anchor from its own user trust list. This is easier Shimaoka, et al. [Page 9] INTERNET DRAFT January 2006 than cross-certification and is 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 the EE trusts unknown PKI domain irresponsibly. If the EE trusts unknown PKI domains irresponsibly, then the issuer CA cannot apply its CP to the EE. A trust anchor MAY not apply its validation policy to the EE. Considerations EE MUST update its own user trust list when the status of CA which is included in the trust list changes, such as revocation or updating. 3.1.2 Authority Trust List model Definition The model in which a trust list is managed by the trust authority, which manages the trust anchors that are to be used by a relying party. The trust authority MAY issue multiple trust lists for some purposes or parties. EEs trusting the same trust authority may share the authority trust list given by the trust authority. Characteristics 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 Shimaoka, et al. [Page 10] INTERNET DRAFT January 2006 A subject CA in the cross-certification MUST have a self-signed 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, (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. The issuing CA SHOULD publish the cross-certificate in the repository for relying parties. In general, the cross-certificate is populated to the crossCertificatePair attribute of a repository such as a LDAP or X.500 directory server. At minimum, 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 When a subject CA does not have a self-signed certificate, such subject CA is established by another CA issuing the cross- certificate to the subject CA. This, however, means the issuer CA of the cross-certificate may not be able to recognize the existence of the subject CA because the issuer CA may not have a formal agreement or contract to the establishing 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. Shimaoka, et al. [Page 11] INTERNET DRAFT January 2006 For PKI issuing Revocation List Issuing CAs MAY issue Authority Revocation Lists (ARLs), or SHOULD at least issue full CRLs. 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.(See 3.2.3) 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 publish 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- 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 as well as EEs of PKI 1. But RPs who use the PCA of PKI 2 as the trust anchor cannot trust EEs of PKI 1. This configuration illustrates helping RPs who use the 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 | | | | | | +----+ | Shimaoka, et al. [Page 12] INTERNET DRAFT January 2006 | | | | | | 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 two self-signed CAs issue cross-certificates to each other. Characteristics Both CAs cross-certify with each other mutually. Both CAs MUST generate a crossCertificatePair that consists of 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 agree and accept more information in order to issue a cross-certificate (e.g., validity, keyUsage, and constraints) and MUST exchange the information and place these in the directory system. +---------------+ +----------------------+ | PKI 1 | | PKI 2 | | | cross-certified | | Shimaoka, et al. [Page 13] INTERNET DRAFT January 2006 | +-----+ | 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 subset of unilateral cross-certification. Definition The model in which a CA issues a certificate to a CA which has no self-signed certificate. The model in which a PKI always has 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 subordinate CAs and their EEs by trusting only the root CA. Subordination is different from unilateral cross- certification, in that the subordination model MUST NOT allow a subordinate CA to be issued a certificate by more than one issuer CAs. A subordinate CA MAY NOT necessarily require an accreditation, such as WebTrust or license under the e-signature law. The accreditation is rather required only for the superior CA Shimaoka, et al. [Page 14] INTERNET DRAFT January 2006 or the root CA. Although a full third party accreditation of the subordinate CA is not required, it is the responsibility of the superior or root CA to ensure it issues CA certificates only to CAs that operate under its accredited policies and procedures. In this case, accreditation means that the subordinate CA can inherit the benefit of the trustworthiness of the superior CA. An existence of the subordinate CA is dependent on the superior CA. The subordinate CA is dependent on the superior CA for its existing. 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 domain, 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 relationship will change from the subordination model into the unified domain model as described in section 6.2.2. 4 PKI Domain 4.1 Requirements for PKI domain PKIs in a PKI domain SHOULD share a common "domain policy" consisting of one or more CPs. The CPs of the domain policy SHOULD be populated in the certificate policies extension for each certificate. The PKI domain MUST have at least one principal CA that can be trusted by other PKI domains. The PKI domain MUST have a mechanism to propagate certificate status information to other PKI domains. The PKI domain SHOULD agree to a minimum common certificate profile. Shimaoka, et al. [Page 15] INTERNET DRAFT January 2006 All CAs in a PKI domain MUST be operated under a CPS that conforms to the domain policy. All CAs in a PKI domain MUST be able to issue a certificate under including a valid CP of the domain policy. 4.2 Risk Analysis of non-interoperable PKI domains A PKI domain that satisfies the requirements presented in section 4.1 of this document MAY be used in the multi-trust or single-trust point model. However when one PKI domain interconnects with another PKI domain, the following items need to be considered to reduce the risk of being non-interoperable: - Namespace Conflicts A PKI domain SHOULD agree to use namespaces that do not overlap. If the PKI domain namespaces overlap, a namespace conflict occurs resulting in the name constraints extension possibly not being able to perform the specified name constraint as intended. - PKI Domain Policy in Certificates CAs of PKI domains SHOULD populate the certificate policy extension with the PKI domain policy. If the PKI domain policy is not described in the certificate policies extension, the path validation MAY fail when the relying parties use the certificate policies extension to identify the25 Shimaoka, et al. Expires January 10, 2007 [Page 2] Internet-Draft multi-domain PKIdomain.interoperability July 2006 1. Introduction 1.1. Objective ThePKI domain policyobjective of this document isnecessary in path validation through the PKI domains that use policy constraints or policy mapping. - Certificate Authority Certification Path Constraints A CA that wantstoassert constraints for the certification path MUST explicitly include the extensions for the constraints in the certificates that the CA issues, sinceestablish a standard terminology thatCA assumes the validation policycan be used bya relying party which MAY NOT be under the CA's control. By explicitly including the constraints in certificates, a certification path that otherwise would validate will fail, regardless of a relying party's path validation settings or configuration. For example; Assume the CA-X expects its RPs to evaluate an appropriate CP in the path validation. Even if 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 theredifferent Public Key Infrastructure (PKI) authorities who areresponsible EEs and irresponsible EEs. A responsible EE may set the flag to TRUE, but an irresponsible EE may not. Therefore, CA-X SHOULD issue a certificate which uses requireExplicitPolicy explicitly in the policyConstraints extension. If CA-X issues Shimaoka, et al. [Page 16] INTERNET DRAFT January 2006 all certificates which use requireExplicitPolicy in the policyConstraints extension, RP MUST evaluate the CP whether it has responsibility or not. - End Entity Certification Path Constraints Some PKI domains that require an explicit policy MAY NOT assert the requiredExplicitPolicy constraint in certificates they issue. These PKI domains assume the relying parties will configure their validation policy appropriately. A PKI domain requiring an explicit domain policy SHOULD set the following validation policy for its end entities: * user-initial-policy-set which includes its own domain policy OID. * initial-explicit-policy set to TRUE. *considering establishing trustanchor which is the principal CA of its PKI domain. - Distributionrelationships with each other. The document defines different types ofCertificate and Certificate Status Information A PKI domain SHOULD make certificate and certificate revocation lists (CRLs) available using LDAP or HTTP. This provides the ability for other certificate status protocols such as OCSPpossible trust relationships, identifies design andSCVPimplementation considerations that PKIs should implement to facilitate trust relationships across PKIs, and identifies issues that should beimplemented without requiring theconsidered when implementing trust relationships. 1.2. Document Outline Section 2 (Section 2) describes basic PKIdomain providing the certificates and CRLSterminology necessary toimplement the protocol. If certificate and certificate status information is not made availableconsider trust relationships. Section 3 (Section 3) focuses on trust relationships established by relying parties. Section 4 (Section 4) defines a PKIdomain, certification paths passing through that PKIdomainMAY not be constructedandvalidated. 4.3 Trust Relationship Disclosure Requirementsrequirements formulti-domain PKIs For any multi-domain PKI model, each PKI domain SHOULD show the trust relationship(s) it has with otherPKIdomains as follows: * Posteriorinteroperation within a PKIdomain X SHOULD show itsdomain. Section 5 defines requirements for interoperation across PKIarchitecture todomains. Finally, Section 6 provides a glossary summarizing theprior PKI domain Y, becauseterms described in thetrust relationship fromremainder of thePKI domain Ydocument. 1.3. Requirements and Assumptions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are tothe PKI domain X MAY depend on such PKI architecture. * Posterior PKI domain X SHOULD show allbe interpreted as described in RFC 2119 [3]. Shimaoka, et al. Expires January 10, 2007 [Page 3] Internet-Draft multi-domain PKIdomainsinteroperability July 2006 2. Terminology 2.1. Basic Concepts The following terms defining basic constructs are used throughout this document. Where possible, definitions found in RFC 2828 [2] have been used. Additional terms from RFC 2828 [2] and new terms thatit trusts to the prior PKI domain Y, because the prior PKI domain Y MUST NOT trust an unnecessary PKI domain. * Posterior PKI domain X MAY publish what PKI domains it is trusted bydefine relationships between these constructs are introduced and defined in later sections. A full list of terms can be found in Section 6 [8.1]. Certificate A digitally-signed data structure that attests toprior PKI domain Y, because PKI domain Y MAY considertheother certification pathsbinding of a system entity's identity toPKI domain X. In addition,aPKI domain SHOULD givepublic key value. [modified from theappropriate policy mappings betweenRFC 2828 definition of public-key certificate] Certificate Policy "A named set of rules that indicates theprior PKI domainsapplicability of a certificate to a particular community and/or class of application with common security requirements." (X.509) [5] Certification Authority (CA) An entity that issues certificates (especially X.509 certificates) andthe posterior PKI domainsvouches forcertificate based trust relationship. 5 Single-domain PKI Shimaoka, et al. [Page 17] INTERNET DRAFT January 2006 This section describestheappropriate PKI architectures for establishingbinding between the data items in asingle PKI domain. All PKIscertificate. (RFC 2828) [2] End Entity A system entity thatare going to participate in multi-domain PKI SHOULD adopt any of the following models for multi-domain PKI interoperability. 5.1 Single CA PKI model Thisis thesimplest PKI model which is a special case of a hierarchical PKI which has no subordinate CAs. All PKIs in this model are composed using this building blocksubject of aCAcertificate andits EE. Definition Single PKI consists of a single self-signed CAthat is using, or is permitted andits EEs. All EEs MUST be issued their certificates byable to use, the matching private key onlyCA. Trust anchor The trust anchor MUST be the self-signed certificate of the CA. +----+ +---| CA |---+ | +----+ | | | | | | | v v v +----+ +----+ +----+ | EE | | EE | | EE | +----+ +----+ +----+ Figure 5 - Single PKI model 5.2 Hierarchy PKI model This is a typical architecture of PKI. Definition Hierarchy PKI consists offor asingle root CA,purpose or purposes other than signing anumber of subordinate CAs, and EEs. Onlycertificate; i.e., an entity that is not a CA. (RFC 2828) [2] Relying Party A system entity that depends on theroot CA MUST issuevalidity of information (such as another entity's public key value) provided by aself-signedcertificate.All subordinate CAs MUST have only one superior CA. Trust anchor[from the RFC 2828 definition of certificate user] Trustanchor MUST beAnchor A certificate upon which a relying party relies as being valid without theroot CA. All EEs SHOULD trust onlyneed for validation testing. [modified from theroot CA. +---------+RFC 2828 definition of trusted certificate] Shimaoka, et al.[Page 18] INTERNET DRAFTExpires January 10, 2007 [Page 4] Internet-Draft multi-domain PKI interoperability July 2006+---| top CA |---+ | +---------+ | | | | | v v +----+ +----+ +-----| CA | +-----| CA |------+ | +----+ | +----+ | | | | v v v +----+ +----+ +----+ +--| CA |-----+ | CA |-+ +---|2.2. Certification Authority Relationships Certification Authorities (CA) establish trust relationships by issuing certificates to other CAs. 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 consistsrelationships can be either hierarchical or peer. There are three types ofmultiple CAs and their EEs. Allcertificates that are issued by CAsMUST be cross-certified with more than oneto other CAs, self-signed certificates, subordinate CAunilaterally. Some CAs MAY cross-certify mutually. Trust anchorcertificates, or peer cross-certificates. Thetrust anchor for a relying party whoprocess of issuing cross-certificates isissued a certificate from a CA in the mesh PKI SHOULDknown as cross-certification, which can be either unilateral or bilateral. Self-Signed Certificate A certificate for which theCA who issuedpublic key bound by the certificatetoand therelying party. The trust anchor forprivate key used to sign therelying party who is not issued acertificatefromare components of themesh PKI MAY be any CA insame key pair, which belongs to themesh PKI. Considerationssigner. (RFC 2828) [2] Cross-Certificate Atrust anchor which does not have a self-signedcertificateis authorized byissued from one CA to another CA.In such a case,Subordinate CA Certificate A certificate issued from one CA to another CA which becomes that CA's own signing certificate. Because therelying parties may not recognizeCA that is therevocationsubject of the subordinate CA certificate uses the subordinate CAeven ifcertificate as its own signing certificate, the issuing CApublishesauthorizes therevocation information about that CA. Therefore, this document recommends that relying party SHOULD only trust other self-signed CAs. If there is no self-signed CA in that mesh, i.e. all CAs inexistence of themesh certify with each other,subordinate CA. [modified from therelying parties SHOULD choose a trust anchorRFC 2828 definition of subordinate certification authority] Peer Cross-Certificate A certificate issued fromthose CAs carefully. For Shimaoka, et al. [Page 19] INTERNET DRAFT January 2006 example, a relying party may choose aone CA to another CA where the CA that ishighly unlikely to be revoked. This model SHOULD be used sparingly, becausethe subject of thecomplexity in certification path building. However, one should not assume that this modelcross-certificate does notexistuse the cross- certificate as its own signing certificate. Cross-Certification The act or process of issuing a cross-certificate. Note that this definition is notimplemented. A Full Mesh PKI,the same as the definition in RFC 2828 [2], which only addresses bilateral cross-certification. Unilateral Cross-Certification The act or process by whichisonewhere all CAs inCA certifies thePKI mutually cross-certify each other directly, MAY be useful for certification path building, because it is able to reach any prior PKI domain directly without passing throughpublic key of anotherPKI domain. 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 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 inby issuing amulti-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 ablepeer cross-certificate tobe obtained through some distribution methods.that other CA. [modified from the RFC 2828 definition of cross-certification] Bilateral Cross-Certification Shimaoka, et al.[Page 20] INTERNET DRAFTExpires January2006 - 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 multiple10, 2007 [Page 5] Internet-Draft multi-domain PKIdomainsinteroperability July 2006 The act or process by which two CAs each certify atrust list. Considerations If the ownerpublic key of thetrust list adds aother by each CAinissuing a peer cross-certificate to theexisting certification path, it SHOULD do so carefully sinceother CA. [modified from the RFC 2828 definition of cross-certification] 2.2.1. Hierarchical In aconstrainthierarchical relationship, as shown in Figure xxx, one CA assumes a parent relationship to thecertification path MAY NOT be evaluated correctly. The reasonother CA. +----+ | CA | +----+ | | | v +----+ | CA | +----+ Figure 1: Hierarchical Trust Relationship There are two types of hierarchical relationships, depending on whether a subordinate CA certificate or a peer cross-certificate is used. In thefollowing: Assume certification path X->Y->Z->EE(Z) exists. When cross-case where one CA issues a subordinate CA certificateX->Y includes pathLenConstraints=1, CA-Z cannot extendto another, thecertification path started from CA-X by more cross certificates. However, ifCA at therelying party trusts CA-Y directly,top of thecross certificate constraint in X->Yhierarchy, which must itself have a self-signed certificate, isignored allowing CA-Zcalled a Root CA. In the case where one CA issues peer cross-certificates toextendother CAs, that CA is called a Unifying CA. Unifying CAs only use unilateral peer cross- certificates. Root CA A CA that is at thecertification path bytop of a hierarchy, and itself does not issue certificates to end entities (except those required for its own operation) but issues subordinate CA certificates to one or morecross certificates. Thus,CAs. Unifying CA A CA that is at therelying party MUST recognizetop of a hierarchy, and itself does not issue certificates to end entities (except those required for its own operation) but establishes unilateral cross-certification with other CAs. Shimaoka, et al. Expires January 10, 2007 [Page 6] Internet-Draft multi-domain PKI interoperability July 2006 2.2.2. Peer In arisk of trusting another CA directly. Most of the actual public PKIspeer relationship, no parent child relationship is created. To establisha multi-trust point model without a domain policy. When using such public PKIs, this document recommends: - user-initial-policy-set SHOULD NOT be specified, - and initial-explicit-policy SHOULD NOTpeer relationships, only peer cross-certificates are used. Peer relationships can betrue.either unilateral or bilateral, as shown in Figure 2. Unilateral Bilateral Cross-Certification Cross-Certification +----+ +----+ +----+ +----+ | CA | ---> | CA | | CA | <--> | CA | +----+ +----+ +----+ +----+ Figure 2: Peer Trust Relationship Ingeneral, since it is difficult fortheEE to check if a CA's self- signed certificate has been revoked,case where a CASHOULD announce itexists only toall its EEs when themanage peer cross-certificates, that CA iscompromised and MAYcalled a Bridge CA. CAs can establish unilateral or bilateral cross-certification with a bridge CA, as shown in Figure 3. Bridge CA A CA that itself does not issuethe CRL. Anyway, for announcementcertificates toallend entities (except those required for itsEEs, theown operation) but establishes unilateral or bilateral cross-certification with other CAs. Bilateral Cross-Certification +----+ +----+ | CASHOULD do the best: phoning, emailing, press release, and etc. In the multi-trust point model,| <-------+ +-------> | CA | +----+ | | +----+ v v +-----------+ | Bridge CA | +-----------+ +----+ | | +----+ | CA | <-------+ +-------> | CA | +----+ +----+ Unilateral Cross-Certification Figure 3: Bridge CA 2.3. Public Key Infrastructure (PKI) RFC 2828 [2] defines acompromised trust anchor SHOULD be removed from the trust list,PKI as "a system of CAs...that perform some set of certificate management, archive management, key management, andthe removal SHOULD be performed by the subject managing the trust list. 6.1.1 Based on User Trust List Considerationstoken management functions for a community of users in an Shimaoka, et al.[Page 21] INTERNET DRAFTExpires January 10, 2007 [Page 7] Internet-Draft multi-domain PKI interoperability July 2006This isapplication of asymmetric cryptography." However, this definition does not provide asimplegood concept of a PKI boundary e.g., when two CAs enter a trust relationship, under what circumstances are they becoming part of the same PKI andtypical method for makingwhen are they creating a trust relationshipto another PKI domain.between two distinct PKIs. Therelying party MUST understanddefinition of PKI in this document adds a boundary constraint to the definition. Public Key Infrastructure (PKI) A system of CAs that perform some set of certificatestatusmanagement, archive management, key management, and token management functions for a community ofthe trust anchorusers inthean application of asymmetric cryptography and share trustlist. 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 domainsrelationships, operate under a single Certificate Policy, and arerelated by Cross- Certification. This cross-certification iseithermutualoperated by a single organization orunilateral.under the direction of a single organization. Inthis model, only one trust anchor is required by EEs. Considerations Each PKI domain MAY use policy mapping for crossing different PKI domains. Ifaddition, a PKIdomain wantsthat intends torestrictenter into trust relationships with other PKIs MUST designate acertification path, the PKI domainPrincipal CA that will manage all trust relationships. This Principal CA SHOULDNOT rely on the validation policy ofalso be the trust anchor for relyingparty, but SHOULD includeparties of that PKI. Principal CA A CA which has a self-signed certificate and is designated as theconstraintsCA that will issue peer cross-certificates to principal CAs in other PKIs and be thecross- certificate explicitly. For example, when each PKI domain wants to affectsubject of peer cross-certificates issued by principal CAs in other PKIs. In discussing different possible architectures for PKI, theconstraints toconcept of a certificationpath, it SHOULD setpath is necessary. A certification path is built based on trust relationships between CAs. Certification Path An ordered sequence of certificates where therequireExplicitPolicy to zeroissuer of each certificate in thepolicyConstraints extension of any cross-certificates. A PKI domain that relies onpath is thevalidation policysubject of therelying party about such constraints cannot guaranteenext certificate in theconstraints will be recognizedpath. A certification path begins with an end entity certificate andfollowed. 6.2.1 Unified Domain model (based on unilateral Cross-Certification) The model in which multiple PKI domains haveends with ajoint superior CA that issues cross-certificates to eachtrust anchor certificate. 2.3.1. Simple PKIdomain unilaterally. SuchDefinition A simple PKI consists of ajoint superiorsingle CAis defined as unificate CA. This model is used aswith amethodself-signed certificate which issues certificates tounify or reconfigure the multipleEEs, as shown in Figure 4. Shimaoka, et al. Expires January 10, 2007 [Page 8] Internet-Draft multi-domain PKIdomains to oneinteroperability July 2006 +----+ | CA | +----+ | +------+------+ v v v +----+ +----+ +----+ | EE | | EE | | EE | +----+ +----+ +----+ Figure 4: Simple PKIdomain by subordinatingModel Trust Anchor The trust anchor MUST be theindividual PKI domains. Except that Principal CAs transformed into subordinate CAs have bothself-signedcertificates and intermediate certificates issued by the Unificate CA, this model looks like a subordination model withcertificate of theUnificateCA. Principal CAas the trust anchor acrossThe principal CA MUST be the CA. 2.3.2. Hierarchical PKIdomains. Therefore, this model is often used like the hierarchy model in multi-domain PKI. cross-certified cross-certified Unificate CA toDefinition A hierarchical PKI1 +--------------+ Unificateconsists of a single root CA and one or more subordinate CAs that issue certificates toPKI 3 +---------| UnificateEEs. The root CA MUST have a self-signed certificate and all subordinate CAs MUST have subordinate CA|---+ | +--------------+ |certificates, as shown in Figure 5. Shimaoka, et al.[Page 22] INTERNET DRAFTExpires January 10, 2007 [Page 9] Internet-Draft multi-domain PKI interoperability July 2006 +---------+ || | | cross-certified| | | UnificateRoot CA | +---------+ | +------------+------------+ v v +----+ +----+ |to PKI 2 | | +-----------|---+ +-----------|---+ +----|-----------------+ | PKI 1 | | | PKI 2 |CA | | CA |PKI 3+----+ +----+ | | +------+------+ +--------+-------+ v| |v| |v v v +----+ +----+ +----+ +----+ +----+ || +-----+ | | +-----+ | | +-----+ | | +---| PCA | | | | PCA | | | | PCA |<--+ | | | +-----+ | | +-----+ | | +-----+ | | | | | | | | | | ^EE | | EE | | EE | | CA | | CA | +----+ +----+ +----+ +----+ +----+ | | +---+--+ +------+------+ v v v v v| | | | | | | | | |+----+ +----+ +----+ +----+ +----+ | EE | | EE | | EE | | EE | | EE ||+----+ +----+ +----+ +----+ +----+ Figure 5: Hierarchical PKI Model Trust Anchor The trust anchor MUST be root CA. Principal CA|---+ | | | | | | | |The principal CA MUST be the root CA. 2.3.3. Mesh PKI Definition A mesh PKI consists of multiple self-signed CAs that issue certificates to EEs and issue peer cross-certificates to each other. A mesh PKI MAY be a full mesh, where all CAs issue peer cross- certificates to all other CAs, as shown in Figure 6. A mesh PKI MAY be a partial mesh, where all CAs do not issue peer cross- certificates to all other CAs. In a partial mesh PKI, certification paths may not exist from all CAs to all other CAs, as shown in Figure 7. Shimaoka, et al. Expires January 10, 2007 [Page 10] Internet-Draft multi-domain PKI interoperability July 2006 +-----+ +--------> | CA1 |+----+<------+ | +-----+ | | | | | +---+--+ | | v v | | +----+ +----+ |^| | EE | | EE | | | +----+ +----+ | v| |v +-----+ +-----+ | CA2 | <---------------> | CA3 | +-----+ +-----+ | || | |+---+--+ +------+------+ v v v v v +----+ +----+ +----+ +----+| |+----+ | EE | | EE | | EE | | EE | |+---| CA | | | | CA |---+ | | | | | | | |EE | +----+| |+----+ +----+ +----+ +----+ Figure 6: Full Mesh PKI model +-----+ +-------> | CA1 | --------+ | +-----+ | | | | | +---+--+ | | v v | | +----+ +----+ | | | EE | | EE | | | +----+ +----+ | v v +-----+ +-----+ | CA2 | | CA3 | +-----+ +-----+ | || | | v v | |+---+--+ +------+------+ v v| |v v v| | +----+ +----+ | |+----+ +----+| |+----+ +----+ +----+ || | EE | | EE | | | |EE | | EE | || |EE | | EE | | EE || |+----+ +----+| | +----+ +----+ | |+----+ +----+ +----+| +---------------+ +---------------+ +----------------------+Figure8 - Unified Domain model 6.2.2 Bridge7: Partial Mesh PKI model Trust Anchor Shimaoka, et al. Expires January 10, 2007 [Page 11] Internet-Draft multi-domain PKI interoperability July 2006 Themodeltrust anchor for a relying party who is issued a certificate from a CA inwhich everythe mesh PKIdomain trusts each other through a BridgeSHOULD be the CAby Cross-Certification. In this model,who issued the certificate to the relying party. The trustrelationshipanchor for the relying party who is notestablished betweenissued asubscriber domain andcertificate from the mesh PKI MAY be any CA in the PKI. In arelying party domain directly, but established throughpartial mesh, selection of theBridge CA. This is usefultrust anchor may result in no certification path from the trust anchor to one or more CAs in the mesh. For example, in Figure xxx above, selection of CA1 or CA2 as the trust anchor will result in paths from all end entities inreducingthenumberfigure. However, selection ofcross-certifications required for a PKI domain to interoperate with other PKI domains. Requirements for Bridge model - Bridge CA MUST NOT be usedCA3 as the trust anchor will result inany PKI domain. - Bridge CA SHOULD issue cross-certificates with other PKI domains mutuallycertification paths only for those EEs whose certificates were issued by CA3. No certification path exists to CA1 or CA2. Principal CA The principal CA MAYissue cross certificates unilaterally. - Bridgebe any CAMUST NOT issue EE certificates except when it is necessary forwithin theCA's operation. - Bridge CA MUST use its own domain policy inPKI. However, thepolicy mapping between a priormesh PKIdomainMUST have only one principal CA, and aposterior PKI domain. Shimaoka, et al. [Page 23] INTERNET DRAFT January 2006 - The domain policy of Bridge CAtrust path MUSTbe a subset ofexist from theprior PKI domain policy that is mapped. - The domain policy of Bridgeprincipal CAMUSTto every CA within the PKI. Considerations This model SHOULD bea supersetused sparingly, especially the partial mesh model, because of theposteriorcomplexity of determining trust anchors and building certification paths. A full mesh PKIdomain policy that is mapped. - Bridge CA SHOULDMAY bea neutral positionuseful for certification path building, because paths of length one exist from all CAs to allPKI domains which trust throughother CAs in theBridge CA. Cross-Certificate from prior PKI domain to Bridge CA issuerDomainPolicy := Priormesh. 2.3.4. Hybrid PKIdomain policy subjectDomainPolicy := Bridge CA domain policy Cross-Certificate from Bridge CA to posteriorDefinition A hybrid PKIdomain issuerDomainPolicy := Bridge CA domain policy subjectDomainPolicy := Posterioris a PKIdomain policy - Cross-Certificates issued by Bridge CAthat uses a combination of peer cross- certificates andCross-Certificate issued to Bridgesubordinate CASHOULD includecertificates to define therequireExplicitPolicy withCAs that are a part of the PKI. Trust Anchor The trust anchor for avalue thatrelying party who isgreater than zero in the policyConstraints extension. - Cross-certificateissuedto Bridge CA SHOULD include the requireExplicitPolicy withavalue that is greater than zerocertificate from a CA in thepolicyConstraints extension. - Cross-certificate issued by Bridge CA SHOULD NOT include any constraints to keep its neutral position. -mesh PKIdomains cross-certified with Bridge CASHOULDNOT cross- certify directly to other PKI domains cross-certified withbe thesame Bridge CA. - BridgeCASHOULD clarify the method forwho issued thepolicy mapping of cross-certificationcertificate tokeep its transparency. Considerationsthe relying party. TheBridge CA SHOULD be operated by a neutral trusted third party agreed upon bytrust anchor for thePKIs or consortium consisting ofrelying party who is not issued a certificate from thePKIs. The Bridgemesh PKI MAY be any self-signed CASHOULD do policy mappingina well documented and agreed upon manner with all PKI domains. For usingthename constraints, the BridgePKI. Principal CASHOULD pay attention to preventing a conflict of each name space of the cross-certifiedShimaoka, et al. Expires January 10, 2007 [Page 12] Internet-Draft multi-domain PKIdomains.interoperability July 2006 The principal CA MAY be any CA within the PKIdomainsthatperform cross-certification with the Bridge CA SHOULD confirmhas a self- signed certificate. However, thefollowing: - Doeshybrid PKI MUST have only one principal CA, and a trust path MUST exist from theBridgeprincipal CAperform the policy mapping via its own domain policy? - Does the Bridgeto every CAclarifywithin themethodPKI. Considerations This model SHOULD be used sparingly because ofpolicy mapping inthecross-certification? - Iscomplexity of determining trust anchors and building certification paths. However, hybrid PKIs may occur as a result of theBridge CA ableevolution of a PKI over time, such as CAs within an organization joining together to become a single PKI. Shimaoka, et al. Expires January 10, 2007 [Page 13] Internet-Draft multi-domain PKI interoperability July 2006 3. Trust Lists Relying parties MAY choose toaccepttrust multiple PKIs through thedomain policyuse of trust lists. Trust lists can be managed by an individual relying party or by a trust authority thatthe prior PKI domain desires? * If the domain policyismappedshared by multiple relying parties. Trust List A list of one or more trust anchors used by a relying party to explicitly trust a PKI. Trust Authority An entity that manages a centralized trust list for onewithor more relying parties. Figure 8 shows an example of alower security level, the prior PKI domain SHOULD NOT accept it.trust list that contains a simple PKI, a hierarchical PKI, and a full mesh PKI. Shimaoka, et al.[Page 24] INTERNET DRAFTExpires January2006 Otherwise, the prior PKI domain MUST carefully consider the risks involved with accepting certificates with a lower security level. cross-certified cross-certified PKI 1 with BCA +-----------+10, 2007 [Page 14] Internet-Draft multi-domain PKI3 with BCA +------->| Bridge CA |<------+ | +-----------+ | | ^ | | cross-certified |interoperability July 2006 Trust List +--------------------------------------------------------------+ | Trust Anchors |PKI 2 with BCA| | | +---------------+ +---------------+ +----------------------+ | |+-----------|---+ +-----------|---+ +----|-----------------+| PKI 1 | ||PKI 2 | || |PKI 3 | |v | | v | | v | | +-----+ | | +-----+ | | +-----+ | | +---| PCA | | | | PCA | | | | PCA |<--+| | |+-----+ | | +-----+ | | +-----+ | || | | | | | | +----+ |^| +----+ | | +----+ | | | | | CA | | |v| CA | | | | CA | <-----+ | | | | +----+ | | +----+ | | +----+ | | | | | | |CA |---+ | | | | | || | | |+----+^ | | | +---------|-----------------|-------------|----------|---------+ | | | | | | | |^| | | +---+--+ | | v | | | v | | v v | || | | |+----+ | | | +----+ | | +----+ +----+ | | | CA | | | | || +---|CA | | | |CA |---+ |EE | | EE | | | +----+ | | | +----+ | | +----+ +----+ | | | | | | ^ | | | | | +---+--+ | | v | | | +---------------+ | v v | | +----+ | | | | +----+ +----+ | | | CA | <---+ | | |v v| EE |v v| EE |v v v| | +----++----+| |+----+ +----+|| +----++----+ +----+ | | |EE| |EE| | | |EE+---+--+ | +---------------+ | v v v |EE| +----+ +----+ +----+ | | | EE | | EE | | EE | | | +----+ +----+| | +----+ +----+ | | +----+ +----+ +----+ | +---------------+ +---------------+ +----------------------+ 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 Shimaoka, et al. [Page 25] INTERNET DRAFT January 2006 When CA-X cross-certifies CA-Y unilaterally, both CAs SHOULD operate their directory server in the following way. CA-X SHOULD generate the 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 the following crossCertificatePair and store it in its own directory entry. issuedToThisCA := cross-certificate for CA-Y issued by CA-X issuedByThisCA := NULL (2) Mutual cross-certification Each CA MUST generate a crossCertificatePair that consists of the cross-certificate it issues and the cross-certificate it is issued. CA-X SHOULD generate the following crossCertificatePair and store it in its own directory entry: issuedToThisCA := cross-certificate for CA-X issued by CA-Y issuedByThisCA := cross-certificate for CA-Y issued by CA-X CA-Y SHOULD generate the following crossCertificatePair and store it in its own directory entry: issuedToThisCA := cross-certificate for CA-Y issued by CA-X issuedByThisCA := cross-certificate for CA-X issued by CA-Y In the mutual cross-certification model, each CA SHOULD NOT individually generate two crossCertificatePairs each containing only one cross-certificate, similar to the unilateral cross- certification model. (3) Subordination A superior CA MAY store a subordinate CA certificate to issuedByThisCA element of crossCertificatePair attribute in its own entry for the reverse path building. However, it SHOULD be only for compatibility with the reverse path building, since a path building for subordination SHOULD be the forward direction. A superior CA SHOULD NOT store a subordinate CA certificate in its own entry for the forward path building. A subordinate CA MAY store its own subordinate CA certificate to the issuedToThisCA element of the crossCertificatePair attribute in its own (subordinate CA) entry for the forward path building. A subordinate CA MUST store its own subordinate CA certificate to the cACertificate attribute in its own entry. Shimaoka, et al. [Page 26] INTERNET DRAFT January 2006 7.2 Cross-Certification When updating the Cross-Certificate: There is a standard method for what+----+ | +----------------------+ Figure 8: Trust List 3.1. Relying Party Trust List Model Any Relying Party MAY choose todo whentrust certificates issued by across- certificate is updatedPKI bymodifying some ofinstalling a trust anchor for that PKI into itscontents, e.g., policy identifier. When issuer CA-X re-issueslocal trust list. Installing across-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 publish it to their own directory system. Until this is done,PKI's trust anchor into a local trust list thechange of cross- certificationisnot reflected completely in certification paths. In addition, CA-X MUST revoketheold cross-certificatesimplest method for relying parties toCA-Y when CA-Xtrust EE certificates issued by that PKI. Using local trust lists does notintend to enable the oldrequire cross-certificate. The reason why both CAs MUST update each crossCertificatePair iscertification between the PKI that issued the relyingparty may use the issuedToThisCA attribute of the crossCertificatePair (in subject CA-Y entry ofparty's own certificate and therepository)other PKI. Nor does it require implementing mechanisms fortracing theprocessing complex certificationpath. 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 havepaths. As amigration period up toresult, theexpiration of the originally issued self-issued certificate. When the keypair of the subject CA is compromised: When the keypair of subject CA-Ylocal trust list model iscompromised, issuer CA-X MUST revoke the cross-certificate for subject CA-Y, then CA-X SHOULD removethecrossCertificatePair attribute for CA-Y from its repository. 7.3 Providing Directory Information Across PKI-domains The directory infrastructures used by individualmost common model in use today. Considerations Shimaoka, et al. Expires January 10, 2007 [Page 15] Internet-Draft multi-domain PKIdomainsinteroperability July 2006 Relying parties who choose todistribute certificates and CRLs usually consist of eitherinstall trust anchors for PKIs that they are not also subscribers to do not necessarily create aset of interconnected or stand alone directories. An interconnected directory infrastructure connects directories viarelationship with theuse ofPKI. The relying party may be relying on certificates for adirectory protocol suchpurpose that is not supported by the PKI aschaining, replicating, or shadowing. An interconnected directory infrastructure allowsdefined in the PKI's certificate policy. Also, the relyingpartiesparty will not be directly informed if the trust anchor's certificate is revoked, and so MUST check the PKI's repository toreduceverify thenumberstatus ofdirectories they need tothe trust anchor. Relying parties MUST be aware ofin orderthese considerations when making a decision toobtain certificates and CRLs. However,use thistechniquemodel. PKIs that are directly installed into relying party trust lists MAYleadchoose toinfrastructure propagation delays as directory Shimaoka, et al. [Page 27] INTERNET DRAFT January 2006 information is updated or changed. Directory infrastructures composed of stand alone directories provide certificate and CRL information from a set (list) of directories the relyingcross-certify other PKIs. Relying partiesare aware of. If a directory is queried but cannot satisfy the request, it MAY provide referralsMUST implement appropriate controls toanother directoryensure thatmight be ablethey do not inadvertently trust certificates from cross-certified PKIs that they did not intend toprovide the requested information. To help promote interoperability,trust. For example: Assume certification path X->Y->Z->EE(Z) exists. When cross- certificate X->Y includes pathLenConstraints=1, CA-Z cannot extend thePKI domains SHOULD provide access tocertification path started from CA-X by more cross certificates. However, if thePKI domain's directory infrastructure via LDAP or HTTP and information to access (e.g. IP address or FQDN) at least one ofrelying party trust CA-Y directly, thePKI domain's directories. EE SHOULD be able to process LDAP referralscross certificate constraint inorder to operate with a set of stand alone directories. 8 Security Considerations 8.1 Certificate and CRL Profile Defining the concrete Certificate and CRL profile for multi-domain PKI interoperabilityX->Y isnot within the scope of this memo. All Certificates and CRLs MUST comply with [RFC 3280]. In addition, CAs in a multi-domain PKI SHOULD consider the following forignored allowing CA-Z to extend theCertificate and CRL profile: * Extensions intended for processing onlycertification path by more cross certificates. Thus, relying party MUST recognize alocal PKI domain SHOULD be non-critical. * The cRLDistributionPoints extension SHOULD be used for obtainingrisk of trusting another CA directly. PKIs that intend to support therevocation list. distributionPoint fieldrelying party trust list model SHOULDinclude also the UniformResourceIdentifier. When the CRLpublish their certificate policies so that relying parties can determine if their use isseparated into ARL and CRL,supported under theissuingDistributionPoint extensionpolicy. PKIs SHOULD alsobe used. * The Authority Key Identifier extension and Subject Key Identifier extension SHOULD be used for assisting in path construction. * The policyIdentifier fieldbroadly publicize any revocation of a trust anchor CA or theCertificate Policies extension SHOULD be used for identifying each policy domain. * The Policy Mapping extensionprincipal CA (email, repository, press release, etc.). 3.2. Trust Authority Model A relying party MAYbe used for validatingchoose to trust certificates issued by PKIs thatmutual domain policiesareequivalent. *themselves trusted by a trust authority. TheName Constraints extensiontrust authority MAYNOT be usedmanage multiple trust lists formulti-domain PKI because the name space of multi-domain PKI is not manageduse bya singledifferent relying parties. In this trust authorityallowing formodel, thepossibility of a name space conflict. Iftrust authority acts as aname space conflict exists,third party broker between relying parties and trusted PKIs. There are currently no commercially available products that support thename constraint extension MAY unintentionally excludetrust authority model. However, this model may be useful when aPKI domain. Ifnumber of relying parties within aPKI domain uses the name constraints in multi-domain PKI, the PKI domain SHOULD pay attention for conflicts incommunity of interest wish to centrally manage trusted PKIs and where thePKI domain name spaces. 8.2 Path ValidationPKIs that issue certificates to EEs within this community of interest do not themselves desire to cross-certify. Considerations Shimaoka, et al.[Page 28] INTERNET DRAFTExpires January 10, 2007 [Page 16] Internet-Draft multi-domain PKI interoperability July 2006Validation policy used for path validation is the intersectionAll ofauthority-constrained parameters and user-constrained parameters. An authority-constrained parameter SHOULD NOT assumethevalidation policy of a relying party, but SHOULD be included inconsiderations for thecertificates explicitly. A Relyingrelying partyMUST carefully determine its validation policies, includingtrust list model apply to the trustanchor. 8.3 Asymmetric problem 8.3.1 Hybridauthority model. Where possible, trust authorities SHOULD register with the PKIs they include in their trustmodel This clause considers the caselists so that they can be informed of changes inwhichPKIdomains trust each other by differentcertificate policies or revocation of a trustrelationship models such as useranchor CA or the principal CA. Relying parties using trustlists and unilateral cross-certificationauthorities are relying on the accuracy of the trustmodels. Inter-domainlist as maintained by the trustrelationships do not have toauthority. Relying parties MAY also besymmetric. Since inter-domain trust relationships in this document are defined as directionalrelying on the trustrelationships, there is no additional requirementauthority to provide revocation information for CA and EE certificates. As ahybridresult, trustmodel. What each PKI domain does is merely the same as a symmetricauthorities SHOULD provide information to relying parties for how additional trustrelationship model. For example when PKI domain-X trusts PKI domain-Y byanchors are added to theusertrust listmodelandPKI domain-Y trusts PKI domain-Xwhat network and other security controls are maintained byunilateral cross-certification, PKI domain-X merely has to comply withtheusertrustlist model,authority to ensure reliability andPKI domain-Y with the unilateral cross-certification model. 8.3.2 Asymmetric policy mapping This clause considers the case where a resultaccuracy of thepolicy mapping in mutual cross-certification model is asymmetric. This document does not strongly recommend using asymmetric mapping because the following unequivalent mapping often creates a security hole. +-------+ 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 create an unforeseen security hole ininformation provided by thecertification path. E.g., CA-X that cross-certified to PCA-1 with cP-1.1 MAY be able to grow its certification path to anothertrust anchor. Shimaoka, et al. Expires January 10, 2007 [Page 17] Internet-Draft multi-domain PKI interoperability July 2006 4. PKI Domain 4.1. Requirements for PKI domainvia PCA-1 by cP-1.2. Since different policy identifiers managed by the same4.2. Risk Analysis of non-interoperable PKI domains 4.3. Trust Relationship Disclosure Requirements for multi-domain PKIs Shimaoka, et al. Expires January 10, 2007 [Page 18] Internet-Draft multi-domain PKI interoperability July 2006 5. Abbreviations PKI: Public Key Infrastructure CA: Certification Authority EE: End Entity CRL: Certificate Revocation List ARL: Authority Revocation List PCA: Principal Certification Authority RP: Relying Party CP: Certificate Policy CPS: Certification Practice Statement DN: Distinguished Name Shimaoka, et al. Expires January 10, 2007 [Page 19] Internet-Draft multi-domain PKIactuallyinteroperability July 2006 6. Security Considerations TBD. Shimaoka, et al. Expires January 10, 2007 [Page29] INTERNET DRAFT20] Internet-Draft multi-domain PKI interoperability July 2006 7. IANA Considerations This document has no actions for IANA. Shimaoka, et al. Expires January 10, 2007 [Page 21] Internet-Draft multi-domain PKI interoperability July 2006describe different policies, differing policy identifiers mapped unexpectedly in the same entity represent 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. 98. References9.18.1. Normative References[RFC 3280][1] Housley, R., Polk, W., Ford, W.,Polk, W.and D. Solo, "Internet X.509 Public Key Infrastructure Certificate andCRLCertificate Revocation List (CRL) Profile", RFC 3280, April 2002.[RFC 2256] Wahl, M., "A Summary of the X.500(96) User Schema[2] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000. [3] Bradner, S., "Key words for usewith LDAPv3",in RFCs to Indicate Requirement Levels", BCP 14, RFC2256, Dec2119, March 1997.[ISO-X509] ITU-T Recommendation X.509 (2005 E): Information[4] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002. [5] International International Telephone and Telegraph Consultative Committee, "Information Technology - Open Systems Interconnection - The Directory: AuthenticationFramework, August 2005. 9.2Framework", CCITT Recommendation X.509, March 2000. 8.2. Informative References [6] Housley, R. and W. Polk,W., JOHN WILEY & SONS, INC.,"Planning for PKI",AugAugust 2001. [7] Lloyd, S., Ed. and PKI Forum, "PKI Interoperability Framework", March 2001. [8] Lloyd, S., Ed. and PKI Forum, "CA-CA Interoperability", March 2001. [9] Shimaoka, M., NPO Japan Network Security Association, and ISEC, Information Technology Promotion Agency, Japan, "Interoperability Issues for multi PKI domain",JulJuly 2002. [10] NPO Japan Network SecurityAssociation,Association and ISEC, Information Technology Promotion Agency, Japan, "Implementation Problems on PKI", Feb 2003. [11] Japan PKI Forum, Korea PKI Forum, PKI Forum Singapore, and Chinese Taipei PKI Forum, "Achieving PKI Interoperability 2003",JulJuly 2003. [12] Japan PKI Forum, Korea PKI Forum, and PKI Forum Singapore, "Achieving PKI Interoperability",AprApril 2002.Shimaoka, et al. [Page 30] INTERNET DRAFT January 2006[13] Cooper, M., Dzambasow, Y., Hesse, P., Joseph,S.S., and R. Nicholas,R.,"Internet X.509 Public Key Infrastructure: Shimaoka, et al. Expires January 10, 2007 [Page 22] Internet-Draft multi-domain PKI interoperability July 2006 Certification Path Building", RFC 4158, September2005. 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 authors 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 consists 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 Address2005. Shimaoka, et al. Expires January 10, 2007 [Page 23] Internet-Draft multi-domain PKI interoperability July 2006 Authors' Addresses MasakiSHIMAOKAShimaoka SECOM Co., Ltd. IntelligentSystems Lab.System Laboratory SECOM SC Center,8-10-16,8-10-16 Shimorenjaku Mitaka, Tokyo 181-8528JAPANJP Email:shimaoka@secom.ne.jp /shimaoka@secom.ne.jp, m-shimaoka@secom.co.jp NelsonE.HastingsNISTNational Institute of Standard and Technology 100 Bureau Drive, Stop 8930 Gaithersburg, MD 20899-8930USA EMail:US Email: nelson.hastings@nist.gov Rebecca Nielsen Booz Allen Hamilton 8283 Greensboro Drive McLean, VA 22102USAUS Email: nielsen_rebecca@bah.com12 Full Copyright StatementShimaoka, et al.[Page 31] INTERNET DRAFTExpires January 10, 2007 [Page 24] Internet-Draft multi-domain PKI interoperability July 2006Copyright (C) The Internet Society (2006). 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 Statement 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. 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 atietf- ipr@ietf.org.ietf-ipr@ietf.org. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Shimaoka, et al. Expires January 10, 2007 [Page32]25] ----