view Side-By-Side changes
Network Working Group M. Shimaoka, Ed.Internet-DraftRequest for Comments: 5217 SECOMIntended status:Category: Informational N. HastingsExpires: December 6, 2008NIST R. Nielsen Booz Allen HamiltonJune 4,July 2008 Memorandum formulti-domainMulti-Domain Public Key Infrastructure Interoperabilitydraft-shimaoka-multidomain-pki-13Status ofthisThis MemoBy 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 ofThis memo provides information for the InternetEngineering 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.community. Itis inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The listdoes not specify an Internet standard ofcurrent Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The listany kind. Distribution ofInternet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 6, 2008. Shimaoka, et al. Expires December 6, 2008 [Page 1] Internet-Draft multi-domain PKI interoperability June 2008this memo is unlimited. Abstract The objective of this document is to establish a terminology framework and to suggest the operational requirements of Public Key Infrastructure (PKI) domain for interoperability of multi-domain Public Key Infrastructure, where each PKI domain is operated under a distinct policy. This document describes the relationships between Certification Authorities (CAs), provides the definition and requirements for PKI domains, and discusses typical models of multi- domain PKI. Shimaoka, et al.Expires December 6, 2008Informational [Page2] Internet-Draft multi-domain1] RFC 5217 Multi-Domain PKIinteroperability JuneInteroperability July 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .43 1.1. Objective . . . . . . . . . . . . . . . . . . . . . . . .43 1.2. Document Outline . . . . . . . . . . . . . . . . . . . . .43 2. Public Key Infrastructure (PKI) Basics . . . . . . . . . . . .53 2.1. Basic Terms . . . . . . . . . . . . . . . . . . . . . . .53 2.2. RelationshipsBetweenbetween Certification Authorities . . . . .64 2.2.1. Hierarchical CA Relationships . . . . . . . . . . . .65 2.2.2.Peer-to-peerPeer-to-Peer CA Relationships . . . . . . . . . . . .76 2.3. Public Key Infrastructure (PKI) Architectures . . . . . .87 2.3.1. Single CA Architecture . . . . . . . . . . . . . . . .97 2.3.2. Multiple CA Architectures . . . . . . . . . . . . . .98 2.4. Relationships between PKIs and Relying Parties . . . . . .1312 3. PKI Domain . . . . . . . . . . . . . . . . . . . . . . . . . .1412 3.1. PKI Domain Properties . . . . . . . . . . . . . . . . . .1413 3.2. Requirements for Establishing and Participating in PKI Domains . . . . . . . . . . . . . . . . . . . . . . . . .1513 3.2.1. PKI Requirements . . . . . . . . . . . . . . . . . . .1513 3.2.2. PKI Domain Documentation . . . . . . . . . . . . . . .1514 3.2.3. PKI Domain Membership Notification . . . . . . . . . .1615 3.2.4. Considerations for PKIs and PKI Domains with Multiple Policies . . . . . . . . . . . . . . . . . .1716 3.3. PKI Domain Models . . . . . . . . . . . . . . . . . . . .1816 3.3.1. Unifying Trust Point (Unifying Domain) Model . . . . .1816 3.3.2. Independent Trust Point Models . . . . . . . . . . . .1917 3.4. Operational Considerations . . . . . . . . . . . . . . . .2321 4. Trust Models External to PKI Relationships . . . . . . . . . .2422 4.1. Trust List Models . . . . . . . . . . . . . . . . . . . .2422 4.1.1. Local Trust List Model . . . . . . . . . . . . . . . .2422 4.1.2. Trust Authority Model . . . . . . . . . . . . . . . .2523 4.2. Trust List Considerations . . . . . . . . . . . . . . . .2624 4.2.1. Considerations for a PKI . . . . . . . . . . . . . . .2624 4.2.2. Considerations for Relying Parties and Trust Authorities . . . . . . . . . . . . . . . . . . . . .2624 4.2.3. Additional Considerations for Trust Authorities . . .2725 5. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . .2825 6. Security Considerations . . . . . . . . . . . . . . . . . . .2925 6.1. PKI Domain Models . . . . . . . . . . . . . . . . . . . .2925 6.2. Trust List Models . . . . . . . . . . . . . . . . . . . .2926 7.IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 8.References . . . . . . . . . . . . . . . . . . . . . . . . . .32 8.1.27 7.1. Normative References . . . . . . . . . . . . . . . . . . .32 8.2.27 7.2. Informative References . . . . . . . . . . . . . . . . . .32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Intellectual Property and Copyright Statements . . . . . . . . . . 3427 Shimaoka, et al.Expires December 6, 2008Informational [Page3] Internet-Draft multi-domain2] RFC 5217 Multi-Domain PKIinteroperability JuneInteroperability July 2008 1. Introduction 1.1. Objective The objective of this document is to establish a terminology framework and to provide the operational requirements, which can be used by different Public Key Infrastructure (PKI) authorities who are considering establishing trust relationships with each other. The document defines different types of possible trust relationships, identifies design and implementation considerations that PKIs should implement to facilitate trust relationships across PKIs, and identifies issues that should be considered when implementing trust relationships. This document defines terminology and interoperability requirements for multi-domain PKIs from one perspective. A PKI domain can achieve multi-domain PKI interoperability by complying with the requirements in this document. However, there are other ways to define and realize multi-domain PKI interoperability. 1.2. Document Outline Section 2(Section 2)introduces the PKI basics, which provide a background for multi-domain PKI. Section 3(Section 3)provides the definitions and requirements of 'PKI domain' and describes the typical models of multi-domain PKI. Section 4(Section 4)considers the Trust ListmodelsModels depending on relying party-CA relationships (not CA-CA trustrelationship which isrelationships, as they are not a focus of this document). Section 5(Section 5)identifies abbreviations used in the document.Shimaoka, et al. Expires December 6, 2008 [Page 4] Internet-Draft multi-domain PKI interoperability June 20082. Public Key Infrastructure (PKI) Basics 2.1. Basic Terms The following terms are used throughout this document. Where possible, definitions found in RFC 4949 [RFC4949] have been used. Certificate: A digitally signed data structure that attests to the binding of a system entity's identity to a public keyvalue.value (based on the definition ofpublic-keypublic key certificate in RFC 4949[RFC4949])[RFC4949]). Certificate Policy: A named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common securityrequirements.requirements (X.509[CCITT.X509.2000])[CCITT.X509.2000]). Note that to avoid confusion, this document uses the terminology "Certificate Policy Document" to refer to the document that defines therules,rules and "Policy Object Identifier (OID)" to specify a particular rule set. Shimaoka, et al. Informational [Page 3] RFC 5217 Multi-Domain PKI Interoperability July 2008 Certificate Policy Document: A document that defines the rules for the issuance and management of certificates and identifies Policy Object Identifiers(OID(s))(OIDs) for these rules. A Certificate Policy Document may define more than one Policy OID. Policy Object Identifier (Policy OID): An identifier applied to a set of rules governing the issuance and management of certificates. Policy OIDs are defined in the Certificate Policy Documents. Certification Authority (CA): An entity that issues certificates (especially X.509 certificates) and vouches for the binding between the data items in acertificate.certificate (RFC 4949[RFC4949])[RFC4949]). End Entity (EE): A system entity that is the subject of a certificate and that is using, or is permitted and able to use, the matching private key only for a purpose or purposes other than signing a certificate; i.e., an entity that is not aCA.CA (RFC 4949[RFC4949])[RFC4949]). RelyingParty:party: A system entity that depends on the validity of information (such as another entity's public key value) provided by acertificate.certificate (from the RFC 4949 [RFC4949] definition of certificateuser) Shimaoka, et al. Expires December 6, 2008 [Page 5] Internet-Draft multi-domain PKI interoperability June 2008user). 2.2. RelationshipsBetweenbetween Certification Authorities CAs establish trust relationships by issuing certificates to other CAs. CA relationships are divided into 'certification hierarchy' [RFC4949] and 'cross-certification' [RFC4949]. In a certification hierarchy, there are two types ofCAs, superior CACAs: 'superior CA' and 'subordinateCA'CA', as described in RFC 4949 [RFC4949]. Superior CA: A CAwhichthat is an issuer of a subordinate CA certificate. A cross-certification can be either unilateral or bilateral. Unilateral cross-certification: Cross-certification of one CA (CA1) by another CA (CA2) but no cross-certification of CA2 by CA1. Bilateral cross-certification: Cross-certification of one CA (CA1) by another CA (CA2) and cross-certification of CA2 by CA1. Shimaoka, et al. Informational [Page 4] RFC 5217 Multi-Domain PKI Interoperability July 2008 2.2.1. Hierarchical CA Relationships In a hierarchical relationship, as shown in Figure 1, one CA assumes a parent relationship to the other CA. +----+ | CA | +----+ | v +----+ | CA | +----+ Figure 1: Hierarchical CA Relationship There are two types of hierarchical relationships, depending on whether a subordinate CA certificate or a unilateral cross- certificate is used. In the case where one (superior) CA issues a subordinate CA certificate to another, the CA at the top of the hierarchy, which must itself have a self-signed certificate, is called aRootroot CA. In the case where one CA issues unilateral cross- certificates to other CAs, the CA issuing unilateral cross- certificates is called a Unifying CA. Unifying CAs use only unilateral cross-certificates. NOTE: In this document, the definition ofRootroot CA is according to the second definition (context for hierarchical PKI) of 'root CA' in RFCShimaoka, et al. Expires December 6, 2008 [Page 6] Internet-Draft multi-domain PKI interoperability June 20084949 [RFC4949]. This document uses the terminology'Trust Anchor'trust anchor CA' for the first definition (context for PKI) of'Root'root CA' in RFC 4949. Root CA: A CA that is at the top of a hierarchy, and itself should not issue certificates to end entities (except those required for its own operation) but issues subordinate CA certificates to one or more CAs. Subordinate CA: A CA whosepublic-keypublic key certificate is issued by another superior CA, and itself must not be used as aTrust Anchortrust anchor CA. Unifying CA: A CA that is at the top of a hierarchy, and itself should not issue certificates to end entities (except those required for its own operation) but establishes unilateral cross- certification with other CAs. A Unifying CA must permit CAs to which it issues cross-certificates to have self-signed certificates. Shimaoka, et al. Informational [Page 5] RFC 5217 Multi-Domain PKI Interoperability July 2008 2.2.2.Peer-to-peerPeer-to-Peer CA Relationships In a peer relationship, no parent-child relationship is created. To establish peer relationships, only cross-certificates are used. Peer relationships can be either unilateral or bilateral, as shown in Figure 2. Bilateral Unilateral Cross-Certification Cross-Certification +----+ +----+ +----+ +----+ | | ---> | | | CA | ---> | CA | | CA | | CA | +----+ +----+ | | <--- | | +----+ +----+ Figure 2:Peer-to-peerPeer-to-Peer CA Relationships In the case where a CA exists only to manage cross-certificates, that CA is called a Bridge CA. CAs can establish unilateral or bilateral cross-certification with a Bridge CA, as shown in Figure 3. Bridge CA: A CAthat itselfthat, itself, does not issue certificates to end entities (except those required for its own operation) but establishes unilateral or bilateral cross-certification with other CAs.Shimaoka, et al. Expires December 6, 2008 [Page 7] Internet-Draft multi-domain PKI interoperability June 2008Bilateral Cross-Certification +----+ ----------+ +--------- +----+ | CA | | | | CA | +----+ <-------+ | | +------> +----+ | v v | +-----------+ | Bridge CA | +-----------+ +----+ | | +----+ | CA | <-------+ +-------> | CA | +----+ Unilateral +----+ Cross-Certification Figure 3: Bridge CA Shimaoka, et al. Informational [Page 6] RFC 5217 Multi-Domain PKI Interoperability July 2008 2.3. Public Key Infrastructure (PKI) Architectures Public Key Infrastructure (PKI): A system of CAs that perform some set of certificate management, archive management, key management, and token management functions for a community of users in an application of asymmetric cryptography and share trust relationships, operate under the same Certificate Policy Document specifying a shared set ofpolicyPolicy OID(s), and are either operated by a single organization or under the direction of a single organization. In addition, a PKI that intends to enter into trust relationships with other PKIs must designate a Principal CA (PCA) that will manage all trust relationships. This Principal CA should also be the trust anchor CA for relying parties of that PKI. Principal CA (PCA): A CAwhichthat should have a self-signedcertificate,certificate is designated as the CA that will issuecross- certificatescross-certificates to Principal CAs in other PKIs, and may be the subject ofcross-certificatescross- certificates issued by Principal CAs in other PKIs. In discussing different possible architectures for PKI, the concept of a certification path is necessary. A certification path is built based on trust relationships between CAs. Certification Path: An ordered sequence of certificates where the subject of each certificate in the path is the issuer of the next certificate in the path. A certification path begins with a trust anchor certificate and ends with an end entity certificate.Shimaoka, et al. Expires December 6, 2008 [Page 8] Internet-Draft multi-domain PKI interoperability June 20082.3.1. Single CA Architecture Definition: A simple PKI consists of a single CA with a self-signed certificatewhichthat issues certificates to End Entities (EEs), as shown in Figure 4. +----+ | CA | +----+ | +------+-----+ v v v +----+ +----+ +----+ | EE | | EE | | EE | +----+ +----+ +----+ Figure 4: Simple PKI Architecture Shimaoka, et al. Informational [Page 7] RFC 5217 Multi-Domain PKI Interoperability July 2008 TrustAnchoranchor CA: The trust anchor CA must be the CAwhichthat has aself-signedself- signed certificate. Principal CA: Since this PKI architecture has one CA, the Principal CA must be that CA. 2.3.2. Multiple CA Architectures 2.3.2.1. Hierarchical PKI Architecture Definition: A hierarchical PKI consists of a single root CA and one or more subordinate CAs that issue certificates to EEs. A hierarchical PKI may have intermediate CAs, which areSubordinatesubordinate CAs that themselves haveSubordinatesubordinate CAs. The root CA must distribute a trust anchor (public key and associated data), but the format and protocol are irrelevant for this specification. And all subordinate CAs must have subordinate CA certificates, as shown in Figure 5. TrustAnchoranchor CA: The trust anchor CA must be the root CA. Principal CA: The Principal CA must be the root CA.Shimaoka, et al. Expires December 6, 2008 [Page 9] Internet-Draft multi-domain PKI interoperability June 2008+---------+ | Root CA | +---------+ | +------------+------------+ v v +----+ +----+ | CA | | CA | +----+ +----+ | | +------+------+ +--------+-------+ v v v v v +----+ +----+ +----+ +----+ +----+ | EE | | EE | | EE | | CA | | CA | +----+ +----+ +----+ +----+ +----+ | | +---+--+ +------+------+ v v v v v +----+ +----+ +----+ +----+ +----+ | EE | | EE | | EE | | EE | | EE | +----+ +----+ +----+ +----+ +----+ Figure 5: Hierarchical PKI Architecture Shimaoka, et al. Informational [Page 8] RFC 5217 Multi-Domain PKI Interoperability July 2008 2.3.2.2. Mesh PKI Architectures Definition: A mesh PKI consists of multiple CAs with self-signed certificates that issue certificates to EEs and issue cross- certificates to each other. A mesh PKI may be a full mesh, where all CAs issue cross-certificates to all other CAs, as shown in Figure 6. A mesh PKI may also be a partial mesh, where all CAs do not issue 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 December 6, 2008 [Page 10] Internet-Draft multi-domain PKI interoperability June 2008+--------- +-----+ <--------+ | | CA1 | | | +------> +-----+ -------+ | | | | | | | | +---+--+ | | | | v v | | | | +----+ +----+ | | | | | EE | | EE | | | | | +----+ +----+ | | v | v | +-----+ ----------------> +-----+ | CA2 | | CA3 | +-----+ <---------------- +-----+ | | +---+--+ +------+------+ v v v v v +----+ +----+ +----+ +----+ +----+ | EE | | EE | | EE | | EE | | EE | +----+ +----+ +----+ +----+ +----+ Figure 6: Full Mesh PKI Architecture Shimaoka, et al. Informational [Page 9] RFC 5217 Multi-Domain PKI Interoperability July 2008 +--------- +-----+ | | CA1 | --------+ | +------> +-----+ | | | | | | | +---+--+ | | | v v | | | +----+ +----+ | | | | EE | | EE | | | | +----+ +----+ | v | v +-----+ +-----+ | CA2 | ----------------> | CA3 | +-----+ +-----+ | | +---+--+ +------+------+ v v v v v +----+ +----+ +----+ +----+ +----+ | EE | | EE | | EE | | EE | | EE | +----+ +----+ +----+ +----+ +----+ Figure 7: Partial MeshPKI Architecture Shimaoka, et al. Expires December 6, 2008 [Page 11] Internet-Draft multi-domain PKI interoperability June 2008PKI Architecture TrustAnchoranchor CA: The trust anchor CA for an end entity is usually the CA that issued the end entity's certificate. The trust anchor CA for an end entitywhothat is not issued a certificate from the mesh PKI may be any CA in the PKI. In a partial mesh, selection of the trust anchor may result in no certification path from the trust anchor to one or more CAs in the mesh. For example, in Figure 7 above, the selection of CA1 or CA2 as the trust anchor CA will result in paths from all end entities in the figure. However, the selection of CA3 as the trust anchor CA will result in certification paths only for those EEs whose certificates were issued by CA3. No certification path exists to CA1 or CA2. Principal CA: The Principal CA may be any CA within the mesh PKI. However, the mesh PKI must have only one Principal CA, and a certification path should exist from the Principal CA to all other CAs within the mesh PKI. Considerations: This model should be used sparingly, especially the partial mesh model, because of the complexity of determining trust anchors and building certification paths. A full mesh PKI may be useful for certification pathbuilding,building because paths of length one exist from all CAs to all other CAs in the mesh. Shimaoka, et al. Informational [Page 10] RFC 5217 Multi-Domain PKI Interoperability July 2008 2.3.2.3. Hybrid PKI Architectures Definition: A hybrid PKI is a PKIwhichthat uses a combination of the pure hierarchical model using subordinate CA certificates and the pure mesh model using cross-certificates. +-----+ <----- +-----+ | CA2 | | CA1 | +-----+ -----> +-----+ | | +---+--+ +---+--+-------+ v v v v v +----+ +----+ +----+ +----+ +-----+ | EE | | EE | | EE | | EE | | CA3 | +----+ +----+ +----+ +----+ +-----+ | +------+------+ v v v +----+ +----+ +----+ | EE | | EE | | EE | +----+ +----+ +----+ Figure 8: Hybrid PKI ArchitectureShimaoka, et al. Expires December 6, 2008 [Page 12] Internet-Draft multi-domain PKI interoperability June 2008TrustAnchoranchor CA: The trust anchor CA for a hybrid PKI may be any CA with self-issued certificates in the hybrid PKI. However, because of the potential complexity of a hybrid PKI, the PKI should provide guidance regarding the selection of the trust anchor to relying parties because a relying party may fail to build an appropriate certification path to a subscriber if they choose an inappropriate trust anchor. Principal CA: The Principal CA may be any CA within the hybrid PKI and should have a self-signed certificate for cross-certification with other PKI domains. However, the hybrid PKI must have only one PrincipalCA,CA and a certification path must exist from the Principal CA to every CA within the PKI. Considerations: This model should be used sparingly because of the complexity of determining trust anchors and building certification paths. However, hybrid PKIs may occur as a result of the evolution of a PKI over time, such as CAs within an organization joining together to become a single PKI. Shimaoka, et al. Informational [Page 11] RFC 5217 Multi-Domain PKI Interoperability July 2008 2.4. Relationships between PKIs and Relying Parties Relying Parties establish trust relationships by trust anchor to a PKI. Relying Parties may use a Trust List for establishing trust relationships to one or more PKIs. A Trust List is a set of one or more trust anchors for trusting one or more PKIs. There are two types of maintenance models of Trust List, Local Trust List Model and Trust Authority Model. The two models are described in detail in Section4.1 (Section 4.1). Shimaoka, et al. Expires December 6, 2008 [Page 13] Internet-Draft multi-domain PKI interoperability June 20084.1. 3. PKI Domain Two or more PKIs may choose to enter into trust relationships with each other. For these relationships, each PKI retains its own set of Certificate PolicyOID(s)OIDs and its own Principal CA. In addition to making a business decision to consider a trust relationship, each PKI determines the level of trust of each external PKI by reviewing external PKI Certificate Policy Document(s) and any other PKI governance documentation through a process known as policy mapping. Trust relationships are technically formalized through the issuance of cross-certificates. Such a collection of two or more PKIs is known as a PKIDomain.domain. PKIDomain:domain: A set of two or more PKIs that have chosen to enter into trust relationships with each other through the use of cross- certificates. Each PKI that has entered into the PKIDomaindomain is considered a member of that PKIDomain.domain. NOTE: This definition specifies a PKIDomaindomain recursively in terms of its constituent domains and associated trust relationships; this is different to the definition in RFC 4949 [RFC4949] that gives PKIDomaindomain as a synonym for CA domain and defines it in terms of a CA and its subject entities. Domain Policy Object Identifier: A domain Policy Object Identifier (OID) is apolicyPolicy OIDwhichthat is shared across a PKIDomain.domain. Each CA in the PKIDomaindomain must be operated under the domainpolicyPolicy OID. Each CA may also have its ownpolicyPolicy OID(s) in addition to the domainpolicyPolicy OID. In such a case, the CA must comply with both policies. The domainpolicyPolicy OID is used to identify the PKIDomain.domain. Policy Mapping: A process by which members of a PKIDomaindomain evaluate the Certificate Policies (CPs) and other governance documentation of other potential PKIDomaindomain members to determine the level of trust that each PKI in the PKIDomaindomain places on certificates issued by each other PKI in the PKIDomain.domain. Shimaoka, et al. Informational [Page 12] RFC 5217 Multi-Domain PKI Interoperability July 2008 3.1. PKI Domain Properties o A PKIDomaindomain may operate a Bridge CA or a Unifying CA that defines members of the domain by issuing cross-certificates to those members. o A single PKI may simultaneously belong to two or more PKIDomains.domains. o A PKIDomaindomain may contain PKIDomainsdomains within its own membership.Shimaoka, et al. Expires December 6, 2008 [Page 14] Internet-Draft multi-domain PKI interoperability June 2008o Two or more PKIDomainsdomains may enter into a trust relationship with each other, creating a new PKIDomain.domain. They may choose to retain the existing PKIDomainsdomains in addition to the new PKIDomain,domain or collapse the existing PKIDomainsdomains into the new PKIDomain.domain. o A member of a PKIDomaindomain may choose to participate in the PKIDomaindomain but restrict or deny trust in one or more other member PKIs of that same PKIDomain.domain. 3.2. Requirements for Establishing and Participating in PKI Domains The establishment of trust relationships has a direct impact on the trust model of relying parties. As a result, consideration must be taken in the creation and maintenance of PKIDomainsdomains to prevent creating inadvertent trust relationships. 3.2.1. PKI Requirements In order for a PKI to participate in one or more PKIDomains,domains, that PKI must have the following: o A Certificate Policy Document documenting the requirements for operation of that PKI. The Certificate Policy Document should be in RFC 3647 [RFC3647] format. o One or more PolicyOID(s)OIDs defined in the Certificate Policy Document that are also asserted in all certificates issued by that PKI. o A defined Principal CA. PKIDomainsdomains may also impose additional technical, documentation, or policy requirements for membership in the PKIDomain.domain. When participatingtoin a PKIDomain,domain, theDomaindomain Policy OID(s) must be asserted at least incross certificatescross-certificates issued by a participating PKI. After the participation, the PKI can assert theDomaindomain Policy OID(s) in certificates issued by that PKI, or may map theDomaindomain Shimaoka, et al. Informational [Page 13] RFC 5217 Multi-Domain PKI Interoperability July 2008 Policy OID(s) to the Policy OID(s) asserted in certificates issued by that PKI. 3.2.2. PKI Domain Documentation PKIDomainsdomains must be formally defined and documented. This documentation may vary greatly depending on the PKIDomain.domain. However, it must:Shimaoka, et al. Expires December 6, 2008 [Page 15] Internet-Draft multi-domain PKI interoperability June 2008o Establish the existence of the PKIDomain;domain; o Define the authority for maintaining the PKIDomain;domain; Examples of PKIDomaindomain Authorities are (1) Representatives from two PKIs that agree to form a simple PKIDomain,domain, (2) A single entitywhichthat may or may not be related to any of the PKIs in the PKIDomain,domain, (3) A governance board made up of representatives from each PKIDomaindomain member. o Define how the PKIDomaindomain is governed; o Define the purpose and community of interest of the PKIDomain;domain; and Examples of PKIDomaindomain intents are (1) allow relying parties of one PKI to trust certificates issued by another PKI, (2)Allowallow PKIs that support similar subscriber communities of interest to interact with each other, and (3)Allowallow relying parties to trust certificates issued by a number of PKIs that all meet a set of requirements. o Unless the PKIDomaindomain has a predetermined membership, describe the requirements and methods for joining the PKIDomain,domain, such as FPKIMETHOD [FPKIMETHOD]. Examples of governance documents that PKIDomainsdomains may choose to use are: o Statement of intent between two or more parties; o Memorandum of Agreement between two or more parties; o Certificate Policy Document for the PKIDomain;domain; o Charter for the PKIDomain;domain; or o Methodology for PKIDomaindomain membership. Shimaoka, et al. Informational [Page 14] RFC 5217 Multi-Domain PKI Interoperability July 2008 3.2.3. PKI Domain Membership Notification A cross-certificate from the Principal CA of one PKI to the Principal CA of another PKI indicates a mapping between one or more policies of the first PKI and one or more policies of the second PKI. When a relying party is determining if a certificate can be validated, it builds a certification path from the certificate being presented to a trust anchor. To prevent creating inadvertent trust relationships across PKIDomainsdomains when a single PKI is a member of two or moreShimaoka, et al. Expires December 6, 2008 [Page 16] Internet-Draft multi-domain PKI interoperability June 2008disparate PKIDomains,domains, each PKIDomaindomain must be cognizant of what PKIDomainsdomains in which its member PKIs participate. Figure 9 illustrates this concept. +-----------------------------+ | PKIDomaindomain 2 | +----------------------------+ | | | | | | +------+ <------ +------+ <------ +------+ | | | PKI1 | | | PKI2 | | | PKI3 | | | +------+ ------> +------+ ------> +------+ | | | | | | +-----------------------------+ | PKIDomaindomain 1 | +----------------------------+ Figure 9: Participation in Multiple PKI Domains As shown in Figure 9, PKI2 is a member of both PKIDomaindomain 1 and PKIDomaindomain 2. Since a certification path exists from PKI1 to PKI2, and from PKI2 to PKI3, a certification path also exists from PKI1 to PKI3. However, PKI1 does not share domain membership with PKI3, so the certification path validation from PKI1 to PKI3 with a validation policy for PKIDomaindomain 1 must not succeed. To ensure correct certification path validation and policy mapping, the cross- certificates issued by both PKI1 and PKI3 to PKI2 must contain constraints such as policy mapping or name constraints disallowing the validation of certification paths outside their respective domains. To fully prevent inadvertent trust, any PKI that is a member of one or more PKIDomainsdomains must inform all those PKIDomainsdomains of its membership in all other PKIDomains.domains. In addition, that PKI must inform all those PKIDomainsdomains of which it is a member, any time its membership status changes with regards to any other PKIDomain.domain. If a PKIDomaindomain is informed of the change in status of one of its member PKIs with regards to other PKIDomains,domains, that PKIDomaindomain must review the constraints in any cross-certificate issued to that PKI. If the change in membership would result in a change to the allowed or Shimaoka, et al. Informational [Page 15] RFC 5217 Multi-Domain PKI Interoperability July 2008 disallowed certification paths, the PKIDomaindomain must ensure that all such cross-certificates are revoked and re-issued with correct constraints. 3.2.4. Considerations for PKIs and PKI Domains with Multiple Policies In some cases, a single PKI may issue certificates at more than one assurance level. If so, the Certificate Policy Document must define separatepolicyPolicy OIDs for each assurance level, and must define theShimaoka, et al. Expires December 6, 2008 [Page 17] Internet-Draft multi-domain PKI interoperability June 2008differences between certificates of different assurance levels. A PKIDomaindomain may also support more than one assurance level. If so, the PKIDomaindomain must also define separatepolicyPolicy OIDs for each assurance level, and must define the differences in requirements for each level. When PKIs and PKIDomainsdomains choose to establish trust relationships, these trust relationships may exist for only one defined assurance level, may have a one-to-one relationship between PKI assurance levels and PKIDomaindomain assurance levels, or may have many-to-one or one-to-many relationships between assurance levels. These relationships must be defined in cross-certificates issued between PKIs in the PKIDomain.domain. 3.3. PKI Domain Models Two or more PKIDomainsdomains may choose to enter into trust relationships with each other. In that case, they may form a larger PKIDomaindomain by establishing a new Unifying or Bridge CA or by issuing cross- certificates between their Principal CAs. 3.3.1. Unifying Trust Point (Unifying Domain) Model In the Unifying Trust Point Model, a PKIDomaindomain is created by establishing ajointjoint, superior CA that issues unilateral cross- certificates to each PKIDomain,domain, as shown in Figure 10. Such ajointjoint, superior CA is defined as a Unifying CA, and the Principal CAs in each PKIDomaindomain have the hierarchical CA relationship with that Unifying CA. In this model, any relying party from any of the PKIDomainsdomains must specify the Unifying CA as its trust anchor CA in order to validate a subscriber in the other PKIDomains.domains. If the relying party does not desire to validate subscribers in other PKIDomains,domains, the relying party may continue to use the Principal CA from the old PKIDomaindomain as its trust anchor CA. This model may be used for merging multiple PKIDomainsdomains into a single PKIDomaindomain with less change to existing PKIDomains,domains, or may be used to combine multiple PKIDomainsdomains into one PKIDomaindomain for relying Shimaoka, et al. Informational [Page 16] RFC 5217 Multi-Domain PKI Interoperability July 2008 parties. The unilateral cross-certificate issued by the Unifying CA to the Principal CAs in each PKIDomaindomain may include any policy mapping.Shimaoka, et al. Expires December 6, 2008 [Page 18] Internet-Draft multi-domain PKI interoperability June 2008Cross-certified Cross-certified Unifying CA Unifying CA to PKIDomaindomain 1 +--------------+ to PKIDomaindomain 3 +---------| Unifying CA |---+ | +--------------+ | | | | | Cross-certified| | | Unifying CA | | | to PKIDomaindomain 2| | +-----------|---+ +-----------|---+ +----|-----------------+ | PKI | | | PKI | | | | PKI | | domain 1 | | | domain 2 | | | | domain 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 10: Unifying Trust Point (Unifying Domain) Model 3.3.2. Independent Trust Point Models In Independent Trust Point Models, relying parties continue to use only the trust anchor of their PKIDomain.domain. A relying party in the individual trust point model can continue to use the trust anchor of its PKIDomain.domain. 3.3.2.1. Direct Cross-Certification Model In this model, each PKIDomaindomain trusts each other by issuing a cross- certificate directly between each Principal CA, as shown in Shimaoka, et al. Informational [Page 17] RFC 5217 Multi-Domain PKI Interoperability July 2008 Figure 11. This model may be used for shortening a certification path or establishing a trust relationship expeditiously.Shimaoka, et al. Expires December 6, 2008 [Page 19] Internet-Draft multi-domain PKI interoperability June 2008Considerations: A PKIDomaindomain in this model needs to take into account that the other PKIDomaindomain may cross-certify with any other PKIDomains.domains. If a PKIDomaindomain wants to restrict a certification path, the PKIDomaindomain should not rely on the validation policy of the relying party, but should include the constraints in the cross-certificate explicitly. A PKIDomaindomain that relies on the validation policy of the relying party about such constraints cannot guarantee that the constraints will be recognized and followed. +---------------+ +------------------------+ | PKI | cross-certified | PKI | | domain 1 | each other | domain 2 | | +-----+ --------------------> +-----+ ----+ | | | PCA | | | | PCA | | | | +-----+ <-------------------- +-----+ <-+ | | | | | | ^ | v | | | | | | +----+ | | | | | | | CA |---+ | | | | | | +----+ | | | v | | v ^ | | | | +----+ | | +----+ | | | | | +---| CA | | | | CA |--+ | | | | | +----+ | | +----+ | | | | | | | | | | | | | v v | | v v v | | +----+ +----+ | | +----+ +----+ +----+ | | | EE | | EE | | | | EE | | EE | | EE | | | +----+ +----+ | | +----+ +----+ +----+ | +---------------+ +------------------------+ Figure 11: Direct Cross-Certification Model 3.3.2.2. Bridge Model In this model, every PKIDomaindomain trusts each other through a Bridge CA byCross-Certification,cross-certification, as shown in Figure 12. The trust relationship is not established between a subscriber domain and a relying party domain directly, but established from the Principal CA of the relying party's PKIDomaindomain via a Bridge CA. This model is useful in reducing the number of cross-certifications required for a PKIDomaindomain to interoperate with other PKIDomains.domains. Shimaoka, et al. Informational [Page 18] RFC 5217 Multi-Domain PKI Interoperability July 2008 Requirements for Bridge model: o The Bridge CA must not be used as the trust anchor CA in any PKIDomain. Shimaoka, et al. Expires December 6, 2008 [Page 20] Internet-Draft multi-domain PKI interoperability June 2008domain. o The Bridge CA should issue cross-certificates with other PKIDomainsdomains mutually or may issue cross-certificates unilaterally. o The Bridge CA must not issue End Entity (EE) certificates except when it is necessary for the CA's operation. o The Bridge CA must use its own domainpolicyPolicy OID, not other PKIDomain policydomain Policy OID(s), for the policy mapping. o The Bridge CA should be a neutral position to all PKIDomains,domains, which trust through the Bridge CA. Forexampleexample, in Figure 12, in the case that a relying party who trusts the PCA of PKIDomaindomain 1 as its trust anchor CA builds the certification path to a subscriber in PKIDomaindomain 3: Cross-Certificate from PKIDomaindomain 1 to the Bridge CA: issuerDomainPolicy ::= domainpolicyPolicy OID of PKIDomaindomain 1 subjectDomainPolicy := domainpolicyPolicy OID of the Bridge CA Cross-Certificate from the Bridge CA to PKIDomaindomain 3: issuerDomainPolicy ::= domainpolicyPolicy OID of the Bridge CA subjectDomainPolicy ::= domainpolicyPolicy OID of PKIDomaindomain 3 oCross-CertificatesCross-certificates issued by the Bridge CA andCross-Certificatecross-certificate issued to the Bridge CA should include the requireExplicitPolicy with a value that is greater than zero in the policyConstraints extension because a relying party may not set the initial- explicit-policy to TRUE. o PKIDomainsdomains cross-certified with the Bridge CA should not cross- certify directly to other PKIDomainsdomains cross-certified with the same Bridge CA. o The Bridge CA should clarify the method for the policy mapping of cross-certification to keep its transparency. Shimaoka, et al. Informational [Page 19] RFC 5217 Multi-Domain PKI Interoperability July 2008 Considerations: The Bridge CA should be operated by an independent third party agreed upon by the PKIDomainsdomains or a consortium consisting of representatives from the PKIDomaindomain members. The Bridge CA should do policy mapping in a well-documented and agreed-upon manner with all PKIDomains.domains. When applying the name constraints, the Bridge CA needs to avoid creating conflicts between the name spaces of the cross-certified PKIDomains.domains. The PKIDomainsdomains that perform cross-certification with the Bridge CAShimaoka, et al. Expires December 6, 2008 [Page 21] Internet-Draft multi-domain PKI interoperability June 2008should confirm the following: * Does the Bridge CA perform the policy mapping via its own domainpolicyPolicy OID? * Does the Bridge CA clarify the method of policy mapping in the cross-certification? * Is the Bridge CA able to accept the domain policy that the PKIDomaindomain desires? + If the domain policy is mapped to one with a lower security level, the PKIDomaindomain should not accept it. Otherwise, the PKIDomaindomain must carefully consider the risks involved with accepting certificates with a lower security level. Shimaoka, et al. Informational [Page 20] RFC 5217 Multi-Domain PKI Interoperability July 2008 cross-certified cross-certified PKIDomaindomain 1 with BCA PKIDomaindomain 3 with BCA +---------> +-----------+ -----+ | | Bridge CA | | | +-------- +-----------+ <--+ | | | ^ | | | | | cross-certified | | | | | | PKIDomaindomain 2 | | | | | | with BCA | | | | +---------|-|---+ +-----------|-|-+ +--|-|-----------------+ | PKI | | | | PKI | | | | | | PKI | |domain 1 | v | | domain 2 | v | | | v domain 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 12: Bridge ModelShimaoka, et al. Expires December 6, 2008 [Page 22] Internet-Draft multi-domain PKI interoperability June 20083.4. Operational Considerations Each PKIDomaindomain may use policy mapping for crossing different PKIDomains.domains. If a PKIDomaindomain wants to restrict a certification path, the PKIDomaindomain should not rely on the validation policy of the relying party, but should include the constraints in the cross-certificate explicitly. For example, when each PKIDomaindomain wants to affect the constraints to a certification path, it should set the requireExplicitPolicy to zero in the policyConstraints extension of any cross-certificates. A PKIDomaindomain that relies on the validation policy of the relying party about such constraints cannot guarantee the constraints will be recognized and followed. Shimaoka, et al.Expires December 6, 2008Informational [Page23] Internet-Draft multi-domain21] RFC 5217 Multi-Domain PKIinteroperability JuneInteroperability July 2008 4. Trust Models External to PKI Relationships As opposed to PKIDomaindomain trust relationships entered into by PKIs themselves, trust across multiple PKIs can be created by entities external to the PKIs through locally configured lists of trust anchors. Trust List: A set of one or more trust anchors used by a relying party to explicitly trust one or more PKIs. Note that Trust Lists are often created without the knowledge of the PKIs that are included in the list. 4.1. Trust List Models 4.1.1. Local Trust List Model A Trust List can be created and maintained by a single relying party for its own use. Local Trust List: A Trust List installed and maintained by a single relying party for its own use. NOTE: This definition is similar to "trust-file PKI" defined in RFC 4949 [RFC4949]. However, this document prefers the term "Local Trust List" contrasting with "Trust Authority" defined below. Figure 13 illustrates a Local Trust List. +-------------------------------------------------------------+ | RelyingPartyparty | | +---------------------------------------------------------+ | | | Trust List | | | | +--------------+ +--------------+ +--------------+ | | | | | PKI 1 | | PKI 2 | ... | PKI n | | | | | | TrustAnchoranchor | | TrustAnchoranchor | | TrustAnchoranchor | | | | | +--------------+ +--------------+ +--------------+ | | | +---------------------------------------------------------+ | +-------------------------------------------------------------+ Figure 13: Relying Party Local Trust List Model Creating a Local Trust List is the simplest method for relying parties to trust EE certificates. Using Local Trust Lists does not require cross-certification between the PKI that issued the relying party's own certificate and the PKI that issued the EE'scertificate. Norcertificate,nor does it require implementing mechanisms for processing complex certification paths, as all CAs in a path can be included in the Local Trust List. As a result, Local Trust Lists arethe most commonShimaoka, et al.Expires December 6, 2008Informational [Page24] Internet-Draft multi-domain22] RFC 5217 Multi-Domain PKIinteroperability JuneInteroperability July 2008 the most common model in use today. However, because Local Trust Lists are created and managed independently by eachRelying Party,relying party, the use of Local Trust Lists can be difficult for an enterprise to manage. 4.1.2. Trust Authority Model Alternatively, a Trust List can be created and maintained for using by multiple relying parties. In this case, the entity responsible for the Trust List is known as a Trust Authority. Trust Authority: An entity that manages a Trust List for use by one or more relying parties. Figure 14 illustrates a Trust Authority and how it is used by Relying Parties. Note that the Trust Authority replaces the PKITrust Anchor(s)trust anchor(s) in the Local Trust List for each participatingRelying Party.relying party. +-------------------------------------------------------------+ | Trust Authority | | +---------------------------------------------------------+ | | | Trust List | | | | +--------------+ +--------------+ +--------------+ | | | | | PKI 1 | | PKI 2 | ... | PKI n | | | | | | TrustAnchoranchor | | TrustAnchoranchor | | TrustAnchoranchor | | | | | +--------------+ +--------------+ +--------------+ | | | +---------------------------------------------------------+ | +-------------------------------------------------------------+ +---------------------+ +---------------------+ | RelyingPartyparty 1 | | RelyingPartyparty 2 | | +-----------------+ | | +-----------------+ | ... | | Trust Authority | | | | Trust Authority | | | +-----------------+ | | +-----------------+ | +---------------------+ +---------------------+ Figure 14: Trust Authority Model A Trust Authority may be operated by a PKI, a collection of relying parties that share a common set of users, an enterprise on behalf of all of its relying parties, or an independent entity. Although PKIs generally establish trust relationships through cross-certificates, a PKI may choose to provide a Trust Authority to support relying parties that do not support processing of certification paths. A collection of relying parties that share a common set of users may choose to maintain a single Trust Authority to simplify the management of Trust Lists. An enterprise may choose to provide a Shimaoka, et al. Informational [Page 23] RFC 5217 Multi-Domain PKI Interoperability July 2008 Trust Authority to implement enterprise policies and direct allShimaoka, et al. Expires December 6, 2008 [Page 25] Internet-Draft multi-domain PKI interoperability June 2008Relying Parties within the enterprise to use its Trust Authority. Finally, an independent entity may choose to operate a Trust Authority as a managed service. 4.2. Trust List Considerations 4.2.1. Considerations for a PKI A PKI should publish its Certificate Policy Document so that Relying Parties and Trust Authorities can determine what, if any, warranties are provided by the PKI regarding reliance on EE certificates. A PKI should broadly publicize information regarding revocation or compromise of aTrust Anchortrust anchor CA or Principal CA certificate through notice on a web page, press release, and/or other appropriate mechanisms so that Relying Parties and Trust Authorities can determine if aTrust Anchortrust anchor CA or Principal CA certificate installed in a Trust List should be removed. A PKI should publish Certificate Revocation Lists (CRLs) or other information regarding the revocation status of EE certificates to a repository that can be accessed by any party that desires to rely on the EE certificates. 4.2.2. Considerations for Relying Parties and Trust Authorities Relying Parties and Trust Authorities are responsible for the following prior to including a PKI in the Trust List: o Reviewing the Certificate Policy Document of each PKI to determine that the PKI is operated to an acceptable level of assurance; o Reviewing the Certificate Policy Document of each PKI to ensure any requirements imposed on Relying Parties are met; o Determining if the PKI provides any warranties regarding reliance on EE certificates, and if these warranties are acceptable for the intended reliance on the EE certificates. Reliance may be at theRelying Party'srelying party's own risk; and o Periodically reviewing information published by the PKI to its repository, including Certificate Policy Document updates or notice of CA revocation or compromise. A PKI can choose to join or leave PKIDomainsdomains in accordance with its Certificate Policy Document. If theRelying Partyrelying party or Trust Authority does not wish to inherit trust in other members of these PKIDomains,domains, Shimaoka, et al. Informational [Page 24] RFC 5217 Multi-Domain PKI Interoperability July 2008 it is the responsibility of theRelying Partyrelying party or Trust Authority toShimaoka, et al. Expires December 6, 2008 [Page 26] Internet-Draft multi-domain PKI interoperability June 2008inhibit policy mapping. 4.2.3. Additional Considerations for Trust Authorities A Trust Authority should establish a Trust Authority Policy that identifies the following: o The intended community of Relying Parties that will use the Trust Authority; o The process by whichTrust Anchorstrust anchors are added or removed from the Trust List; o Any warranties provided by the Trust Authority for reliance on EE certificates. These warranties may be those provided by the PKIs themselves or may be additional warranties provided by the Trust Authority; o Information regarding how the Trust Authority protects the integrity of its Trust List; and o Information regarding how Relying Parties interact with the Trust Authority to obtain information as to whether an EE certificate is trusted.Shimaoka, et al. Expires December 6, 2008 [Page 27] Internet-Draft multi-domain PKI interoperability June 20085. Abbreviations CA: Certification Authority EE: End Entity OID: Object Identifier PCA: Principal Certification Authority PKI: Public Key InfrastructureShimaoka, et al. Expires December 6, 2008 [Page 28] Internet-Draft multi-domain PKI interoperability June 20086. Security Considerations This section highlights security considerations related to establishing PKIDomains.domains. 6.1. PKI Domain Models For all PKIDomaindomain models described in Section 3.3(Section 3.3)created through the issuance of cross-certificates, standard threats including message insertion, modification, and man-in-the-middle are notapplicable,Shimaoka, et al. Informational [Page 25] RFC 5217 Multi-Domain PKI Interoperability July 2008 applicable because all information created by CAs, including policy mapping and constraints, is digitally signed by the CA generating the cross-certificate. Verifying that a given certificate was issued by a member of a PKIDomaindomain may be a time-critical determination. If cross-certificates and revocation status information cannot be obtained in a timely manner, a denial of service may be experienced by the end entity. In situations where such verification is critical, caching of cross- certificates and revocation status information may be warranted. An additional security consideration for PKIDomainsdomains is creating inadvertent trust relationships, which can occur if a single PKI is a member of multiple PKIDomains.domains. See Section 3.2.3(Section 3.2.3)for a discussion of creating inadvertent trust relationships and mechanisms to prevent it. Finally, members of PKIDomainsdomains must participate in domain governance, or at a minimum, be informed anytime a PKI joins or leaves the domain, so that domain members can make appropriate decisions for maintaining their own membership in the domain or choosing to restrict or deny trust in the new member PKI. 6.2. Trust List Models In these models, many standard attacks are not applicable since certificates are digitally signed. Additional security considerations apply when trust is created through atrust list.Trust List. A variation of the modification attack is possible intrust list models.Trust List Models. If an attacker is able to add or remove CAs from the relying party ortrust authority trust list,Trust Authority Trust List, the attacker can affect which certificates will or will not be accepted. To prevent this attack, access totrust listsTrust Lists must be adequately protected against unauthorized modification. This protection is especially important for trust anchors that are used by multiple applications, as it is a key vulnerability of this model. This attack may result in unauthorized usage if a CA is added to atrust list,Trust List, or denial ofShimaoka, et al. Expires December 6, 2008 [Page 29] Internet-Draft multi-domain PKI interoperability June 2008service if a CA is removed from atrust list.Trust List. Fortrust authorityTrust Authority models, adenial of servicedenial-of-service attack is also possible if the application cannot obtain timely information from the trust anchor. Applications should specify service-level agreements withtrust authority.Trust Authority. In addition, applications may choose to locally cache the list of CAs maintained by thetrust authorityTrust Authority as a backup in the event that the trust anchor's repository (e.g., Lightweight Directory Access Protocol (LDAP) directory) is not available. Shimaoka, et al.Expires December 6, 2008Informational [Page30] Internet-Draft multi-domain26] RFC 5217 Multi-Domain PKIinteroperability JuneInteroperability July 2008 7.IANA Considerations This document has no actions for IANA. Shimaoka, et al. Expires December 6, 2008 [Page 31] Internet-Draft multi-domain PKI interoperability June 2008 8.References8.1.7.1. Normative References [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.8.2.7.2. Informative References[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.[CCITT.X509.2000] InternationalInternationalTelephone and Telegraph Consultative Committee, "Information Technology - Open Systems Interconnection - The Directory: Authentication Framework", CCITT Recommendation X.509, March 2000. [FPKIMETHOD] "US Government PKI Cross-Certification Criteria and Methodology", January 2006, <http:// www.cio.gov/fpkia/documents/ crosscert_method_criteria.pdf>. [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, November 2003.[FPKIMETHOD] "US Government PKI Cross-Certification Criteria and Methodology", January 2006.[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007. Shimaoka, et al.Expires December 6, 2008Informational [Page32] Internet-Draft multi-domain27] RFC 5217 Multi-Domain PKIinteroperability JuneInteroperability July 2008 Authors' Addresses Masaki Shimaoka (editor) SECOM Co., Ltd. Intelligent System Laboratory SECOM SC Center, 8-10-16 Shimorenjaku Mitaka, Tokyo 181-8528 JPEmail:EMail: m-shimaoka@secom.co.jp Nelson Hastings National Institute of Standard and Technology 100 Bureau Drive, Stop 8930 Gaithersburg, MD 20899-8930 USEmail:EMail: nelson.hastings@nist.gov Rebecca Nielsen Booz Allen Hamilton 8283 Greensboro Drive McLean, VA 22102 USEmail:EMail: nielsen_rebecca@bah.com Shimaoka, et al.Expires December 6, 2008Informational [Page33] Internet-Draft multi-domain28] RFC 5217 Multi-Domain PKIinteroperability JuneInteroperability July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Shimaoka, et al.Expires December 6, 2008Informational [Page34]29] ----