Network Working Group M. Shimaoka Internet-Draft SECOM Expires: January 10, 2007 N. Hastings NIST R. Nielsen Booz Allen Hamilton July 9, 2006 Memorandum for multi-domain Public Key Infrastructure Interoperability draft-shimaoka-multidomain-pki-07 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed 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 on January 10, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo is intended to describe the foundation necessary to the deployment of a multi-domain PKI. The scope of this memo is to establish and clarify the trust relationships and interoperability between multiple PKI domains. A Certification Authority (CA) is able to extend a certification path by establishing trust with other CAs. Shimaoka, et al. Expires January 10, 2007 [Page 1] Internet-Draft multi-domain PKI interoperability July 2006 Both single- and multi-domain PKIs are established by such trust relationships between CAs. Typical and primitive PKI model is a single-domain PKI that shares the same Certificate Policy (CP) at a specified trust level. A multi-domain PKI is established by combining more than one single-domain PKI. A multi-domain PKI can be categorized as either a multi-trust point model based on the trust list model; or single-trust point model based on the Cross- Certification model. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Objective . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Document Outline . . . . . . . . . . . . . . . . . . . . . 3 1.3. Requirements and Assumptions . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Certification Authority Relationships . . . . . . . . . . 5 2.2.1. Hierarchical . . . . . . . . . . . . . . . . . . . . . 6 2.2.2. Peer . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Public Key Infrastructure (PKI) . . . . . . . . . . . . . 7 2.3.1. Simple PKI . . . . . . . . . . . . . . . . . . . . . . 8 2.3.2. Hierarchical PKI . . . . . . . . . . . . . . . . . . . 9 2.3.3. Mesh PKI . . . . . . . . . . . . . . . . . . . . . . . 10 2.3.4. Hybrid PKI . . . . . . . . . . . . . . . . . . . . . . 12 3. Trust Lists . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1. Relying Party Trust List Model . . . . . . . . . . . . . . 15 3.2. Trust Authority Model . . . . . . . . . . . . . . . . . . 16 4. PKI Domain . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.1. Requirements for PKI domain . . . . . . . . . . . . . . . 18 4.2. Risk Analysis of non-interoperable PKI domains . . . . . . 18 4.3. Trust Relationship Disclosure Requirements for multi-domain PKIs . . . . . . . . . . . . . . . . . . . . 18 5. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22 8.2. Informative References . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . . . 25 Shimaoka, et al. Expires January 10, 2007 [Page 2] Internet-Draft multi-domain PKI interoperability July 2006 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) describes basic PKI terminology necessary to consider trust relationships. Section 3 (Section 3) focuses on trust relationships established by relying parties. Section 4 (Section 4) defines a PKI domain and requirements for PKI interoperation within a PKI domain. Section 5 defines requirements for interoperation across PKI domains. Finally, Section 6 provides a glossary summarizing the terms described in the remainder of the document. 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]. Shimaoka, et al. Expires January 10, 2007 [Page 3] Internet-Draft multi-domain PKI interoperability July 2006 2. Terminology 2.1. Basic Concepts The following terms defining basic constructs are used throughout this document. Where possible, definitions found in RFC 2828 [2] have been used. Additional terms from RFC 2828 [2] and new terms 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]. 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 definition of public-key certificate] Certificate Policy "A named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements." (X.509) [5] 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) [2] End Entity 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] 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 the RFC 2828 definition of certificate 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 definition of trusted certificate] Shimaoka, et al. Expires January 10, 2007 [Page 4] Internet-Draft multi-domain PKI interoperability July 2006 2.2. Certification Authority Relationships Certification Authorities (CA) establish trust relationships by issuing certificates to other CAs. CA relationships can be either hierarchical or 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. 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) [2] Cross-Certificate A certificate issued from one CA to another CA. Subordinate CA Certificate 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 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] Peer Cross-Certificate A certificate issued from one CA to another CA where the CA that is the subject of the cross-certificate does not use the cross- certificate as its own signing 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 [2], which only addresses bilateral cross-certification. Unilateral Cross-Certification The act or process by which one CA certifies the public key of another CA by issuing a peer cross-certificate to that other CA. [modified from the RFC 2828 definition of cross-certification] Bilateral Cross-Certification Shimaoka, et al. Expires January 10, 2007 [Page 5] Internet-Draft multi-domain PKI interoperability July 2006 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 In a hierarchical relationship, as shown in Figure xxx, one CA assumes a parent relationship to the other CA. +----+ | CA | +----+ | | | v +----+ | CA | +----+ Figure 1: Hierarchical Trust Relationship There are two types of hierarchical relationships, depending on whether a subordinate CA certificate or a peer cross-certificate is used. In 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. Root CA A CA that is at the top of a hierarchy, and itself does not issue certificates to end entities (except those required for its own operation) but issues subordinate CA certificates to one or more CAs. Unifying CA A CA that is at the top of a hierarchy, and itself does not issue certificates to end entities (except those required for its own operation) but establishes unilateral cross-certification with other CAs. Shimaoka, et al. Expires January 10, 2007 [Page 6] Internet-Draft multi-domain PKI interoperability July 2006 2.2.2. Peer In 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 Relationship 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. 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) RFC 2828 [2] 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 Shimaoka, et al. Expires January 10, 2007 [Page 7] Internet-Draft multi-domain PKI interoperability July 2006 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. Public Key Infrastructure (PKI) A system of CAs that perform some set of certificate management, archive management, key management, and token management functions for a community of users in an application of asymmetric cryptography and share trust relationships, operate under a single Certificate Policy, and are either operated by a single organization or under the direction of a single organization. In addition, a PKI that intends to enter into trust relationships with other PKIs MUST designate a Principal CA that will manage all trust relationships. This Principal CA SHOULD also be the trust anchor for relying parties of that PKI. Principal CA A CA which has a self-signed certificate and is designated as the CA that will issue peer cross-certificates to principal CAs in other PKIs and be the subject of peer cross-certificates issued by principal CAs in other PKIs. In discussing different possible architectures for PKI, the concept of a certification path is necessary. A certification path is built based on trust relationships between CAs. Certification Path An ordered sequence of certificates where the issuer of each certificate in the path is the subject of the next certificate in the path. A certification path begins with an end entity certificate and ends with a trust anchor certificate. 2.3.1. Simple PKI 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 PKI Model Trust Anchor The trust anchor MUST be the self-signed certificate of the CA. Principal CA The principal CA MUST be the CA. 2.3.2. Hierarchical PKI 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 2006 +---------+ | 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 Model Trust Anchor The trust anchor MUST be root CA. Principal CA The principal CA MUST be the root CA. 2.3.3. Mesh PKI Definition A mesh PKI consists of multiple self-signed CAs that issue certificates to EEs and issue peer cross-certificates to each other. A mesh PKI MAY be a full mesh, where all CAs issue peer cross- certificates to all other CAs, as shown in Figure 6. A mesh PKI MAY be a partial mesh, where all CAs do not issue peer cross- certificates to all other CAs. In a partial mesh PKI, certification paths may not exist from all CAs to all other CAs, as shown in Figure 7. Shimaoka, et al. Expires January 10, 2007 [Page 10] Internet-Draft multi-domain PKI interoperability July 2006 +-----+ +--------> | CA1 | <------+ | +-----+ | | | | | +---+--+ | | v v | | +----+ +----+ | | | EE | | EE | | | +----+ +----+ | v v +-----+ +-----+ | CA2 | <---------------> | CA3 | +-----+ +-----+ | | +---+--+ +------+------+ v v v v v +----+ +----+ +----+ +----+ +----+ | EE | | EE | | EE | | EE | | EE | +----+ +----+ +----+ +----+ +----+ Figure 6: Full Mesh PKI model +-----+ +-------> | CA1 | --------+ | +-----+ | | | | | +---+--+ | | v v | | +----+ +----+ | | | EE | | EE | | | +----+ +----+ | v v +-----+ +-----+ | CA2 | | CA3 | +-----+ +-----+ | | +---+--+ +------+------+ v v v v v +----+ +----+ +----+ +----+ +----+ | EE | | EE | | EE | | EE | | EE | +----+ +----+ +----+ +----+ +----+ Figure 7: Partial Mesh PKI model Trust Anchor Shimaoka, et al. Expires January 10, 2007 [Page 11] Internet-Draft multi-domain PKI interoperability July 2006 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 for the 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, in Figure xxx 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 The principal CA MAY be any CA within the PKI. However, the mesh PKI MUST have only one principal CA, and a trust path MUST exist from the principal CA to every CA within the 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. 2.3.4. Hybrid PKI Definition A hybrid PKI is a PKI that uses a combination of peer cross- certificates and subordinate CA certificates to define the CAs that are a part of the PKI. 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 for the relying party who is not issued a certificate from the mesh PKI MAY be any self-signed CA in the PKI. Principal CA Shimaoka, et al. Expires January 10, 2007 [Page 12] Internet-Draft multi-domain PKI interoperability July 2006 The principal CA MAY be any CA within the PKI that has a self- signed certificate. However, the hybrid PKI MUST have only one principal CA, and a trust path MUST exist from the principal CA to every CA within the PKI. Considerations This model SHOULD be used sparingly because of the complexity of determining trust anchors and building certification paths. However, hybrid PKIs may occur as a result of the evolution of a PKI over time, such as CAs within an organization joining together to become a single PKI. Shimaoka, et al. Expires January 10, 2007 [Page 13] Internet-Draft multi-domain PKI interoperability July 2006 3. Trust Lists Relying parties MAY choose to trust multiple PKIs through the use of trust lists. Trust lists can be managed by an individual relying party or by a trust authority that is shared by multiple relying parties. Trust List A list of one or more trust anchors used by a relying party to explicitly trust a PKI. Trust Authority An entity that manages a centralized trust list for one or more relying parties. Figure 8 shows an example of a trust list that contains a simple PKI, a hierarchical PKI, and a full mesh PKI. Shimaoka, et al. Expires January 10, 2007 [Page 14] Internet-Draft multi-domain PKI interoperability July 2006 Trust List +--------------------------------------------------------------+ | Trust Anchors | | | | +---------------+ +---------------+ +----------------------+ | | | PKI 1 | | PKI 2 | | PKI 3 | | | | | | | | | | | | +----+ | | +----+ | | +----+ | | | | | CA | | | | CA | | | | CA | <-----+ | | | | +----+ | | +----+ | | +----+ | | | | | | | | | | | ^ | | | +---------|-----------------|-------------|----------|---------+ | | | | | | | | | | | +---+--+ | | v | | | v | | v v | | +----+ | | | +----+ | | +----+ +----+ | | | CA | | | | | CA | | | | EE | | EE | | | +----+ | | | +----+ | | +----+ +----+ | | | | | | ^ | | | | | +---+--+ | | v | | | +---------------+ | v v | | +----+ | | | | +----+ +----+ | | | CA | <---+ | | | | EE | | EE | | | +----+ | | | +----+ +----+ | | | | | | | | | +---+--+ | +---------------+ | v v v | | +----+ +----+ +----+ | | | EE | | EE | | EE | | | +----+ +----+ +----+ | +----------------------+ Figure 8: Trust List 3.1. Relying Party Trust List Model Any Relying Party MAY choose to trust certificates issued by a PKI by installing a trust anchor for that PKI into its local trust list. Installing a PKI's trust anchor into a local trust list the 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 other PKI. 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. Considerations Shimaoka, et al. Expires January 10, 2007 [Page 15] Internet-Draft multi-domain PKI interoperability July 2006 Relying parties 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 the PKI as defined in the PKI's certificate policy. Also, the relying party will not be directly informed if the trust anchor's certificate is revoked, and so MUST check the PKI's repository to verify the status of the trust anchor. Relying parties MUST be aware of these considerations when making a decision 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 do not inadvertently trust certificates from cross-certified PKIs that they did not intend to trust. For example: Assume certification path X->Y->Z->EE(Z) exists. When cross- certificate X->Y includes pathLenConstraints=1, CA-Z cannot extend the certification path started from CA-X by more cross certificates. However, if the relying party trust CA-Y directly, the cross certificate constraint in X->Y is ignored allowing CA-Z to extend the certification path by more cross certificates. Thus, relying party MUST recognize a risk of trusting another CA directly. PKIs that intend to support the relying party trust list model SHOULD publish their certificate policies so that relying parties can determine if their use is supported under the policy. PKIs SHOULD also broadly publicize any revocation of a trust anchor CA or the principal CA (email, repository, press release, etc.). 3.2. Trust Authority Model A relying party MAY choose to trust certificates issued by PKIs that are themselves trusted by a trust authority. The trust authority MAY manage multiple trust lists for use by different relying parties. In this trust authority model, the trust authority acts as a third party broker between relying parties and trusted PKIs. There are currently no commercially available products that support the trust authority model. However, this model may be useful when a number of relying parties within a community of interest wish to centrally manage trusted PKIs and where the PKIs that issue certificates to EEs within this community of interest do not themselves desire to cross-certify. Considerations Shimaoka, et al. Expires January 10, 2007 [Page 16] Internet-Draft multi-domain PKI interoperability July 2006 All of the considerations for the relying party trust list model apply to the trust authority model. Where possible, trust authorities SHOULD register with the PKIs they include in their trust lists so that they can be informed of changes in PKI certificate policies or revocation of a trust anchor CA or the principal CA. Relying parties using trust authorities are relying on the accuracy of the trust list as maintained by the trust authority. Relying parties MAY also be relying on the trust authority to provide revocation information for CA and EE certificates. As a result, trust authorities SHOULD provide information to relying parties for how additional trust anchors are added to the trust list and what network and other security controls are maintained by the trust authority to ensure reliability and accuracy of the information provided by the trust anchor. Shimaoka, et al. Expires January 10, 2007 [Page 17] Internet-Draft multi-domain PKI interoperability July 2006 4. PKI Domain 4.1. Requirements for PKI domain 4.2. Risk Analysis of non-interoperable PKI domains 4.3. Trust Relationship Disclosure Requirements for multi-domain PKIs Shimaoka, et al. Expires January 10, 2007 [Page 18] Internet-Draft multi-domain PKI interoperability July 2006 5. Abbreviations PKI: Public Key Infrastructure CA: Certification Authority EE: End Entity CRL: Certificate Revocation List ARL: Authority Revocation List PCA: Principal Certification Authority RP: Relying Party CP: Certificate Policy CPS: Certification Practice Statement DN: Distinguished Name Shimaoka, et al. Expires January 10, 2007 [Page 19] Internet-Draft multi-domain PKI interoperability July 2006 6. Security Considerations TBD. Shimaoka, et al. Expires January 10, 2007 [Page 20] Internet-Draft multi-domain PKI interoperability July 2006 7. IANA Considerations This document has no actions for IANA. Shimaoka, et al. Expires January 10, 2007 [Page 21] Internet-Draft multi-domain PKI interoperability July 2006 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] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002. [5] International International Telephone and Telegraph Consultative Committee, "Information Technology - Open Systems Interconnection - The Directory: Authentication Framework", CCITT Recommendation X.509, March 2000. 8.2. Informative References [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. [13] 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 2006 Certification Path Building", RFC 4158, September 2005. Shimaoka, et al. Expires January 10, 2007 [Page 23] Internet-Draft multi-domain PKI interoperability July 2006 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. Expires January 10, 2007 [Page 24] Internet-Draft multi-domain PKI interoperability July 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF 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 is currently provided by the Internet Society. Shimaoka, et al. Expires January 10, 2007 [Page 25]