view Side-By-Side changes
Network Working Group M. Shimaoka Internet-Draft SECOM Intended status: Informational N. Hastings Expires:JanuaryJuly 10, 2007N. HastingsNIST R. Nielsen Booz Allen HamiltonJuly 9, 2006January 6, 2007 Memorandum for multi-domain Public Key Infrastructure Interoperabilitydraft-shimaoka-multidomain-pki-07draft-shimaoka-multidomain-pki-08 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 onJanuaryJuly 10, 2007. Copyright Notice Copyright (C) The Internet Society(2006). Abstract This memo is intended to describe the foundation necessary to the deployment of a multi-domain PKI. The scope of this memo is to establish and clarify the trust relationships and interoperability between multiple PKI domains. A Certification Authority (CA) is able to extend a certification path by establishing trust with other CAs.(2007). Shimaoka, et al. ExpiresJanuaryJuly 10, 2007 [Page 1] Internet-Draft multi-domain PKI interoperabilityJuly 2006 Both single-January 2007 Abstract This document desires to establish a standard terminology and actual language for interoperability of multi-domainPKIsPKI that consists of several PKI domains which areestablished by such trustoperated under each distinct policy. This document describes the relationships betweenCAs. TypicalCertification Authorities (CAs), the definition andprimitive PKI model is a single-domainrequirements for PKIthat shares the same Certificate Policy (CP) at a specified trust level. Adomain, and typical models of multi-domainPKI is established by combining more than one single-domainPKI.AShimaoka, et al. Expires July 10, 2007 [Page 2] Internet-Draft multi-domain PKIcan be categorized as either a multi-trust point model based on the trust list model; or single-trust point model based on the Cross- Certification model.interoperability January 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .34 1.1. Objective . . . . . . . . . . . . . . . . . . . . . . . .34 1.2. Document Outline . . . . . . . . . . . . . . . . . . . . .34 1.3. Requirements and Assumptions . . . . . . . . . . . . . . .34 2.Terminology . . . . . . . . . . . . .Public Key Infrastructure (PKI) Basics . . . . . . . . . . . .45 2.1. Basic Concepts . . . . . . . . . . . . . . . . . . . . . .45 2.2.Certification AuthorityRelationships Between Certification Authorities . . . . . 5 2.2.1. Hierarchical CA Relationships . . . . .5 2.2.1. Hierarchical. . . . . . . 6 2.2.2. Peer-to-peer CA Relationships . . . . . . . . . . . . 7 2.3. Public Key Infrastructure (PKI) Architectures . .6 2.2.2. Peer. . . . 8 2.3.1. Single CA Architecture . . . . . . . . . . . . . . . . 9 2.3.2. Multiple CA Architectures . . . . .7 2.3. Public Key Infrastructure (PKI). . . . . . . . . 9 3. PKI Domain . . . .7 2.3.1. Simple PKI. . . . . . . . . . . . . . . . . . . . . .8 2.3.2. Hierarchical13 3.1. PKI domain Properties . . . . . . . . . . . . . . . . . .. 9 2.3.3. Mesh13 3.2. Requirements for Establishing and Participating in PKI domains . . . . . . . . . . . . . . . . . . . . . . .10 2.3.4. Hybrid PKI. . 13 3.2.1. PKI Requirements . . . . . . . . . . . . . . . . . . . 14 3.2.2. PKI Domain Documentation .12 3. Trust Lists. . . . . . . . . . . . . . 14 3.2.3. PKI Domain Membership Notification . . . . . . . . . . 15 3.2.4. Considerations for PKIs and PKI Domains with Multiple Policies .14 3.1. Relying Party Trust List Model. . . . . . . . . . . . . .15 3.2.. . . 16 3.3. PKI domain Models . . . . . . . . . . . . . . . . . . . . 16 3.3.1. Unifying TrustAuthorityPoint (Unifying Domain) Model . . . . . 16 3.3.2. Independent Trust Point Models . . . . . . . . . . . . 17 3.4. Operational Considerations .16. . . . . . . . . . . . . . . 20 4. Trust Models External to PKIDomainRelationships . . . . . . . . . . 21 4.1. Trust List Considerations . . . . . . . . . . . . . . . .18 4.1. Requirements21 4.1.1. Considerations for PKIdomain. . . . . . . . . . . . . . .18. 21 4.1.2. Considerations for Trust List Owners . . . . . . . . . 21 4.2.Risk Analysis of non-interoperable PKI domainsTrust List Models . . . . . . . . . . . . . . .18 4.3.. . . . . 22 4.2.1. Relying Party Local TrustRelationship Disclosure Requirements for multi-domain PKIsList Model . . . . . . . . . 22 4.2.2. Trust Authority Model . . . . . . . . . . . . . . . .1822 5. Terminologies and Abbreviations . . . . . . . . . . . . . . . 24 5.1. Terminologies . . . . . . . . . . . . . . . . . . . . . . 24 5.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . .1924 6. Security Considerations . . . . . . . . . . . . . . . . . . .2026 6.1. PKI Domain Models . . . . . . . . . . . . . . . . . . . . 26 6.2. Trust List Models . . . . . . . . . . . . . . . . . . . . 26 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . .2128 8. References . . . . . . . . . . . . . . . . . . . . . . . . . .2229 8.1. Normative References . . . . . . . . . . . . . . . . . . .2229 8.2. Informative References . . . . . . . . . . . . . . . . . .2229 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .2431 Intellectual Property and Copyright Statements . . . . . . . . . .2532 Shimaoka, et al. ExpiresJanuaryJuly 10, 2007 [Page2]3] Internet-Draft multi-domain PKI interoperabilityJuly 2006January 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 Section 2(Section 2)describesbasic PKI terminology necessary to consider trust relationships.the relevance between each entity, and the relationship between especially CAs, for understanding of multi- domain PKI. Section 3(Section 3) focuses on trust relationships established by relying parties. Section 4 (Section 4) defines a PKI domaindescribes the definitions and requirements for PKIinteroperation within a PKI domain. Section 5 defines requirements for interoperation acrossdomain, and also describes the typical models of multi-domain PKI. Although it is not focus on PKIdomains. Finally,domain because they depend on not CA-CA trust relationship but RP-CA relationship, Section6 provides a glossary summarizing4 considers theterms described inTrust List models. Section 5 shows theremainder ofterminologies and thedocument.abbreviations. 1.3. Requirements and Assumptions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119[3].[4]. Shimaoka, et al. ExpiresJanuaryJuly 10, 2007 [Page3]4] Internet-Draft multi-domain PKI interoperabilityJuly 2006January 2007 2.TerminologyPublic Key Infrastructure (PKI) Basics 2.1. Basic Concepts The following terms defining basic constructs are used throughout this document. Where possible, definitions found in RFC 2828[2][3] have been used. Additional terms from RFC 2828[2][3] and new terms that define relationships between these constructs are introduced and defined in later sections.A full list of terms can be found in Section 6 [8.1]. CertificateCertificate: 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 definition of public-key certificate] CertificatePolicyPolicy: "A named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements." (X.509)[5][6] Certification Authority(CA)(CA): An entity that issues certificates (especially X.509 certificates) and vouches for the binding between the data items in a certificate. (RFC 2828)[2][3] EndEntityEntity: 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)[2][3] RelyingPartyParty: A system entity that depends on the validity of information (such as another entity's public key value) provided by a certificate. [from the RFC 2828 definition of certificate user] TrustAnchorAnchor: A certificate upon which a relying party relies as being valid without the need for validation testing. [modified from the RFC 2828 definition of trusted certificate]Shimaoka, et al. Expires January 10, 2007 [Page 4] Internet-Draft multi-domain PKI interoperability July 20062.2.Certification AuthorityRelationships Between Certification Authorities Certification Authorities (CA) establish trust relationships by issuing certificates to other CAs. CA relationships can be either hierarchical orpeer.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. Expires July 10, 2007 [Page 5] Internet-Draft multi-domain PKI interoperability January 2007 Self-SignedCertificateCertificate: 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)[2] Cross-Certificate[3] Cross-Certificate: A certificate issued from one CA to another CA. Subordinate CACertificateCertificate: A certificate issued from one CA to another CA which becomes that CA's own signing certificate. Because the CA that is the subject of the subordinate CA certificate MUST not have a self-signed certificate and uses the subordinate CA certificate as its own signing certificate, the issuing CA authorizes the existence of the subordinate CA. [modified from the RFC 2828 definition of subordinate certification authority] PeerCross-CertificateCross-Certificate: A certificate issued from one CA to another CA where the CA that is the subject of the cross-certificatedoes not use the cross- certificate ashas issued its ownsigningself-signed certificate.Cross-CertificationCross-Certification: The act or process of issuing across-certificate.cross- certificate. Note that this definition is not the same as the definition in RFC 2828[2],[3], which only addresses bilateralcross-certification.cross- certification. UnilateralCross-CertificationCross-Certification: The act or process by which one CA certifies the public key of another CA by issuing a peercross-certificatecross- certificate to that other CA. [modified from the RFC 2828 definition of cross-certification] BilateralCross-Certification Shimaoka, et al. Expires January 10, 2007 [Page 5] Internet-Draft multi-domain PKI interoperability July 2006Cross-Certification: The act or process by which two CAs each certify a public key of the other by each CA issuing a peer cross-certificate to the other CA. [modified from the RFC 2828 definition of cross-certification] 2.2.1. Hierarchical CA Relationships In a hierarchical relationship, as shown in Figurexxx,1, one CA assumes a parent relationship to the other CA. Shimaoka, et al. Expires July 10, 2007 [Page 6] Internet-Draft multi-domain PKI interoperability January 2007 +----+ | CA | +----+ | | | v +----+ | CA | +----+ Figure 1: HierarchicalTrustCA Relationship 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. RootCACA: A CA that is at the top of a hierarchy, and itselfdoesSHOULD not issue certificates to end entities (except those required for its own operation) but issues subordinate CA certificates to one or more CAs.UnifyingA 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 itselfdoesSHOULD not issue certificates to end entities (except those required for its own operation) but establishes unilateralcross-certificationcross- certification with other CAs.Shimaoka, et al. Expires January 10, 2007 [Page 6] Internet-Draft multi-domain PKI interoperability July 2006A unifying CA MUST permit CAs to which it issues peer cross-certificates to have self-signed certificates. 2.2.2.PeerPeer-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. Unilateral Bilateral Cross-Certification Cross-Certification +----+ +----+ +----+ +----+ | CA | ---> | CA | | CA | <--> | CA | +----+ +----+ +----+ +----+Figure 2: Peer Trust RelationshipShimaoka, et al. Expires July 10, 2007 [Page 7] Internet-Draft multi-domain PKI interoperability January 2007 Figure 2: Peer-to-peer CA Relationships In 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 a bridge CA, as shown in Figure 3. BridgeCACA: 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[2][3] 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 anShimaoka, et al. Expires January 10, 2007 [Page 7] Internet-Draft multi-domain PKI interoperability July 2006application 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. Public Key Infrastructure(PKI)(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 a single Certificate Policy, and are either operated by a single organization or under the direction of a single organization. Shimaoka, et al. Expires July 10, 2007 [Page 8] Internet-Draft multi-domain PKI interoperability January 2007 In addition, a PKI that intends to enter into trust relationships with 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. PrincipalCACA: A CA whichhasMUST have a self-signedcertificate andcertificate, is designated as the CA that will issue peer cross-certificates to principal CAs in otherPKIsPKIs, and MAY be the subject of peercross-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. CertificationPathPath: An ordered sequence of certificates where theissuersubject of each certificate in the path is thesubjectissuer of the next certificate in the path. A certification path begins withan end entitya trust anchor certificate and ends witha trust anchoran end entity certificate. 2.3.1.Simple PKI DefinitionSingle 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.Shimaoka, et al. Expires January 10, 2007 [Page 8] Internet-Draft multi-domain PKI interoperability July 2006+----+ | CA | +----+ |+------+------++------+-----+ v v v +----+ +----+ +----+ | EE | | EE | | EE | +----+ +----+ +----+ Figure 4: Simple PKIModelArchitecture TrustAnchorAnchor: The trust anchor MUST be the self-signed certificate of the CA. PrincipalCACA: The principal CA MUST be the CA. 2.3.2. Multiple CA Architectures Shimaoka, et al. Expires July 10, 2007 [Page 9] Internet-Draft multi-domain PKI interoperability January 2007 2.3.2.1. Hierarchical PKIDefinitionArchitecture Definition: A hierarchical PKI consists of a single root CA and one or more subordinate CAs that issue certificates to EEs. The root CA MUST have a self-signed certificate and all subordinate CAs MUST have subordinate CA certificates, as shown in Figure 5.Shimaoka, et al. Expires January 10, 2007 [Page 9] Internet-Draft multi-domain PKI interoperability July 2006Trust Anchor: The trust anchor MUST be root CA. Principal CA: The principal 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 PKIModel Trust Anchor The trust anchor MUST be root CA. Principal CA The principal CA MUST be the root CA. 2.3.3.Architecture 2.3.2.2. Mesh PKIDefinitionArchitectures Definition: A mesh PKI consists of multiple self-signed CAs that issue certificates to EEs and issue peer cross-certificates to each other. A mesh PKI MAY be a full mesh, where all CAs issue peercross- certificatescross-certificates to all other CAs, as shown in Figure 6. A mesh PKI MAY be a partial mesh, where all CAs do not issue peercross- certificatescross-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. ExpiresJanuaryJuly 10, 2007 [Page 10] Internet-Draft multi-domain PKI interoperabilityJuly 2006January 2007 +-----+ +--------> | CA1 | <------+ | +-----+ | | | | | +---+--+ | | v v | | +----+ +----+ | | | EE | | EE | | | +----+ +----+ | v v +-----+ +-----+ | CA2 | <---------------> | CA3 | +-----+ +-----+ | | +---+--+ +------+------+ v v v v v +----+ +----+ +----+ +----+ +----+ | EE | | EE | | EE | | EE | | EE | +----+ +----+ +----+ +----+ +----+ Figure 6: Full Mesh PKImodelArchitecture +-----+ +-------> | CA1 | --------+ | +-----+ | | | | | +---+--+ | | v v | | +----+ +----+ | | | EE | | EE | | | +----+ +----+ | v v +-----+ +-----+ | CA2 | | CA3 | +-----+ +-----+ | | +---+--+ +------+------+ v v v v v +----+ +----+ +----+ +----+ +----+ | EE | | EE | | EE | | EE | | EE | +----+ +----+ +----+ +----+ +----+ Figure 7: Partial Mesh PKImodel Trust AnchorArchitecture Shimaoka, et al. ExpiresJanuaryJuly 10, 2007 [Page 11] Internet-Draft multi-domain PKI interoperabilityJuly 2006January 2007 Trust Anchor: The trust anchor for a relying party who is issued a certificate from a CA in the mesh PKI SHOULD be the CA who issued the certificate to the relying party. The trust anchor forthea relying party 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,inFigurexxx7 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. PrincipalCACA: The principal CA MAY be any CA within the PKI. However, the mesh PKI MUST have only one principal CA, and atrustcertification pathMUSTSHOULD exist from the principal CA toevery CAall other CAs within the PKI.ConsiderationsConsiderations: 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.2.3.4.2.3.2.3. Hybrid PKIDefinitionArchitectures Definition: A hybrid PKI is a PKI that uses a combination of peercross- certificatescross-certificates and subordinate CA certificates to define the CAs that are a part of the PKI. TrustAnchorAnchor: The trust anchor for arelying party who is issued a certificate from ahybrid PKI MAY be any self- signed CA in themesh PKI SHOULD bePKI. However, because of theCA who issuedpotential complexity of a hybrid PKI, thecertificatePKI SHOULD provide guidance totherelyingparty. The trust anchor for the relying party who is not issued a certificate fromparties regarding themesh PKI MAY be any self-signed CA inselection of thePKI.trust anchor. PrincipalCA Shimaoka, et al. Expires January 10, 2007 [Page 12] Internet-Draft multi-domain PKI interoperability July 2006CA: The principal CA MAY be any CA within the PKI that has aself- signedself-signed certificate. However, the hybrid PKI MUST have only one principal CA, and atrustcertification path MUST exist from the principal CA to every CA within the PKI.ConsiderationsConsiderations: 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. ExpiresJanuaryJuly 10, 2007 [Page13]12] Internet-Draft multi-domain PKI interoperabilityJuly 2006January 2007 3.Trust Lists Relying parties MAYPKI Domain Two or more PKIs may choose to enter into trustmultiple PKIs throughrelationships with each other. For these relationships, each PKI retains its own Certificate Policy and its own Principal CA. Prior to establishing theusetrust relationship, each PKI determines the level of trustlists. Trust lists can be managed by an individual relying party orof each external PKI by reviewing external PKI CP(s) and any other PKI governance documentation through atrust authority that is shared by multiple relying parties.process known as policy mapping. TrustListrelationships 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: Alistset ofonetwo or more PKIs that have chosen to enter into trustanchors usedrelationships with each other through the use of cross- certificates. Policy Mapping: A process by which members of arelying partyPKI Domain evaluate the CPs and other governance documentation of other potential PKI Domain members toexplicitlydetermine the level of trusta PKI. Trust Authority An entitythatmanageseach PKI in the PKI Domain places on certificates issued by each other PKI in the PKI Domain. 3.1. PKI domain Properties o A PKI Domain MAY operate acentralized trust list for oneBridge CA ormore relying parties. Figure 8 shows an example ofatrust listUnifying CA thatcontains a simple PKI, a hierarchical PKI, and a full mesh PKI. Shimaoka, et al. Expires Januarydefines 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 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. 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 PKI Domains to prevent inadvertent trust. Shimaoka, et al. Expires July 10, 2007 [Page14]13] Internet-Draft multi-domain PKI interoperabilityJuly 2006 Trust List +--------------------------------------------------------------+ | Trust Anchors | | | | +---------------+ +---------------+ +----------------------+ | | |January 2007 3.2.1. PKI1 | |Requirements In order for a PKI2 | |to participate in one or more PKI3 | | | | | | | | | | | | +----+ | | +----+ | | +----+ | | | | | CA | | | | CA | | | |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 [2] format. o One or more Policy OIDs 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 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. 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 of requirements. o Unless the PKI Domain has a predetermined membership, describe the requirements and methods for joining the PKI Domain, such as FPKIMETHOD [15]. Examples of governance documents that PKI Domains MAY choose to use Shimaoka, et al. Expires July 10, 2007 [Page 14] Internet-Draft multi-domain PKI interoperability January 2007 are: o Statement of intent between two or more parties o Memorandum of Agreement between two or more parties o Certificate Policy 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 Domains it's member PKIs participate in. Figure 8 illustrates this concept. +-----------------------------+ | PKI DOMAIN 2 | +----------------------------+ | | | | | | +------+ | +------+ | +------+ | | | PKI1 | <-----> | PKI2 | <-----> | PKI3 | | | +------+ | +------+ | +------+ | | | | | | +-----------------------------+ | PKI DOMAIN 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 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 PKI Domain 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 Shimaoka, et al. Expires July 10, 2007 [Page 15] Internet-Draft multi-domain PKI interoperability January 2007 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 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, 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. PKI domain Models Two or more PKI domains may choose to enter into trust relationships with each other. In that case, they may form a larger PKI domain by having their common trust anchor or by bridging their principal CAs. 3.3.1. Unifying Trust Point (Unifying Domain) Model The model in which multiple PKI domains have a joint superior CA that issues unilateral cross-certificates to each PKI domain, as shown in Figure 9. Such a joint superior CA is defined as unifying CA, and the principal CAs in each PKI domain have the hierarchical CA relationship with that unifying CA. This model may be used for merging multiple PKI domains to single PKI domain with less change to Shimaoka, et al. Expires July 10, 2007 [Page 16] Internet-Draft multi-domain PKI interoperability January 2007 existing PKI domains, or be used for assuming multiple PKI domains as one PKI domain to a relying party. As against the hierarchical PKI architecture designed on the assumption that operates under a single certificate policy, the unilateral cross-certificate issued by unifying CA to the principal CAs in each PKI domain may include any policy mapping. Cross-certified Cross-certified Unifying CA Unifing CA to PKI domain 1 +--------------+ to PKI domain 3 +---------| Unifying CA |---+ | +--------------+ | | | | | Cross-certified| | | Unifying CA | | | to PKI domain 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 Shimaoka, et al. Expires July 10, 2007 [Page 17] Internet-Draft multi-domain PKI interoperability January 2007 3.3.2.1. Direct Cross-Certification Model ### TBD ### 3.3.2.2. Bridge Model The model in which every PKI domain trusts each other through a Bridge CA by Cross-Certification, as shown in Figure 10. In this model, the trust relationship is not established between a subscriber domain and a relying party domain directly, but established from the principal CA of relying party's PKI domain via Bridge CA. This model is useful in reducing the number of cross-certifications required for a PKI domain to interoperate with other PKI domains. Requirements for Bridge model: o Bridge CA MUST NOT be used as the trust anchor in any PKI domain. o Bridge CA SHOULD issue cross-certificates with other PKI domains 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 in the policy mapping between a prior PKI domain and a posterior PKI domain. o The domain policy of Bridge CA MUST be a subset of the prior PKI domain policy that is mapped. o The domain policy of Bridge CA MUST be a superset of the posterior PKI domain policy that is mapped. o Bridge CA SHOULD be a neutral position to all PKI domains which trust through the Bridge CA, such as the following policy mapping: Cross-Certificate from prior PKI domain to Bridge CA: issuerDomainPolicy := Prior PKI domain policy subjectDomainPolicy := Bridge CA domain policy Cross-Certificate from Bridge CA to posterior PKI domain: issuerDomainPolicy := Bridge CA domain policy subjectDomainPolicy := Posterior PKI domain policy Shimaoka, et al. Expires July 10, 2007 [Page 18] Internet-Draft multi-domain PKI interoperability January 2007 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. o Cross-certificate issued by Bridge CA SHOULD NOT include any constraints to keep its neutral position, excepting above requirement. o PKI domains cross-certified with Bridge CA SHOULD NOT cross- certify directly to other PKI domains cross-certified with the same Bridge CA. o 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 such as a neutral trusted third party agreed upon by the PKI domains or a consortium consisting of the PKI domains. The Bridge CA SHOULD do policy mapping in a well documented and agreed upon manner with all PKI domains. For using the name constraints, the Bridge CA SHOULD pay attention to preventing a conflict of each name space of the cross-certified PKI domains. The PKI domains that perform cross-certification with the Bridge CA SHOULD confirm the following: * Does the Bridge CA perform the policy mapping via its own domain policy? * Does the Bridge CA clarify the method of policy mapping in the cross-certification? * Is the Bridge CA able to accept the domain policy that the prior PKI domain desires? + If the domain policy is mapped to one with a lower security level, the prior PKI domain SHOULD NOT accept it. Otherwise, the prior PKI domain MUST carefully consider the risks involved with accepting certificates with a lower security level. Shimaoka, et al. Expires July 10, 2007 [Page 19] Internet-Draft multi-domain PKI interoperability January 2007 cross-certified cross-certified PKI 1 with BCA +-----------+ PKI 3 with BCA +------->| Bridge CA |<------+ | +-----------+ | | ^ | | cross-certified | | | PKI 2 with BCA | | | | | +-----------|---+ +-----------|---+ +----|-----------------+ | PKI 1 | | | PKI 2 | | | | PKI 3 | | v | | v | | v | | +-----+ | | +-----+ | | +-----+ | | +---| PCA | | | | PCA | | | | PCA |<--+ | | | +-----+ | | +-----+ | | +-----+ | | | | | | | | | | ^ | | | | | | | | | | | v | | | | | | | | | | +----+ | | | | | | | | | | | CA |---+ | | | | | | | | | | +----+ | | | | | | | | | | | ^ | | | | | | | | v | | v | | | | | | | | | +----+ | | +----+ | | | | | | | | | +---| CA | | | | CA |---+ | | |<-----+ | | | | +----+ | | +----+ | | +----+ | | | | | | | | | | | ^ | | | +---------|-----------------|-------------|----------|---------+| | | | | | +----+ | | +----+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | v v | | v v | | v v v | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ | | | EE | | EE | | | | EE | | EE | | | | EE | | EE | | EE | | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ | +---------------+ +---------------+ +----------------------+ Figure 10: Multiple Trust Point (Bridge) Model 3.4. Operational Considerations Each PKI domain MAY use policy mapping for crossing different PKI domains. If a PKI domain wants to restrict a certification path, the PKI domain SHOULD NOT rely on the validation policy of the relying party, but SHOULD include the constraints in the cross-certificate explicitly. For example, when each PKI domain wants to affect the constraints to a certification path, it SHOULD set the requireExplicitPolicy to zero in the policyConstraints extension of any cross-certificates. A PKI domain that relies on the validation policy of the relying party about such constraints cannot guarantee the constraints will be recognized and followed. Shimaoka, et al. Expires July 10, 2007 [Page 20] Internet-Draft multi-domain PKI interoperability January 2007 4. Trust Models External to PKI Relationships As opposed to PKI Domain trust relationships entered into by PKIs themselves, trust across multiple PKIs can be created by entities external to the PKIs. These trust relationships are developed through the use of trust lists. 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 so that trust 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 for Trust List Owners Trust lists can be created without the knowledge of any of the PKIs that are included in the list. As a result, the following considerations MUST be taken with regards to the use of trust lists: o A PKI 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 July 10, 2007 [Page 21] Internet-Draft multi-domain PKI interoperability January 2007 4.2. Trust List Models Trust lists may be created locally by a single relying party or may be operated for the purpose of supporting multiple relying parties. 4.2.1. Relying Party Local Trust List Model Any relying party MAY choose to trust certificates issued by any PKI by installing a trust anchor for that PKI into its local trust list. Figure 11 illustrates a trust list within a relying party application. +-----------------------------------+ | RP | | +------------------------------+ | |+---+--+| TRUST LIST |v| | |v+------+ +------+ +------+ | |v v| |+----+| PKI1 | |+----+PKI2 | |+----+ +----+PKI3 | | |CA| | +------+ +------+ +------+ | | |CA+------------------------------+ | +-----------------------------------+ Figure 11: Relying Party Local Trust List Model Installing a PKI's trust anchor into a local trust list is the simplest method for relying parties to trust EE certificates issued by that PKI. 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's certificate. Nor does it require implementing mechanisms for processing complex certification paths. As a result, the local trust list model is the most common model in use today. 4.2.2. Trust Authority Model Instead of each relying party managing their own trust list, an entity may choose to establish a trust list that can be accessed by multiple relying parties, known as a trust authority. Trust Authority: An entity that manages a centralized trust list for one or more relying parties. A Trust Authority may be operated by a PKI, or may be operated by an independent entity. Figure 12 illustrates a Trust Authority. Note that the Trust Authority replaces the PKIs as the trust anchor for each participating relying party. Shimaoka, et al. Expires July 10, 2007 [Page 22] Internet-Draft multi-domain PKI interoperability January 2007 +-----------------------------------+ | Trust Authority | |EE+------------------------------+ | |EE| TRUST LIST | |+----+| | +------+ +------+ +------+ |+----+| |+----+ +----+| | PKI1 | | PKI2 | |^PKI3 | | | | |+---+--++------+ +------+ +------+ | |v| +------------------------------+ | +-----------------------------------+ +-----------------+ +-----------------+ |+---------------+RP1 |v v| RP2 |+----+| +------------+ | | +------------+ |+----+ +----+| | TRUST LIST |CA|<---+| | TRUST LIST | |EE| |EE+----+ | | | | +----+ | | |+----+ +----+| | TA | | | | | | TA |+---+--+|+---------------+|v v v| | +----++----+ +----+ || |EE| |EE+----+ | |EE| +------------+ | |+----+ +----+ +----++------------+ |+----------------------++-----------------+ +-----------------+ Figure8: Trust List 3.1. Relying Party12: TrustListAuthority ModelAny Relying Party MAY chooseBecause a trust authority is a centralized entity that will be used by multiple relying parties, the following additional considerations apply: o Trust authorities SHOULD register with the PKIs they include in their trust lists so that they can be informed of changes in CPs, changes in PKI Domain membership, or revocation of a trust anchor CA or the principal CA. o Trust authorities SHOULD provide information to their relying parties for how and when trust anchors are added or removed from its trust list. o Since trust authorities replace CA certificatesissuedas the trust anchor for their relying parties, the trust authority MUST be operated to an acceptable level of assurance for its relying parties. Unless the trust authority is itself operated by the relying parties, it MUST provide information to its relying parties regarding its own operations. Shimaoka, et al. Expires July 10, 2007 [Page 23] Internet-Draft multi-domain PKI interoperability January 2007 5. Terminologies and Abbreviations 5.1. Terminologies ### any comments? ### Domain Policy: Domain Policy is a common certificate policy (Object Identifier) that is shared in a PKI domain. Each CAs in the PKI domain MUST be operated under the domain policy at least. Each CAs is able to have another policy for itself in addition to the domain policy. In such a case, the CAs MUST comply with both policies. The policy OID of the domain policy is used to distinguish the PKI domain from another. Posterior PKI domain: This term is used to describe the relative trust relationship of adjoined PKI domains in the certification path and is used in combination with the term "prior PKIby installing a trust anchor for thatdomain". The next trusted PKIinto its local trust list. Installing a PKI'sdomain(s) in the certification path from the trust anchorinto a local trust listto the target certificate is called the posterior PKI domain. That is, the posterior PKI domain is trusted from thesimplest method for relying partiesprior PKI domain. Prior PKI domain: This term is used totrust EE certificates issued by that PKI. Using local trust lists does not require cross- certification betweendescribe the relative trust relationship of adjoined PKIthat issueddomains in therelying party's own certificatecertification path and is used in combination with the term "posterior PKI domain". The previous PKI domain in theother PKI. Nor does it require implementing mechanisms for processing complexcertificationpaths. As a result,path from thelocaltrustlist modelanchor to the target certificate is called themost common modelprior PKI domain. That is, the prior PKI domain trusts the posterior PKI domain. First prior PKI domain inuse today. Considerationsthe certification path is the PKI domain trusted directly by a relying party. 5.2. Abbreviations PKI: Public Key Infrastructure CA: Certification Authority EE: End Entity CRL: Certificate Revocation List ARL: Authority Revocation List PCA: Principal Certification Authority Shimaoka, et al. ExpiresJanuaryJuly 10, 2007 [Page15]24] Internet-Draft multi-domain PKI interoperabilityJuly 2006January 2007 RP: Relyingparties who choose to install trust anchors for PKIs that they are not also subscribers to do not necessarily create a relationship with the PKI. The relying party may be relying on certificates for a purpose that is not supported by theParty CP: Certificate Policy CPS: Certification Practice Statement DN: Distinguished Name Shimaoka, et al. Expires July 10, 2007 [Page 25] Internet-Draft multi-domain PKIas defined in the PKI's certificate policy. Also, the relying party willinteroperability January 2007 6. Security Considerations This section highlights security considerations related to establishing PKI domains. Because this RFC defines terminology and notbe directly informed ifprotocols or technology for implementing thetrust anchor's certificateterminology, detailed security considerations are not applicable. However, a high level discussion of applicable security considerations isrevoked,warranted. As certificates are generally considered public, confidentiality andso MUST check the PKI's repositoryeavesdropping are not applicable toverify the status ofthis RFC. Replay attacks are also not applicable as thetrust anchor. Relying parties MUST be awarecreation and maintenance ofthese considerations when makingadecision to use this model. PKIs that are directly installed into relying party trust lists MAY choose to cross-certify other PKIs. Relying parties MUST implement appropriate controls to ensure that they doPKI or a PKI domain does notinadvertently trust certificates from cross-certified PKIsinvolve actions thatthey did not intend to trust.can be replayed. 6.1. PKI Domain Models Forexample: Assume certification path X->Y->Z->EE(Z) exists. When cross- certificate X->Y includes pathLenConstraints=1, CA-Z cannot extendall PKI domain models created through thecertification path started from CA-X by moreissuance of crosscertificates. However, ifcertificates, 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 therelying party trust CA-Y directly,CA generating thecrosscross-certificate. Verifying that a given certificateconstraint in X->Y is ignored allowing CA-Z to extend the certification pathwas issued bymorea member of a PKI domain may be a time critical determination. If crosscertificates. Thus, relying party MUST recognizecertificates and revocation status information cannot be obtained in arisktimely manner, a denial oftrusting another CA directly. PKIs that intend to supportservice may be experienced by therelying party trust list model SHOULD publish their certificate policies so that relying partiesend entity. In situations where such verification is critical, caching of cross certificates and revocation status information may be warranted. An additional security consideration for PKI domains is inadvertent trust, which candetermineoccur iftheir usea single PKI issupported under the policy. PKIs SHOULD also broadly publicize any revocationa member of multiple PKI domains. See Section 3.2.3 for a discussion of inadvertent trustanchor CAand mechanisms to prevent it. Finally, members of PKI domains MUST participate in domain governance, or at a minimum, be informed anytime a PKI joins or leaves theprincipal CA (email, repository, press release, etc.). 3.2. Trust Authority Model A relying party MAY choose to trust certificates issued by PKIsdomain, so thatare themselves trusted by a trust authority. The trust authority MAY manage multiple trust listsdomain members can make appropriate decisions foruse by different relying parties. In this trust authority model,maintaining their own membership in the domain. 6.2. Trust List Models Additional security considerations apply when trustauthority acts as a third party broker between relying parties and trusted PKIs. There are currently no commercially available products that support theis created through trustauthority model. However, this model may be useful whenlists. In these models, anumber ofrelyingparties withinparty or acommunity of interest wish to centrally manage trusted PKIs and where the PKIs that issuetrust anchor creates a trust domain by directly trusting one or more PKIs. Since certificatesto EEs within this community of interest doare digitally signed, many standard attacks are notthemselves desire to cross-certify. Considerationsapplicable. Shimaoka, et al. ExpiresJanuaryJuly 10, 2007 [Page16]26] Internet-Draft multi-domain PKI interoperabilityJuly 2006 AllJanuary 2007 A variation of theconsiderations for the relying partymodification attack is possible in trust listmodel applymodels. If an attacker is able to add or remove CAs from the relying party or trust authoritymodel. Where possible,trustauthorities SHOULD register withlist, thePKIs they include in theirattacker can affect which certificates will or will not be authenticated. To prevent this attack, access to trust listsso that they canMUST beinformedadequately protected against unauthorized modification. This protection is especially important for trust anchors that are used by multiple applications, as it is a key vulnerability ofchangesthis model. This attack may result inPKI certificate policies or revocation ofunauthorized usage if atrust anchorCAor the principal CA. Relying parties usingis added to a trustauthorities are relying on the accuracylist, or denial oftheservice if a CA is removed from a trustlist as maintained by thelist. For trustauthority. Relying parties MAYanchor models, a denial of service attack is alsobe relying onpossible if thetrust authority to provide revocationapplication cannot obtain timely informationfor CA and EE certificates. As a result,from the trustauthoritiesanchor. Applications SHOULDprovide information to relying parties for how additionalspecify service level agreements with trustanchors are addedanchor providers. In addition, applications MAY choose to locally cache thetrustlistand what network and other security controls areof CAs maintained by the trustauthority to ensure reliability and accuracy ofanchor as a backup in theinformation provided byeven that the trustanchor. Shimaoka, et al. Expires January 10, 2007 [Page 17] Internet-Draft multi-domain PKI interoperability July 2006 4. PKI Domain 4.1. Requirements for PKI domain 4.2. Risk Analysis of non-interoperable PKI domains 4.3. Trust Relationship Disclosure Requirements for multi-domain PKIsanchor is not available. Shimaoka, et al. ExpiresJanuary 10, 2007 [Page 18] Internet-Draft multi-domain PKI interoperabilityJuly2006 5. Abbreviations PKI: Public Key Infrastructure CA: Certification Authority EE: End Entity CRL: Certificate Revocation List ARL: Authority Revocation List PCA: Principal Certification Authority RP: Relying Party CP: Certificate Policy CPS: Certification Practice Statement DN: Distinguished Name Shimaoka, et al. Expires January10, 2007 [Page19]27] Internet-Draft multi-domain PKI interoperabilityJuly 2006 6. Security Considerations TBD. Shimaoka, et al. ExpiresJanuary10,2007[Page 20] Internet-Draft multi-domain PKI interoperability July 20067. IANA Considerations This document has no actions for IANA. Shimaoka, et al. ExpiresJanuaryJuly 10, 2007 [Page21]28] Internet-Draft multi-domain PKI interoperabilityJuly 2006January 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] 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. [3] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000.[3][4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[4][5] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.[5][6] International International Telephone and Telegraph Consultative Committee, "Information Technology - Open Systems Interconnection - The Directory: Authentication Framework", CCITT Recommendation X.509, March 2000. 8.2. Informative References[6][7] Housley, R. and W. Polk, "Planning for PKI", August 2001.[7][8] Lloyd, S., Ed. and PKI Forum, "PKI Interoperability Framework", March 2001.[8][9] Lloyd, S., Ed. and PKI Forum, "CA-CA Interoperability", March 2001.[9][10] Shimaoka, M., NPO Japan Network Security Association, and ISEC, Information Technology Promotion Agency, Japan, "Interoperability Issues for multi PKI domain", July 2002.[10][11] NPO Japan Network Security Association and ISEC, Information Technology Promotion Agency, Japan, "Implementation Problems on PKI", Feb 2003.[11][12] Japan PKI Forum, Korea PKI Forum, PKI Forum Singapore, and Chinese Taipei PKI Forum, "Achieving PKI Interoperability 2003", July 2003.[12][13] Japan PKI Forum, Korea PKI Forum, and PKIForum Singapore,Forum Singapore, Shimaoka, et al. Expires July 10, 2007 [Page 29] Internet-Draft multi-domain PKI interoperability January 2007 "Achieving PKI Interoperability", April 2002.[13][14] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. Nicholas, "Internet X.509 Public Key Infrastructure:Shimaoka, et al. Expires January 10, 2007 [Page 22] Internet-Draft multi-domain PKI interoperability July 2006Certification Path Building", RFC 4158, September 2005. [15] "US Government PKI Cross-Certification Criteria and Methodology", January 2006. Shimaoka, et al. ExpiresJanuaryJuly 10, 2007 [Page23]30] Internet-Draft multi-domain PKI interoperabilityJuly 2006January 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. ExpiresJanuaryJuly 10, 2007 [Page24]31] Internet-Draft multi-domain PKI interoperabilityJuly 2006January 2007 Full Copyright Statement Copyright (C) The Internet Society (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 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 PropertyStatementThe 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.Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.Acknowledgment Funding for the RFC Editor function iscurrentlyprovided by theInternet Society.IETF Administrative Support Activity (IASA). Shimaoka, et al. ExpiresJanuaryJuly 10, 2007 [Page25]32] ----