From: http://www.ietf.org/internet-drafts/draft-shimaoka-multidomain-pki-00.txt Title: Memorandum for Multi-Domain PKI Interoperability Reference: draft-shimaoka-multidomain-pki-00.txt ------------------------------------------------------------------------------ Network Working Group M. SHIMAOKA Request for Comments: DRAFT Japan PKI Forum June 2003 Memorandum for multi-domain PKI Interoperability draft-shimaoka-multidomain-pki-00.txt Status of this Memo This memo is a guideline for the multi-domain PKI interoperability. This is a best current practice, not a specification. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (date). All Rights Reserved. Abstract This memo is used to share the awareness necessary to deployment of multi-domain PKI. Scope of this memo is to establish trust relationship and interoperability between plural PKI domains. Both single-domain PKI and multi-domain PKI are established by the trust relationships between CAs. Typical and primitive PKI models are specified as single-domain PKI. Multi-domain PKI established by plural single-domsin PKI is categorized as multi-trust point model and single-trust point model. Multi-trust point model is based on trust list model, and single-trust point model is based on cross- certification. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2 Requirements and Assumptions . . . . . . . . . . . . . . . . . 2 2.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 Trust Relationship . . . . . . . . . . . . . . . . . . . . . . . 3 3.1 Trust List . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1.1 User Trust List . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.2 Authority Trust List . . . . . . . . . . . . . . . . . . . . 5 3.2 Cross-Certification . . . . . . . . . . . . . . . . . . . . . . 6 3.2.1 Unilateral Cross-Certification . . . . . . . . . . . . . . . 6 3.2.2 Mutual Cross-Certification . . . . . . . . . . . . . . . . . 7 3.3 Subordination (Hierarchy) . . . . . . . . . . . . . . . . . . . 8 4 Single-domain PKI . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1 Single PKI . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2 Hierarchy PKI . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3 Mesh PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 SHIMAOKA [Page 1] INTERNET DRAFT June 2003 5 multi-domain PKI . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1 Multi Trust point model (based on Trust List) . . . . . . . . . 10 5.1.1 Based on User Trust List . . . . . . . . . . . . . . . . . 11 5.1.2 Based on Authority Trust List . . . . . . . . . . . . . . . . 11 5.2 Single Trust Point model (based on Cross-Certification) . . . . 11 5.2.1 Peer-to-Peer model (based on Cross-Certification) . . . . . . 12 5.2.2 Super Domain model (based on unilateral Cross-Certification). 12 5.2.3 Hub model (a.k.a Bridge CA) . . . . . . . . . . . . . . . . . 12 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 12 6.1 Certificate and CRL Profile . . . . . . . . . . . . . . . . . . 12 6.2 Repository . . . . . . . . . . . . . . . . . . . . . . . . 12 6.3 Path Validation . . . . . . . . . . . . . . . . . . . . . . . . 12 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 10 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 13 1 Introduction PKI is able to achieve various architecture, through the means that CAs establish trust relationship with each other. When a certain CA establishes a trust-relationship with another CA, the CA MUST compare the policy of each CAs carefully because various CAs have various policy. So, establishment method for every trust-relationship MAY differ by the result of comparison. To establish appropriate trust- relationship, fully understanding about a relationship between such establishment method and comparison is required. In addition, all trust-relationships established are able to categorize two patterns, single-domain PKI and multi-domain PKI. The technology needed for such an interconnection is insufficient with only the specification of conventional protocol and data format and need to define the thing such as PKI domain and PKI architecture. This document clarifies these definitions for multi-domain PKI interoperability. Section 2 describes the terminology necessary to consider multi- domain PKI. Section 3 categorizes the trust relationships between CAs as Trust List, Cross-Certification, and Hierarchy. Section 4 defines major models necessary to establish single-domain PKI. Section 5 profiles multi-domain PKI as multi trust point model and single trust point model. Multi-trust point model is based on trust list model. Single-trust point model is based on cross-certification model , and is categorized as peer model, super-domain model and hub model. Finally, section 6 describes considerations focused on certificate and CRL profiles, Repository, and path validation. 2 Requirements and Assumptions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", SHIMAOKA [Page 2] INTERNET DRAFT June 2003 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2.1 Terminology Top CA Only CA that is as a root of hierarchy PKI model. Top CA MUST issue a self-signed certificate. Top CA SHOULD be used for Hierarchy PKI model. PKI domain A set of PKIs, which gathers upon a certain trust relationship, and MUST share a certain policy, at least one. Essentially, PKI domain is only a view from relying-party outside of subscriber domain. Domain Policy A set of certificate policies what are shared in a PKI domain. Trust Point Starting point of a certification path to SUBSCRIBER certificate. In some situations, it MAY mean just a node of certification path. Trust Point MUST be a self-signed certificate, except for Mesh PKI. Principal CA A CA that trusts other PKI domain or is trusted from other PKI domain. Principal CA SHOULD issue a self-signed certificate. Trust Anchor Trust anchor is a principal CA in RELYING-PARTY domain, and is also one of trust-points. Trust Anchor SHOULD be a self-signed certificate, except for Mesh PKI. If it is necessary to claim clearly that CA is a trust anchor of a issued certificate, CA MAY indicate URI of its published CA certificate to caIssuer in AuthorityInformationAccess extension. Trust Relationship In this document, this means a trust relation ship between CAs. This relationship is required for tracking from a trust point to a SHIMAOKA [Page 3] INTERNET DRAFT June 2003 subscriber. Subscriber Holder of the certificate which is verified. Relying-Party Entity who verifies the certificate. Validation parameters This is a term for only this document. Five parameters that are part of seven inputs for path validation defined in section 6.1.1 of RFC3280. (c) user-initial-policy-set (d) trust anchor information, (e) initial-policy-mapping-inhibit (f) initial-explicit-policy (g) initial-any-policy-inhibit As these parameters MAY NOT be depended on a built certification path and validation time, these parameters are bound to a trust point and are able to consider without two parameters '(a) a prospective certification path of length n' and '(b) the current date/time'. 3 Trust Relationship This section describes major trust-relationships for plural PKI interconnection. 3.1 Trust List Definition Trust list is a list of more than one CA certificate that means a trust point. Trust list is used for specifying a trust point by relying-party. Requirements CA in a trust list SHOULD NOT cross-certify each other. All relying-parties in this model MUST have a trust list. Considerations TBD SHIMAOKA [Page 4] INTERNET DRAFT June 2003 3.1.1 User Trust List Definition The model in which a trust list is managed by EE. EE is able to have its own user trust list individually. Advantage # EE is able to manage the user trust list. EE is able to add any CA certificate to its own user trust list or delete it. This is an easier and typically method for making a trust relationship to other PKI. Disadvantage Anybody except for EE itself is not able to control trust relationship. If EE trusts unknown PKI domain irresponsibly, then its issuer CA cannot apply their security policy to the EE. Considerations To consider how to update "user trust list", when CA certificate in "user trust list" is updated. 3.1.2 Authority Trust List Definition The model in which an trust list is issued by the trust anchor of relying-party. All EEs who share the same trust anchor SHOULD share a single authority trust list provided by its trust anchor. Advantage EE cannot control his trust relationship from his trust anchor to other. Authority SHOULD control trust relationship. Disadvantage Management method for authority trust list is not established. Considerations To consider about a format of "authority trust list" that is able to be processed by various applications. To consider about a management method for "authority trust list". SHIMAOKA [Page 5] INTERNET DRAFT June 2003 3.2 Cross-Certification Definition Cross-Certification is an issuing certificate to another CA. Requirement CA issued cross-certificate SHOULD have a self-signed certificate. Advantage Cross-Certification is stricter trust relationship than trust list model, because the trust relationship is indicated by a certificate and (authority) revocation list and is recorded to an audit log. Because all subject CAs have a self-signed certificate, a cross- certificate revocation does not always link to the subject CA compromise. Disadvantage CA MUST support cross-certification. Considerations for PKI issuing Revocation List Issuer CA MAY issue ARL, or SHOULD issue fullCRL at least. However, ARL including issuingDistributionPoint extension MAY NOT be processed by some applications. for CA Key Rollover TBD 3.2.1 Unilateral cross-certification Definition The model in which a CA issues a cross-certificate to another CA unilaterally. Advantage This certification is able to used like subordination, and is able to establish more flexible trust relationship. Even if cross- certificate is revoked, subject CA MAY be able to continue its operation. SHIMAOKA [Page 6] INTERNET DRAFT June 2003 Disadvantage for PKI using directory system CA SHOULD generate a crossCertificatePair, even though unilaterally. Considerations Subordination is peculiar unilateral cross-certification. for PKI using directory system Issuer CA MUST store a cross-certificate, which he issued, to issuedByThisCA element of crossCertificatePair attribute in its own directory entry, except subordinate CA certificate. Subject CA SHOULD store a issued cross-certificate to issuedToThisCA element of crossCertificatePair attribute in its own directory entry, except subordinate CA certificate. 3.2.2 Mutual cross-certification Definition The model in which a CA issues a cross-certificate to another CA mutually. Advantage TBD Disadvantage for PKI using directory system Both CAs MUST generate a crossCertificatePair. Considerations for PKI using directory system Each CAs MUST generate a crossCertificatePair that is composed by cross-certificate it issues and issued cross-certificate. for issuing cross-certificate Both CAs MUST agree about more information to issue a cross-certificate (e.g., validity, SHIMAOKA [Page 7] INTERNET DRAFT June 2003 keyUsage, and some constraints) and MUST exchange it. 3.3 Subordination(Hierarchy) Subordination is an peculiar unilateral cross-certification. Definition Subordination is certificate issuing to CA that have no self-signed certificate. Subordinate CA MUST have only one superior CA. In unilateral cross-certification, subject CA MAY have some issuer CAs. Advantage Subordinate CA MAY NOT require any accreditation, rather the accreditation is required only for superior CA or top CA. Subordinate CA is able to inherit some policies and constraints from its superior CA. Because Subordinate CA has clear trust relationship with its superior CA, the subordinate CA is able to be trusted easily by all EEs who trust the superior CA. Disadvantage Subordinate CA MUST NOT cross-certify any CAs , MAY just allow a subordination. When a subordinate CA certificate is revoked by a superior CA, also all certificates issued by the subordinate CA MUST NOT be trusted. Considerations Subordination MUST be used in Single-domain PKI, not multi-domain PKI. for PKI using directory system Superior CA MUST NOT store a subordinate CA certificate to issuedByThisCA element of crossCertificatePair attribute in its own (superiorCA) entry, because path construction will work inefficiently. Subordinate CA MAY store its own subordinate CA certificate to issuedToThisCA element of crossCertificatePair attribute in its own (subordinate CA) entry. Subordinate CA MUST store its own subordinate CA certificate to cACertificate attribute in its own entry. SHIMAOKA [Page 8] INTERNET DRAFT June 2003 4 Single-domain PKI This section describes appropriate PKI architectures for single PKI domain. 4.1 Single PKI This is simplest PKI model. All PKI models are composed of set of this. Definition Single PKI is composed of an only top CA and its EEs. All EEs SHOULD trust only the top CA. All subscribers MUST be issued their certificate by the only top CA. Principal CA Principal CA MUST be the top CA. Trust anchor Trust anchor MUST be the top CA. 4.2 Hierarchy PKI This is a typical architecture of PKI. Definition Hierarchy PKI is composed of an only top CA, some subordinate CAs and EEs. Only a Top CA MUST issue a self-signed certificate. All subordinate CAs MUST have only one superior CA. Principal CA Principal CA MUST be the top CA. Trust anchor Trust anchor MUST be the top CA. All EEs SHOULD trust only a top CA. 4.3 Mesh PKI Definition SHIMAOKA [Page 9] INTERNET DRAFT June 2003 Mesh PKI is composed of plural CAs and their EEs. All CAs MUST cross-certify more than one CA unilaterally, and MUST be cross- certified by more than one CA unilaterally. Principal CA Principal CA SHOULD be unique in the domain. Trust anchor Trust anchor SHOULD be a CA which issued a certificate to relying- party. Considerations All EEs MUST trust only a CA that issued their own certificate. Which SHOULD be a principal CA? 5 multi-domain PKI Multi-domain PKI is composed of plural PKI domain that MUST have different domain policy which is able to map each other. Each PKI domain establishes a trust relationship with more than one PKI domain. This section describes topology models for multi-domain PKI. Considerations Required all information for path validation MUST be able to be obtained through Internet. - Intermediate certificate - Revocation information For this, CA MAY operate a repository, and SHOULD include authorityInfoAccess or cRLDistributionPoints extensions in the certificates it issues. 5.1 Multi Trust point model (based on Trust List) The model in which a relying-party trusts plural domains by a trust list. Relying-party is able to use trust list for specifying the trust point in other domains. Trust list is a list of more than one CA certificate as a principal CA certificate in another domain. SHIMAOKA [Page 10] INTERNET DRAFT June 2003 Considerations The CA in a trust list SHOULD not cross-certify each other. The validation parameters SHOULD be given to each trust point individually. 5.1.1 Based on User Trust List Considerations This is an easier and typically method for making a trust relationship to other PKI domain. Relying-Party is able to establish trust relationship with other domain irresponsibly to his trust anchor. When CA updated the certificates, what relying-party recognizes it is difficult. Relying-party needs to obtain some inputs, e.g.,user-initial-policy-set, initial-policy-mapping- inhibit, initial-explicit-policy and initial-any-policy-inhibit, for path validation from somewhere. 5.1.2 Based on Authority Trust List Authority MAY distribute the validation parameters by including in the trust list. Considerations Relying-party needs to obtain some inputs, e.g.,user-initial- policy-set, initial-policy-mapping-inhibit, initial-explicit-policy and initial-any-policy-inhibit, for path validation from somewhere. 5.2 Single Trust Point model (based on Cross-Certification) The model in which all domains related by Cross-Certification. In this model, a trust point is just a trust anchor. Therefore, certification path always start from trust anchor of relying-party. Considerations Each domain SHOULD use policy mapping for indicating different domain. In addition, cross-certificate SHOULD set zero to requireExplicitPolicy in the policyConstraints extension, and MAY set any value to inhibitPolicyMappings in the policyConstraints extension. If the domain does not use policy mapping, it MAY seem same domain. All certification path MUST be started from the only trust anchor, SHIMAOKA [Page 11] INTERNET DRAFT June 2003 then validation parameters MAY be an only set. Cross-Certificate SHOULD use authorityKeyIdentifier extension and subjectKeyIdentifier extension for path construction. 5.2.1 Peer-to-Peer model (based on Cross-Certification) The model in which two peer domains trust each other by Cross- Certification. This trust relationship SHOULD be established by mutual Cross-Certification, or MAY be established by unilateral Cross-certification. In Cross-Certification model, because trust-anchor is an only one, the validation parameters SHOULD be authority-constrained things. 5.2.2 Super Domain model (based on unilateral Cross-Certification) The model in which plural domains have a common superior CA that issues cross-certificates to each domain unilaterally. Each domain MUST have a certain common certificate policy at least. 5.2.3 Hub model (a.k.a Bridge CA) The model in which every domains trust each other through a Bridge CA by Cross-Certification. This is useful to reduce the complexity of cross-certification. Considerations BCA SHOULD be operated by neutral trusted third party. BCA SHOULD do policy mapping appropriately with both domains. Both domains that cross-certified to BCA SHOULD NOT use nameConstraints extension because they cannot limit name-spaces via BCA. BCA MUST have an independent certificate policy, and MUST use it for policy mapping for both domains. 6 Security Considerations 6.1 Certificate and CRL Profile TBD 6.2 Repository All required information for path construction and validation SHOULD be obtained from relying-party. 6.3 Path Validation SHIMAOKA [Page 12] INTERNET DRAFT June 2003 Validation parameters SHOULD be intersection between authority- constrained parameters and user-constrained parameters. Which SHOULD be a trust anchor for non certificate holder? 7 References [RFC 3280] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 3280, April 2002. [INTEROP] Lloyd, S., PKI Forum, "PKI Interoperability Framework", March 2001. [CA-CA] Lloyd, S., PKI Forum, "CA-CA Interoperability", March 2001. [ISO-X509] ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information Technology - Open Systems Interconnection: The Directory: Authentication Framework," 2001 edition. 8 Acknowledgements 9 Author's Address Masaki SHIMAOKA SECOM Trust.net Co., Ltd. SECOM SC Center, 8-10-16, Shimorenjaku Mitaka, Tokyo JAPAN Phone: +81-422-91-8493 Email: shimaoka@secom.ne.jp 10 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other SHIMAOKA [Page 13] INTERNET DRAFT June 2003 Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. SHIMAOKA [Page 14]