view Side-By-Side changes
Network Working Group M. Shimaoka Internet-Draft SECOM Expires:August 17, 2007February 16, 2008 N. Hastings NIST R. Nielsen Booz Allen HamiltonFebruary 13,August 15, 2007 Memorandum for multi-domain Public Key Infrastructure Interoperabilitydraft-shimaoka-multidomain-pki-09draft-shimaoka-multidomain-pki-10 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 at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire onAugust 17, 2007.February 16, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Shimaoka, et al. ExpiresAugust 17, 2007February 16, 2008 [Page 1] Internet-Draft multi-domain PKI interoperabilityFebruaryAugust 2007 AbstractThisThe objective of this documentdesiresis to establish a standard terminologyand actual languagefor interoperability of multi-domain Public Key Infrastructure (PKI), where each PKIthat consists of several PKI domains which areDomain is operated undereacha distinct policy. This document describes the relationships between Certification Authorities (CAs), provides the definition and requirements for PKIdomains,Domains, and discusses typical models of multi-domain PKI. Shimaoka, et al. ExpiresAugust 17, 2007February 16, 2008 [Page 2] Internet-Draft multi-domain PKI interoperabilityFebruaryAugust 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Objective . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Document Outline . . . . . . . . . . . . . . . . . . . . . 4 1.3. Requirementsand AssumptionsTerminology . . . . . . . . . . . . . . . . . 4 2. Public Key Infrastructure (PKI) Basics . . . . . . . . . . . . 5 2.1. BasicConceptsTerms . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Relationships Between Certification Authorities . . . . . 5 2.2.1. Hierarchical CA Relationships . . . . . . . . . . . . 6 2.2.2. Peer-to-peer CA Relationships . . . . . . . . . . . . 7 2.3. Public Key Infrastructure (PKI) Architectures . . . . . . 8 2.3.1. Single CA Architecture . . . . . . . . . . . . . . . . 9 2.3.2. Multiple CA Architectures . . . . . . . . . . . . . .910 3. PKI Domain . . . . . . . . . . . . . . . . . . . . . . . . . .1314 3.1. PKIdomainDomain Properties . . . . . . . . . . . . . . . . . .1314 3.2. Requirements for Establishing and Participating in PKIdomainsDomains . . . . . . . . . . . . . . . . . . . . . . . . .1415 3.2.1. PKI Requirements . . . . . . . . . . . . . . . . . . .1415 3.2.2. PKI Domain Documentation . . . . . . . . . . . . . . .1415 3.2.3. PKI Domain Membership Notification . . . . . . . . . .1516 3.2.4. Considerations for PKIs and PKI Domains with Multiple Policies . . . . . . . . . . . . . . . . . .1617 3.3. PKIdomainDomain Models . . . . . . . . . . . . . . . . . . . .1618 3.3.1. Unifying Trust Point (Unifying Domain) Model . . . . .1718 3.3.2. Independent Trust Point Models . . . . . . . . . . . .1819 3.4. Operational Considerations . . . . . . . . . . . . . . . .2223 4. Trust Models External to PKI Relationships . . . . . . . . . .2324 4.1. Trust ListConsiderationsModels . . . . . . . . . . . . . . . .23. . . . 24 4.1.1.Considerations for PKILocal Trust List Model . . . . . . . . . . . . . . . .2324 4.1.2.Considerations forTrustList OwnersAuthority Model . . . . . . . . .23. . . . . . . 25 4.2. Trust ListModelsConsiderations . . . . . . . . . . . . . . . . 26 4.2.1. Considerations for a PKI . . . .24 4.2.1. Relying Party Local Trust List Model. . . . . . . . .24. . 26 4.2.2. Considerations for Relying Parties and TrustAuthority ModelAuthorities . . . . . . . . . . . . . . . .24. . . . . 26 4.2.3. Additional Considerations for Trust Authorities . . . 27 5. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . .2628 6. Security Considerations . . . . . . . . . . . . . . . . . . .2729 6.1. PKI Domain Models . . . . . . . . . . . . . . . . . . . .2729 6.2. Trust List Models . . . . . . . . . . . . . . . . . . . .2729 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . .2931 8. References . . . . . . . . . . . . . . . . . . . . . . . . . .3032 8.1. Normative References . . . . . . . . . . . . . . . . . . .3032 8.2. Informative References . . . . . . . . . . . . . . . . . .3032 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .3234 Intellectual Property and Copyright Statements . . . . . . . . . .3335 Shimaoka, et al. ExpiresAugust 17, 2007February 16, 2008 [Page 3] Internet-Draft multi-domain PKI interoperabilityFebruaryAugust 2007 1. Introduction 1.1. Objective The objective of this document is to establish a standard terminology that 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. 1.2. Document Outline ### TBD ### Section 2 describes the relevance between each entity, especially the relationship between Certification Authorities (CA), in order to understand multi-domain PKI. Section 3 describes the definitions and requirements for PKIdomains,Domains, and describes the typical models of multi-domain PKI. Although it is not focus of this document, Section 4 considers the Trust List models that depend on relying party-CA relationships not CA-CA trust relationships. Section 5 identifies abbreviations used in the document. 1.3. Requirementsand AssumptionsTerminology 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]. Shimaoka, et al. ExpiresAugust 17, 2007February 16, 2008 [Page 4] Internet-Draft multi-domain PKI interoperabilityFebruaryAugust 2007 2. Public Key Infrastructure (PKI) Basics 2.1. BasicConceptsTerms The following termsdefining basic constructsare used throughout this document. Where possible, definitions found in RFC 2828 [5] have been used.Additional terms from RFC 2828 [5] and new terms that define relationships between these constructs are introduced and defined in later sections.Certificate: A digitally-signed data structure that attests to the binding of a system entity's identity to a public key value.[modified from the RFC 2828(based on definition of public-keycertificate]certificate in RFC 2828) [5] Certificate Policy (CP):"AA named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common securityrequirements." (X.509) [3]requirements. A certificate policy may define the semantics for more than one certificate policy OID. (added on the definition in X.509 [3]) Certification Authority (CA): An entity that issues certificates (especially X.509 certificates) and vouches for the binding between the data items in a certificate. (RFC 2828) [5] 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 a CA. (RFC 2828) [5] Relying Party: A system entity that depends on the validity of information (such as another entity's public key value) provided by a certificate.[from(from the RFC 2828 definition of certificateuser]user) Trust Anchor: A certificate upon which a relying party relies as being valid without the need for validation testing.[modified from the RFC 2828(based on definition of trustedcertificate]certificate in (RFC 2828) [5] 2.2. Relationships Between Certification Authorities ### TBD ### CAs establish trust relationships by issuing certificates to other CAs. CA relationships can be either hierarchical or peer-to-peer. There are three types of certificates that are issued by CAs to other CAs, self-signed certificates, subordinate CA certificates, or peer cross-certificates. The process of issuing cross-certificates is known as cross-certification, which can be either unilateral or bilateral. Shimaoka, et al. ExpiresAugust 17, 2007February 16, 2008 [Page 5] Internet-Draft multi-domain PKI interoperabilityFebruaryAugust 2007 Self-Signed Certificate: A certificate for which the public key bound by the certificate and the private key used to sign the certificate are components of the same key pair, which belongs to the signer. (RFC 2828) [5] Cross-Certificate: A certificate issued from one CA to another CA. Subordinate CA Certificate: A certificate issued from one CA (CA-1) to another CA (CA-2) which becomesthat CA'sCA-2's own signing certificate. Becausethe CA that is the subject of the subordinate CA certificateCA-2 MUST not have a self-signed certificate and uses the subordinate CA certificate as its own signing certificate,the issuing CACA-1 authorizes the existence of thesubordinate CA.CA-2. [modified from the RFC 2828 definition of subordinate certification authority] Peer Cross-Certificate: A certificate issued from one CA (CA-1) to another CA (CA-2) wherethe CA that is the subject of the cross-certificate has issuedCA-2 uses a different certificate as its ownself-signedsigning certificate. Cross-Certification: The act or process of issuing a cross- certificate. Note that this definition is not the same as the definition in RFC 2828 [5], which only addresses bilateral cross- certification. Unilateral Cross-Certification: The act or process by which one CA (CA-1) certifies the public key of another CA (CA-2) by issuing a peercross- certificatecross-certificate tothat other CA.CA-2. [modified from the RFC 2828 definition of cross-certification] Bilateral Cross-Certification: The act or process by which two CAs (CA-1 and CA-2) each certifyathe public key of the otherby eachCA by issuing peer cross-certificates (i.e., CA-1 issues a peer cross- certificate to CA-2 and CA-2 issues a peer cross-certificate tothe other CA.CA-1) [modified from the RFC 2828 definition ofcross-certification]cross- certification] 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. Shimaoka, et al. ExpiresAugust 17, 2007February 16, 2008 [Page 6] Internet-Draft multi-domain PKI interoperabilityFebruaryAugust 2007 +----+ | CA | +----+ | v +----+ | CA | +----+ Figure 1: Hierarchical CA Relationship ### TBD ### There are two types of hierarchical relationships, depending on whether a subordinate CA certificate or a peer cross-certificate is used. In the case where one 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 a Root CA. In the case where one CA issues peer cross-certificates to other CAs, that CA is called a Unifying CA. Unifying CAs only use unilateral peer cross- certificates. ### TBD ### 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. A Root CA MUST NOT permit its subordinate CAs to issue self-signed certificates. 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. AunifyingUnifying CA MUST permit CAs to which it issues peer cross-certificates to have self-signed certificates. 2.2.2. Peer-to-peer CA Relationships In a peer relationship, no parent child relationship is created. To establish peer relationships, only peer cross-certificates are used. Peer relationships can be either unilateral or bilateral, as shown in Figure 2.UnilateralShimaoka, et al. Expires February 16, 2008 [Page 7] Internet-Draft multi-domain PKI interoperability August 2007 Bilateral Unilateral Cross-Certification Cross-Certification +----+ +----+ +----+ +----+ | | ---> | | | CA | ---> | CA | | CA |<-->| CA | +----+ +----+ | | <--- | | +----+ +----+ Figure 2: Peer-to-peer CA RelationshipsShimaoka, et al. Expires August 17, 2007 [Page 7] Internet-Draft multi-domain PKI interoperability February 2007In the case where a CA exists only to manage peer cross-certificates, that CA is called a Bridge CA. CAs can establish unilateral or bilateral cross-certification with abridgeBridge CA, as shown in Figure 3. Bridge CA: A CA that 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. Bilateral Cross-Certification +----+ ----------+ +--------- +----+ | CA |<-------+ +------->| | | CA | +----+ <-------+ | | +------> +----+ | v v | +-----------+ | Bridge CA | +-----------+ +----+ | | +----+ | CA | <-------+ +-------> | CA | +----++----+Unilateral +----+ Cross-Certification Figure 3: Bridge CA 2.3. Public Key Infrastructure (PKI) Architectures RFC 2828 [5] defines a PKI as "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." However, this definition does not provide a good 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 and when are they creating a trust relationship between two distinct PKIs. The definition of PKI in this document adds a boundary constraint to the definition. Shimaoka, et al. Expires February 16, 2008 [Page 8] Internet-Draft multi-domain PKI interoperability August 2007 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 undera singlethe same CertificatePolicy,Policy (possibly with multiple certificate policy OIDs), 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 relationshipsShimaoka, et al. Expires August 17, 2007 [Page 8] Internet-Draft multi-domain PKI interoperability February 2007with other PKIs MUST designate a Principal CA that will manage all trust relationships. This Principal CA SHOULD also be the trust anchor for relying parties of that PKI. Principal CA (PCA): A CA whichMUSTSHOULD have a self-signed certificate, is designated as the CA that will issue peercross-certificatescross- certificates toprincipalPrincipal CAs in other PKIs, and MAY be the subject of peercross- certificatescross-certificates issued byprincipalPrincipal 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. 2.3.1. Single CA Architecture Definition: A simple PKI consists of a single CA with a self-signed certificate which issues certificates to EEs, as shown in Figure 4. +----+ | CA | +----+ | +------+-----+ v v v +----+ +----+ +----+ | EE | | EE | | EE | +----+ +----+ +----+ Figure 4: Simple PKI Architecture Shimaoka, et al. Expires February 16, 2008 [Page 9] Internet-Draft multi-domain PKI interoperability August 2007 Trust Anchor: The trust anchor MUST be the self-signed certificate of the CA. Principal CA: TheprincipalPrincipal CA MUST be the CA. 2.3.2. Multiple CA Architectures 2.3.2.1. Hierarchical PKI ArchitectureShimaoka, et al. Expires August 17, 2007 [Page 9] Internet-Draft multi-domain PKI interoperability February 2007### TBD 3rd sentence in Definition### 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 are Subordinate CAs that themselves have Subordinate CAs. The root CA MUST have a self-signed certificate and all subordinate CAs MUST have subordinate CA certificates, as shown in Figure 5. Trust Anchor: The trust anchor MUST be the root CA. Principal CA: TheprincipalPrincipal CA MUST be the root CA. +---------+ | 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. Expires February 16, 2008 [Page 10] Internet-Draft multi-domain PKI interoperability August 2007 2.3.2.2. Mesh PKI Architectures Definition: A mesh PKI consists of multipleself-signedCAs with self-signed certificates that issue certificates to EEs and issue peercross-certificatescross- 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 August 17, 2007 [Page 10] Internet-Draft multi-domain PKI interoperability February 2007+--------- +-----++--------><--------+ | | 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. Expires February 16, 2008 [Page 11] Internet-Draft multi-domain PKI interoperability August 2007 +--------- +-----++------->| | CA1 | --------+ | +------> +-----+ | | | | | | | +---+--+ | | | v v | | | +----+ +----+ | | | | EE | | EE | | | | +----+ +----+ | v | v +-----+ +-----+ | CA2 | | CA3 | +-----+ +-----+ | | +---+--+ +------+------+ v v v v v +----+ +----+ +----+ +----+ +----+ | EE | | EE | | EE | | EE | | EE | +----+ +----+ +----+ +----+ +----+ Figure 7: Partial Mesh PKI ArchitectureShimaoka, et al. Expires August 17, 2007 [Page 11] Internet-Draft multi-domain PKI interoperability February 2007Trust Anchor: The trust anchor fora relying party whoan end entity isissued a certificate from a CA in the mesh PKI SHOULD beusually the CAwhothat issuedthe certificate to the relying party.its certificate. The trust anchor fora relying partyan end entity who 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, Figure 7 above, selection of CA1 or CA2 as the trust anchor will result in paths from all end entities in the figure. However, selection of CA3 as the trust anchor 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: TheprincipalPrincipal CA MAY be any CA within the mesh PKI. However, the mesh PKI MUST have only oneprincipalPrincipal CA, and a certification path SHOULD exist from theprincipalPrincipal 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 path building, because paths of length one exist from all CAs to all other CAs in the mesh. Shimaoka, et al. Expires February 16, 2008 [Page 12] Internet-Draft multi-domain PKI interoperability August 2007 2.3.2.3. Hybrid PKI Architectures ### TBD illustrating an example ### Definition: A hybrid PKI is a PKIthatwhich usesacombination ofpeer cross-certificates andboth the pure hierarchical model using subordinate CA certificatesto define the CAs that are a part ofand thePKI.pure mesh model using peer cross-certificates. Trust Anchor: The trust anchor for a hybrid PKI MAY be anyself- signedCA with self-issued certificates in the hybrid PKI. However, because of the potential complexity of a hybrid PKI, the PKI SHOULD provide guidanceto relying partiesregarding 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 he/she chooses inappropriate trust anchor. Principal CA: TheprincipalPrincipal CA MAY be any CA within the hybrid PKIthat hasand SHOULD have a self-signedcertificate.certificate for cross-certification with other PKI domain. However, the hybrid PKI MUST have only oneprincipalPrincipal CA, and a certification path MUST exist from theprincipalPrincipal 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. ExpiresAugust 17, 2007February 16, 2008 [Page12]13] Internet-Draft multi-domain PKI interoperabilityFebruaryAugust 2007 3. PKI Domain ### TBD for single CP issue ### Two or more PKIs may choose to enter into trust relationships with each other. For these relationships, each PKI retains its own Certificate Policy and its own Principal CA. Prior to establishing the trust relationship, each PKI determines the level of trust of each external PKI by reviewing external PKI CP(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 PKI Domain. PKI 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 PKI Domain is considered a member of that PKI Domain. ### TBD for single CP issue ### Domain Policy Object Identifier: A domain Policy Object Identifier (OID) is a policy OID which is shared across a PKIdomain.Domain. Each CA in the PKIdomainDomain MUST be operated under the domain policy OID. Each CA MAY also have its own policy OID in addition to the domain policy OID. In such a case, the CA MUST comply with both policies. The domain policy OID is used to identify the PKIdomain.Domain. Policy Mapping: A process by which members of a PKI Domain evaluate the CPs and other governance documentation of other potential PKI Domain members to determine the level of trust that each PKI in the PKI Domain places on certificates issued by each other PKI in the PKI Domain. 3.1. PKIdomainDomain Properties o A PKI Domain 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 PKI Domains. o A PKI Domain MAY contain PKI Domains within its own membership. o Two or more PKI Domains MAY enter into a trust relationship with each other. In this case, they MAY combine into a single PKI Domain or retain the existing PKI Domains and define a new PKI Shimaoka, et al. Expires February 16, 2008 [Page 14] Internet-Draft multi-domain PKI interoperability August 2007 Domain with the existing PKI Domains as members. o A member of a PKI Domain MAY choose to participate in the PKI Domain but restrict or deny trust in one or more other member PKIs of that same PKI Domain.Shimaoka, et al. Expires August 17, 2007 [Page 13] Internet-Draft multi-domain PKI interoperability February 20073.2. Requirements for Establishing and Participating in PKIdomainsDomains 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 PKI Domains to prevent inadvertent trust. 3.2.1. PKI Requirements In order for a PKI to participate in one or more PKI Domains, that PKI MUST have the following: o A CP documenting the requirements for operation of that PKI. The CP SHOULD be in RFC 3647 [4] format. o One or more Policy OID defined in the CP that are also asserted in all certificates issued by that PKI o A defined Principal CA PKI Domains MAY also impose additional technical, documentation, or policy requirements for membership in the PKI Domain. 3.2.2. PKI Domain Documentation ### TBD for "complexity" ### PKI Domains MUST be formally defined and documented. Although the complexity of this documentation may vary greatly depending on the type of PKI Domain, it MUST address the following: o Establish the existence of the PKI Domain. o Define the authority for maintaining the PKI Domain. Examples of PKI Domain Authorities are (1) Representatives from two PKIs that agree to form a simple PKI Domain, (2) A single entity which may or may not be related to any of the PKIs in the PKI Domain, (3) A governance board made up of representatives from each PKI Domain member. Shimaoka, et al. Expires February 16, 2008 [Page 15] Internet-Draft multi-domain PKI interoperability August 2007 o Define how the PKI Domain is governed. o Define the purpose and community of interest of the PKI Domain. Examples of PKI Domain intents are (1) allow relying parties of one PKI to trust certificates issued by another PKI, (2) Allow PKIs that support similar subscriber communities of interest to interact with each other, (3) Allow relying parties to trust certificates issued by a number of PKIs that all meet a set ofShimaoka, et al. Expires August 17, 2007 [Page 14] Internet-Draft multi-domain PKI interoperability February 2007requirements. o Unless the PKI Domain has a predetermined membership, describe the requirements and methods for joining the PKI Domain, such as FPKIMETHOD [14]. Examples of governance documents that PKI Domains MAY choose to use are: o Statement of intent between two or more parties o Memorandum of Agreement between two or more parties o CP for the PKI Domain o Charter for the PKI Domain o Methodology for PKI Domain membership 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 inadvertent trust across PKI Domains when a single PKI is a member of two or more disparate PKI Domains, each PKI Domain must be cognizant of what PKI Domainsit'sits member PKIs participate in. Figure 8 illustrates this concept. Shimaoka, et al. Expires February 16, 2008 [Page 16] Internet-Draft multi-domain PKI interoperability August 2007 +-----------------------------+ | PKIdomainDomain 2 | +----------------------------+ | | | | | | +------+|<------ +------+|<------ +------+ | | | PKI1 |<----->| | PKI2 |<----->| | PKI3 | | | +------+|------> +------+|------> +------+ | | | | | | +-----------------------------+ | PKIdomainDomain 1 | +----------------------------+ Figure 8: Participation in Multiple PKI Domains As shown in Figure 8, PKI2 is a member of both PKI Domain 1 and PKI Domain 2. Since a certification path exists from PKI1 to PKI2, and from PKI2 to PKI3, a certification path also exists from PKI1 toShimaoka, et al. Expires August 17, 2007 [Page 15] Internet-Draft multi-domain PKI interoperability February 2007PKI3. However, PKI1 does not share domain membership with PKI3, so the certification path validation from PKI1 to PKI3 with a validation policy for PKI Domain 1MUST NOTmust not succeed. To ensure correct certification path validation and policy mapping, the cross certificates issued by both PKI1 and PKI3 to PKI2MUSTmust 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 PKI Domains MUST inform all PKI Domains of its membership in all other PKI Domains. In addition, that PKI MUST inform all PKI Domains that it is a member of any time its membership status changes with regards to any other PKI Domain. If a PKI Domain is informed of the change in status of one of its member PKIs with regards to other PKI Domains, that PKI Domain 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 disallowed certification paths, the PKI Domain 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 ### TBD for single CP issue ### In some cases, a single PKI MAY issue certificates at more than one assurance level. If so, the CP MUST define separate policy OIDs for each assurance level, and MUST define the differences between certificates of different assurance levels. A PKI Domain MAY also support more than one assurance level. If so, Shimaoka, et al. Expires February 16, 2008 [Page 17] Internet-Draft multi-domain PKI interoperability August 2007 the PKI Domain MUST also define separate policy OIDs for each assurance level, and MUST define the differences in requirements for each level. When PKIs and PKI Domains 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 PKI Domain 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 PKI Domain. 3.3. PKIdomainDomain 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 newunifyingUnifying orbridgeBridge CA or by issuing cross certificates between theirprincipalPrincipal CAs.Shimaoka, et al. Expires August 17, 2007 [Page 16] Internet-Draft multi-domain PKI interoperability February 20073.3.1. Unifying Trust Point (Unifying Domain) ModelThe model in whichIn the Unifying Trust Point Model, a PKIdomainDomain is created by establishing a joint superior CA that issues unilateralcross-certificatescross- certificates to each PKIdomain,Domain, as shown in Figure 9. Such a joint superior CA is defined asunifyingUnifying CA, and theprincipalPrincipal CAs in each PKIdomainDomain have the hierarchical CA relationship with thatunifyingUnifying CA. In this model, any relying party from any of the PKIdomainsDomains MUST specify theunifyingUnifying CA as its trust anchor 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 theprincipalPrincipal CA from the old PKIdomainDomain as its trust anchor. 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 parties. The unilateral cross-certificate issued by theunifyingUnifying CA to theprincipalPrincipal CAs in each PKIdomainDomain may include any policy mapping. Shimaoka, et al. ExpiresAugust 17, 2007February 16, 2008 [Page17]18] Internet-Draft multi-domain PKI interoperabilityFebruaryAugust 2007 Cross-certified Cross-certified Unifying CA Unifing 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 9: Unifying Trust Point (Unifying Domain) Model 3.3.2. Independent Trust Point Models Inthis model,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 The model in which each PKIdomainDomain trusts each other by issuing cross-certificate directly between eachprincipalPrincipal CA, as shown in Figure 10. This model may be used for shortening a certification path, or establishing a trust relationship expeditiously. Shimaoka, et al. ExpiresAugust 17, 2007February 16, 2008 [Page18]19] Internet-Draft multi-domain PKI interoperabilityFebruaryAugust 2007 Considerations: A PKIdomainDomain in this model SHOULD consider that the other PKIdomainDomain may cross-certify with any more 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 the constraints will be recognized and followed. +---------------++----------------------++------------------------+ | PKI | cross-certified | PKI | | domain 1 |cross-certifiedeach other | domain 2 | | +-----+| each other |--------------------> +-----+ ----+ | | | PCA|<--------------------->|| | | | PCA|<--+| |+-----+| | +-----+ <-------------------- +-----+ <-+ | | | | | | ^ | v | | | | | | +----+ | | | | | | | CA |---+ | | | | | | +----+ | | | v | | v ^ | | | | +----+ | | +----+ | | | | | +---| CA | | | | CA|---+|--+ | | | | | +----+ | | +----+ | | | | | | | | | | | | | v v | | v v v | | +----+ +----+ | | +----+ +----+ +----+ | | | EE | | EE | | | | EE | | EE | | EE | | | +----+ +----+ | | +----+ +----+ +----+ | +---------------++----------------------++------------------------+ Figure 10: Direct Cross-Certification Model 3.3.2.2. Bridge Model The model in which every PKIdomainDomain trusts each other through a Bridge CA by Cross-Certification, as shown in Figure 11. In this model, the trust relationship is not established between a subscriber domain and a relying party domain directly, but established from theprincipalPrincipal CA of relying party's PKIdomainDomain via Bridge CA. This model is useful in reducing the number of cross-certifications required for a PKIdomainDomain to interoperate with other PKIdomains.Domains. Requirements for Bridge model: o Bridge CA MUST NOT be used as the trust anchor in any PKIdomain.Domain. Shimaoka, et al. ExpiresAugust 17, 2007February 16, 2008 [Page19]20] Internet-Draft multi-domain PKI interoperabilityFebruaryAugust 2007 o Bridge CA SHOULD issue cross-certificates with other PKIdomainsDomains mutually or MAY issue cross certificates unilaterally. o Bridge CA MUST NOT issue EE certificates except when it is necessary for the CA's operation. o Bridge CA MUST use its own domain policy OID, not other PKIdomainDomain policy OID, for the policy mapping. oThe domain policy of Bridge CA MUST be a subset of the domain policy which PKI domain maps to Bridge CA. o The domain policy of Bridge CA MUST be a superset of the domain policy which is mapped by Bridge CA. oBridge CA SHOULD be a neutral position to all PKIdomainsDomains which trust through the Bridge CA. For example in Figure 11, in the case that a relying party who trusts the PCA of PKIdomainDomain 1 as its trust anchor builds the certification path to a subscriber in PKIdomainDomain 3: Cross-Certificate from PKIdomainDomain 1 to Bridge CA: issuerDomainPolicy := domain policy OID of PKIdomainDomain 1 subjectDomainPolicy := domain policy OID of Bridge CA Cross-Certificate from Bridge CA to PKIdomainDomain 3: issuerDomainPolicy := domain policy OID of Bridge CA subjectDomainPolicy := domain policy OID of PKIdomainDomain 3 o Cross-Certificates issued by Bridge CA and Cross-Certificate issued to Bridge CA SHOULD include the requireExplicitPolicy with a value that is greater than zero in the policyConstraints extension because a relying party MAY not set the initial- explicit-policy to TRUE. oCross-certificate issued by Bridge CA SHOULD NOT include any constraints to keep its neutral position, excepting above requirement. oPKIdomainsDomains cross-certified with Bridge CA SHOULD NOT cross- certify directly to other PKIdomainsDomains cross-certified with the same Bridge CA.Shimaoka, et al. Expires August 17, 2007 [Page 20] Internet-Draft multi-domain PKI interoperability February 2007o Bridge CA SHOULD clarify the method for the policy mapping of cross-certification to keep its transparency. Considerations: The Bridge CA SHOULD be operated by an independent third party agreed upon by the PKIdomainsDomains or a consortium consisting of representation from the PKIdomainDomain members. The Bridge CA SHOULD do policy mapping in a well documented and agreed upon manner with all PKIdomains.Domains. For using the name constraints, the Bridge CA SHOULD pay attention to preventing a conflict of each name space of the cross-certified PKIdomains.Domains. The PKIdomainsDomains that perform cross-certification with the Bridge CA SHOULD Shimaoka, et al. Expires February 16, 2008 [Page 21] Internet-Draft multi-domain PKI interoperability August 2007 confirm the following: * Does the Bridge CA perform the policy mapping via its own domain policy 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. Expires August 17, 2007 [Page 21] Internet-Draft multi-domain PKI interoperability February 2007cross-certified cross-certified PKIdomainDomain 1 with BCA+-----------+PKIdomainDomain 3 with BCA+------->|+---------> +-----------+ -----+ | | Bridge CA|<------+| | | +-------- +-----------+ <--+ | | | ^ | | | | | cross-certified | | | | | | PKIdomainDomain 2 | | | | | | with BCA | |+-----------|---+ +-----------|---+ +----|-----------------+| | +---------|-|---+ +-----------|-|-+ +--|-|-----------------+ | PKI | | | | PKI | | | |PKI| |domainPKI | |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 11: Bridge Model Shimaoka, et al. Expires February 16, 2008 [Page 22] Internet-Draft multi-domain PKI interoperability August 2007 3.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. ExpiresAugust 17, 2007February 16, 2008 [Page22]23] Internet-Draft multi-domain PKI interoperabilityFebruaryAugust 2007 4. Trust Models External to PKI Relationships ### TBD whole this section ### As opposed to PKI Domain trust relationships entered into by PKIs themselves, trust across multiple PKIs can be created by entities external to thePKIs. These trust relationships are developedPKIs throughthe uselocally configured lists of trustlists.anchors. Trust List: A set of one or more Trust Anchors used by a relying party to explicitly trust one or more PKIs.4.1. Trust List Considerations 4.1.1. Considerations for PKI PKIs that intend to support trust lists SHOULD publish their CPs soNote thattrust list owners and relying parties can determine if their use is supported under the CP. PKIs SHOULD also broadly publicize any revocation of a Trust Anchor CA or Principal CA through notice on their web page, press release, or other appropriate mechanisms. 4.1.2. Considerations forTrustList Owners Trust lists can beLists are often created without the knowledge ofany ofthe PKIs that are included in the list.As a result, the following considerations MUST be taken with regards to the use of trust lists: o4.1. Trust List Models 4.1.1. Local Trust List Model APKI cannot be held responsible for informing the owner of the trust list of any changes in the status of that PKI, especially with regards to the membership of the PKI in one or more PKI Domains. o The owner of a trust list MUST regularly check each PKI's repository to verify the status of the trust anchor and the status of membership in one or more PKI Domain membership. o The owner of a trust list MUST implement appropriate controls within the trust list to prevent inadvertent trust in the event that a PKI chooses to join one or more PKI Domains that are outside the Trust Anchors in the trust list. o The owner of a trust list SHOULD determine if the intended use of certificates issued by PKIs included in the trust list is in accordance with the CP of that PKI. In the event that a CP is not available to the owner of the trust list, the owner of the trust list SHOULD inform relying parties that use of these certificates is entirely at their own risk. Shimaoka, et al. Expires August 17, 2007 [Page 23] Internet-Draft multi-domain PKI interoperability February 2007 4.2. Trust List Models Trust lists mayTrust List can be createdlocallyand maintained by a single relying partyor may be operatedforthe purpose of supporting multiple relying parties. 4.2.1. Relying Partyits own use. Local Trust List: A Trust ListModel Any relying party MAY choose to trust certificates issued by any PKIinstalled and maintained byinstallingatrust anchorsingle relying party forthat PKI intoitslocal trust list.own use. Figure 12 illustrates atrust list within a relying party application.Local Trust List. +-------------------------------------------------------------+ | Relying Party | | +---------------------------------------------------------+ | | | Trust List | | | | +--------------+ +--------------+ +--------------+ | | | | | PKI 1 | | PKI 2 | ... | PKI n | | | | | | Trust Anchor | | Trust Anchor | | Trust Anchor | | | | | +--------------+ +--------------+ +--------------+ | | | +---------------------------------------------------------+ | +-------------------------------------------------------------+ Figure 12: Relying Party Local Trust List ModelInstallingCreating aPKI's trust anchor into a local trust listLocal Trust List is the simplest method for relying parties to trust EEcertificates issued by that PKI.certificates. Usinglocal trust listsLocal Trust Lists does not requirecross- certificationcross-certification between the PKI that issued the relying party's own certificate and the PKI that issued the EE's certificate. Nor does it require implementing mechanisms for processing complex certificationpaths.paths, as all CAs in a path can be included in the Local Trust List. As a result,the local trust list model isLocal Trust Lists are the most common model in use today.4.2.2.However, because Local TrustAuthority Model Instead ofLists are created Shimaoka, et al. Expires February 16, 2008 [Page 24] Internet-Draft multi-domain PKI interoperability August 2007 and managed independently by eachrelying party managing their own trust list,Relying Party, the use of Local Trust Lists can be difficult for anentity may chooseenterprise toestablishmanage. 4.1.2. Trust Authority Model Alternatively, atrust list thatTrust List can beaccessedcreated and maintained for use by multiple relyingparties,parties. In this case, the entity responsible for the Trust List is known as atrust authority.Trust Authority. Trust Authority: An entity that manages acentralized trust listTrust List for use by one or more relying parties.A Trust Authority may be operated by a PKI, or may be operated by an independent entity.Figure 13 illustrates a TrustAuthority.Authority and how it is used by Relying Parties. Note that the Trust Authority replaces thePKIs asPKI Trust Anchor(s) in thetrust anchorLocal Trust List for each participatingrelying party. Shimaoka, et al. Expires August 17, 2007 [Page 24] Internet-Draft multi-domain PKI interoperability February 2007Relying Party. +-------------------------------------------------------------+ | Trust Authority | | +---------------------------------------------------------+ | | | Trust List | | | | +--------------+ +--------------+ +--------------+ | | | | | PKI 1 | | PKI 2 | ... | PKI n | | | | | | Trust Anchor | | Trust Anchor | | Trust Anchor | | | | | +--------------+ +--------------+ +--------------+ | | | +---------------------------------------------------------+ | +-------------------------------------------------------------++-----------------+ +-----------------++---------------------+ +---------------------+ | Relying Party 1 | | Relying Party 2 | |+------------++-----------------+ | |+------------++-----------------+ | ... | | TrustListAuthority | | | | TrustList |Authority | |+------------+| +-----------------+ |+------------+| +-----------------++-----------------+| +---------------------+ +---------------------+ Figure 13: Trust Authority ModelBecauseA Trust Authority may be operated by atrust authority isPKI, acentralized entitycollection of relying parties thatwill be used by multipleshare a common set of users, an enterprise on behalf of all of its relying parties,the following additional considerations apply: o Trust authorities SHOULD register with theor an independent entity. Although PKIsthey include in theirgenerally establish trustlists so that they can be informed of changes in CPs, changes inrelationships through cross-certificates, a PKIDomain membership, or revocation ofmay choose to provide atrust anchor CA orTrust Authority to support relying parties that do not support processing of certification paths. An 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 Trust Authority to implement enterprise policies and direct all Relying Parties within the enterprise to use its Trust Authority. Shimaoka, et al. Expires February 16, 2008 [Page 25] Internet-Draft multi-domain PKI interoperability August 2007 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 CP 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 a Trust Anchor 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 a Trust Anchor or Principal CA certificate installed in a Trust List should be removed. A PKI SHOULD publish 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 CP of each PKI to determine that the PKI is operated to an acceptable level of assurance. o Reviewing the CP 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 the Relying Party's own risk. o Periodically reviewing information published by the PKI to its repository, including CP updates or notice of CA revocation or compromise. A PKI can choose to join or leave PKI Domains in accordance with its CP. If the Relying Party or Trust Authority does not wish to inherit trust in other members of these PKI Domains, it is the responsibility of the Relying Party or Trust Authority to inhibit policy mapping. Shimaoka, et al. Expires February 16, 2008 [Page 26] Internet-Draft multi-domain PKI interoperability August 2007 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 theprincipal CA.Trust Authority. o The process by which Trustauthorities SHOULD provide information to their relying parties for how and when trust anchorsAnchors are added or removed fromits trust list.the Trust List. oSince trust authorities replace CA certificates asAny warranties provided by thetrust anchorTrust Authority fortheir relying parties,reliance on EE certificates. These warranties may be those provided by thetrust authority MUSTPKIs themselves or may beoperated to an acceptable leveladditional warranties provided by the Trust Authority. o Information regarding how the Trust Authority protects the integrity ofassurance foritsrelying parties. Unless the trust authority is itself operated byTrust List. o Information regarding how Relying Parties interact with therelying parties, it MUST provideTrust Authority to obtain information as toits relying parties regarding its own operations.whether an EE certificate is trusted. Shimaoka, et al. ExpiresAugust 17, 2007February 16, 2008 [Page25]27] Internet-Draft multi-domain PKI interoperabilityFebruaryAugust 2007 5. Abbreviations CA: Certification Authority CP: Certificate Policy EE: End Entity OID: Object Identifier PCA: Principal Certification Authority PKI: Public Key Infrastructure Shimaoka, et al. ExpiresAugust 17, 2007February 16, 2008 [Page26]28] Internet-Draft multi-domain PKI interoperabilityFebruaryAugust 2007 6. Security Considerations This section highlights security considerations related to establishing PKIdomains.Domains. Because this RFC defines terminology and not protocols or technology for implementing the terminology,detailedtechnology-specific security considerations are not applicable. However, a high level discussion of applicable security considerations is warranted. 6.1. PKI Domain Models For all PKIdomainDomain models that described in section 3.3 created through the issuance of cross certificates, standard threats including message insertion, modification, and man-in-the-middle are not 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 inadvertent trust, which can occur if a single PKI is a member of multiple PKIdomains.Domains. See Section 3.2.3 for a discussion of inadvertent trust 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 thedomain.domain or choosing to restrict or deny trust in the new member PKI. 6.2. Trust List Models In these models also, many standard attacks are not applicable since certificates are digitally signed. Additional security considerations apply when trust is created through trustlists. In these models, a relying party or a trust anchor creates a trust domain by directly trusting one or more PKIs. Since certificates are digitally signed, many standard attacks are not applicable.list. A variation of the modification attack is possible in trust list models. If an attacker is able to add or remove CAs from the relying party or trust authority trust list, the attacker can affect which certificates will or will not beauthenticated.accepted. To prevent this attack, access to trust lists MUST be adequately protected against Shimaoka, et al. ExpiresAugust 17, 2007February 16, 2008 [Page27]29] Internet-Draft multi-domain PKI interoperabilityFebruaryAugust 2007 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 a trust list, or denial of service if a CA is removed from a trust list. For trust authority models, a denial of service attack is also possible if the application cannot obtain timely information from the trust anchor. Applications SHOULD specify service level agreements with trust authority. In addition, applications MAY choose to locally cache the list of CAs maintained by the trust authority as a backup in theevenevent that the trustanchoranchor's repository (e.g., LDAP directory) is not available. Shimaoka, et al. ExpiresAugust 17, 2007February 16, 2008 [Page28]30] Internet-Draft multi-domain PKI interoperabilityFebruaryAugust 2007 7. IANA Considerations This document has no actions for IANA. Shimaoka, et al. ExpiresAugust 17, 2007February 16, 2008 [Page29]31] Internet-Draft multi-domain PKI interoperabilityFebruaryAugust 2007 8. References 8.1. Normative References [1] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [3] International International Telephone and Telegraph Consultative Committee, "Information Technology - Open Systems Interconnection - The Directory: Authentication Framework", CCITT Recommendation X.509, March 2000. [4] 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. [5] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000. [6] Housley, R. and W. Polk, "Planning for PKI", August 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", July 2002. [10] NPO Japan Network Security 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", July 2003. [12] Japan PKI Forum, Korea PKI Forum, and PKI Forum Singapore, "Achieving PKI Interoperability", April 2002. Shimaoka, et al. ExpiresAugust 17, 2007February 16, 2008 [Page30]32] Internet-Draft multi-domain PKI interoperabilityFebruaryAugust 2007 [13] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. Nicholas, "Internet X.509 Public Key Infrastructure: Certification Path Building", RFC 4158, September 2005. [14] "US Government PKI Cross-Certification Criteria and Methodology", January 2006. Shimaoka, et al. ExpiresAugust 17, 2007February 16, 2008 [Page31]33] Internet-Draft multi-domain PKI interoperabilityFebruaryAugust 2007 Authors' Addresses Masaki Shimaoka SECOM Co., Ltd. Intelligent System Laboratory SECOM SC Center, 8-10-16 Shimorenjaku Mitaka, Tokyo 181-8528 JP Email: shimaoka@secom.ne.jp, m-shimaoka@secom.co.jp Nelson Hastings National Institute of Standard and Technology 100 Bureau Drive, Stop 8930 Gaithersburg, MD 20899-8930 US Email: nelson.hastings@nist.gov Rebecca Nielsen Booz Allen Hamilton 8283 Greensboro Drive McLean, VA 22102 US Email: nielsen_rebecca@bah.com Shimaoka, et al. ExpiresAugust 17, 2007February 16, 2008 [Page32]34] Internet-Draft multi-domain PKI interoperabilityFebruaryAugust 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Shimaoka, et al. ExpiresAugust 17, 2007February 16, 2008 [Page33]35] ----