view Side-By-Side changes
Request for Comments: DRAFT SECOM Trust.net<draft-shimaoka-multidomain-pki-02.txt> January<draft-shimaoka-multidomain-pki-03.txt> July 2004 Memorandum for multi-domain Public Key Infrastructure (PKI) Interoperability Status of this MemoThis memo is a guideline forBy submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of themulti-domain PKI interoperability. This is a best current practice, notInternet 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 aspecification. Distributionmaximum ofthis memosix months and may be updated, replaced, or obsoleted by other documents at any time. It isunlimited. Copyright Notice Copyright (C)inappropriate to use Internet-Drafts as reference material or to cite them other than a "work in progress." TheInternet Society (2004). All Rights Reserved.list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This memo isusedintended tosharedescribe theawarenessfoundation necessary to the deployment of a multi-domain PKI.ScopeThe scope of this memo is to establish andclearclarify the trust relationship and interoperability betweenpluralmultiple PKI domains. Certification Authority (CA) is able to extend a certification path by trusting from/by other CAs. Both single-domain PKI and multi-domain PKI are established bythesuch trust relationships betweenCertification Authorities (CAs).CAs. Typical and primitive PKI models are specified as single-domainPKI. Multi- domainPKIs. A multi-domain PKI establishedby pluralfrom more than one single-domain PKI is categorized asmulti-trusteither a multi- trust point modelandor single-trust point model.Multi-trustThe multi-trust point model is based on the trust list model, and the single-trust point model is based oncross-certificationthe Cross-Certification model. Shimaoka [Page 1] INTERNET DRAFT January 2004 Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2 Requirements and Assumptions . . . . . . . . . . . . . . . . . 3 2.1 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3 Trust Relationship . . . . . . . . . . . . . . . . . . . . . . . 6 3.1 Operation based TrustList . . . . . . . . . . . .Relationship . . . . . . . . . . . . . . 6 3.1.1 User Trust List. . .model . . . . . . . . . . . . . . . . . . . . 7 3.1.2 Authority Trust List. . .model . . . . . . . . . . . . . . . . . 8 3.2Cross-Certification . . . . . . . . .Certificate based Trust Relationship . . . . . . . . . . . . . 8 3.2.1 Unilateral Cross-Certification . . . . . . . . . . . . . . . 9 3.2.2 Mutual Cross-Certification . . . . . . . . . . . . . . . . . 11 3.3 Subordination (Hierarchy) . . . . . . . . . . . . . . . . . . . 12 4 PKI Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Shimaoka [Page 1] INTERNET DRAFT January 20044.1 Requirements for PKI domain . . . . . . . . . . . . . . . . . . 14 4.2 Risk Analysis of non interoperable PKI domain . . . . . . . . . 14 4.3 Requirements for multi-domain PKI interoperability . . . . . . 14 5 Single-domain PKI . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1 Single PKI model . . . . . . . . . . . . . . . . . . . . . . . 15 5.2 Hierarchy PKI model . . . . . . . . . . . . . . . . . . . . . . 16 5.3 Mesh PKI model . . . . . . . . . . . . . . . . . . . . . . . . 17 6 multi-domain PKI . . . . . . . . . . . . . . . . . . . . . . . . 18 6.1 Multi Trust point model . . . . . . . . . . . . . . . . . . . . 18 6.1.1 Based on User Trust List . . . . . . . . . . . . . . . . . 19 6.1.2 Based on Authority Trust List . . . . . . . . . . . . . . . . 19 6.2 Single Trust Point model . . . . . . . . . . . . . . . . . . . 196.2.1 Peer-to-Peer6.2.2 Unified Domain model . . . . . . . . . . . . . . . . . . . ..206.2.2 Unified Domain6.2.3 Bridge model . . . . . . . . . . . . . . . . . . . .20 6.2.3 Hub model (a.k.a Bridge CA) .. . . . 21 7 Operational Considerations . . . . . . . . . . . .21 6.2.4 Considerations for trusted third CA. . . . . . 23 7.1 Directory . . . . . . .22 7 Security Considerations. . . . . . . . . . . . . . . . . . . . 237.1 Certificate and CRL Profile7.2 Cross-Certification . . . . . . . . . . . . . . . . . .23 7.2 Repository. . . . 24 8 Security Considerations . . . . . . . . . . . . . . . . . . . .24 7.3 Path Validation23 8.1 Certificate and CRL Profile . . . . . . . . . . . . . . . . . . 23 8.2 Path Validation . . . . . .24 7.4 Public PKI and Private PKI. . . . . . . . . . . . . . . . . . 247.58.3 Asymmetric problem . . . . . . . . . . . . . . . . . . . . . . 257.5.18.3.1 Hybrid trust model . . . . . . . . . . . . . . . . . . . . . 257.5.28.3.2 Asymmetric policy mapping . . . . . . . . . . . . . . . . . . 2589 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 268.19.1 Normative References . . . . . . . . . . . . . . . . . . . . . 268.29.2 Informative References . . . . . . . . . . . . . . . . . . . . 26910 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 271011 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 271112 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 27 Shimaoka [Page 2] INTERNET DRAFT January 2004 1 Introduction PKI isableextendable to realize variousarchitecture,architectures, through themeans thatway in which CAs establish a trustrelationshiprelationships with each other. When a certain CA establishes a trust relationship with another CA, theCACAs MUST compare the security level as certificate policy ofeach CAsthe other carefully because various CAs have various certificatepolicy.policies. So,establishmentthe methodforof establishment of every trust relationship MAYdiffer by thediffer, as a result of such comparison. To establish appropriate trustrelationship, fullyrelationships, full understandingabout aof the relationship betweensuchthe establishment method and comparison is required. In addition, all established trust relationshipsestablished are able to categorizefall into one of twopatterns,patterns: single-domain PKI and multi-domain PKI. The technology needed for such an interconnection is insufficient with only thespecificationspecifications of conventionalprotocolprotocols and dataformat and need to define the thingformats; elements such as PKI domain and PKIarchitecture.architecture require definitions. This document clarifies these definitions for multi-domain PKI interoperability.Shimaoka [Page 2] INTERNET DRAFT January 2004Section 2 describes the terminology necessary to consider multi- domain PKI. Section 3 categorizes the trust relationships between CAs as Trust List, Cross-Certification, and Subordination. Section 4 defines a PKI domain and requirements for multi-domain interoperability. Section 5 defines major models necessary to establish single-domain PKI. Section 6 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 the cross-certification model , and is categorized as peer model, unified domain model and hub model. Finally, section 7 describes considerations focused on Certificate and Certificate Revocation List (CRL) profiles,Repository,Repositories, and path validation. +------------------+ +-------------------+ | PKI domain | | PKI domain | | | Domain-Domain | | | | Trust | | | +-----+ | Relationship | +-----+ | | | PCA |<===========================>| PCA | | | +-----+ | | +-----+ | | ^ | | ^ | | | CA-CA Trust | | | CA-CA Trust | | | Relationship | | | Relationship | | v | | v | | +----+ | | +----+ | | | CA | | | | CA | | | +----+ | | +----+ | +------------------+ +-------------------+ Figure 1 - Structure of multi-domain PKI Shimaoka [Page 3] INTERNET DRAFT January 2004 2 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. 2.1 Abbreviations PKI: Public Key Infrastructure PKI based on X.509 is a set of CA andEEEEs in a narrow sense. But in awidebroader sense, PKI sometime means a PKI domain itself. CA: Certification Authority EE: End Entity CRL: Certificate Revocation ListShimaoka [Page 3] INTERNET DRAFT January 2004ARL: Authority Revocation List 2.2 TerminologySubscriber Holder of the certificate which is verified.Relying Party Entity who verifies the certificate. Relying party MUST havea set ofone or more trust anchors and MAY have a set ofacceptable certificatevalidation policies. In single-domain PKI, these MAY be omittedtacitly.implicitly. Intermediate Certificate Whole certificates in a certification path excepting a trust anchor and a target certificate. Top CA Only CA that isasa rootof hierarchyin Hierarchy PKI model. Top CA MUST issue a self-signed certificate. Top CA SHOULD be used for Hierarchy PKI model. For unified domain model, unificate CA SHOULD be used asbelow.defined later in this section. PKI domain PKI domain is a set of PKIsgathered upon some trust relationship. Theyfor identifying the PKI operated on the same certificate policy. Such certificate policy is called a "domain policy". PKI domain MUST havemore thanone or more principalCACAs and SHOULD havemore thanonecommon certificateor more domain policy.Such common policy is named as "domain policy".Domain PolicyMore than oneShimaoka [Page 4] INTERNET DRAFT January 2004 A common certificate policy (Object Identifier)whichthat is shared in a PKI domain.ThisThere can be multiple domain policies in a PKI domain. The ObjectIdentifierIdentifier(s) belonging to a PKI domain is used to distinguisheachthat PKIdomain.domain from another. A PKI domain having no certificate policy MAYbenotdistinguishedbe identified by the relying party in another PKI domain. TrustPointAnchor Starting point of a certification path to a subscribercertificate. Trust Point MUSTcertificate, which is specified by a relying party. If a relying party have to perform a validation of the trust anchor, it SHOULD be verified by some trustworthy out-of-band procedure, and is not within the scope of this memo. In addition, trust anchor SHOULD be a CA issuing a self-signedcertificate, exceptcertificate forMesh PKI model. Principal CA A CA in a PKI domain that trusts other PKI domain directly oran operational reason, which istrusted from other PKI domain directly. Principal CA SHOULD issue a self-signed certificate. Shimaoka [Page 4] INTERNET DRAFT January 2004capable of verifying easily the binding of the private key and the public key. Trusted PKI domain PKI domain which is trusted from trusting PKI domain. Usually, trusted PKI domain meansathe PKI domain of the subscriber. Trusting PKI domain PKI domain which trusts other PKI domains. Usually, trusting PKI domain meansathe PKI domain of the relying party. TrustAnchor 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 model. If it is necessary to claim clearly that CA is a trust anchor of an issued certificate, CA MAY indicate URI of its published CA certificate to caIssuer in AuthorityInformationAccess extension. Public PKI PKI using the trust point that is registered without user's clear agreement. Generally, trust point is registered to certificate store managed by OS or each applications. Web browser using its embedded root certificates for SSL/TLS is typical model of this. Private PKI PKI using the trust point that is registered with user's clear agreement. Generally, all trust point registration require clear user's agreement. In Private PKI, each PKI domain MUST have a domain policy. TrustRelationship In this document, this means a trust relationship between CAs. This relationship is required fortrackingtrailing from a trustpointanchor to a subscriber. Validation parameters This is a term for only this document. Five parameters that areparta subset of the 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-inhibitShimaoka [Page 5] INTERNET DRAFT January 2004(f) initial-explicit-policy (g) initial-any-policy-inhibit As these five parameters MAY NOT bedependeddependent on a built certification path and validation time,these parameters arethey SHOULD be bound to a trustpointanchor and are able toconsiderbe considered without two parameters '(a) a prospective certification path of length n' and '(b) the Shimaoka [Page 5] INTERNET DRAFT January 2004 current date/time'. Theseparameters SHOULD be bound totwo above mentioned parameters, however, are not dependent on a trustpoint,anchor, sincethese except two parameters depending onthey each depend on certification pathandor validation time. Unificate CA CA which has a self-signed certificate and issued unilateral cross- certs to each principal CA of other PKI domains. Unificate CA is specified as a trustpoint inanchor for the PKI domains thatisare cross- certified by this CA unilaterally.Trusted third CA CA which is as trusted third party for each PKI domains, andTrust List Trust list isnecessary to establisha list of one or more trustmodel like hub model and unified- domain model. 2.3 Assumptions In this document, eachanchors, which MAY be a set of the trust anchor certificates in general. Trust list is used for specifying a trust anchor by a relying party. Cross-Certification Cross-Ceritification is an issuing certificate to another CA. 2.3 Assumptions In this document, each PKI MUST have a repository for supporting the path validation, but this document does not specify whether the repository is web server or directory server. 3 Trust Relationship This section describes major trust relationships forpluralmultiple PKI(CA)interconnection.interconnections. All PKIs that are going to participate in multi- domain PKI SHOULD use these trust relationships for multi-domain PKI interoperability. 3.1 Operation based TrustListRelationship DefinitionTrust list is a list of more than one "trusted CA" certificate that means a trust point. Trust list is used for specifying a trust point by relying party. Requirements CAdefined inaterminology section 2.2 Requirements CAs on the same trust list SHOULD NOT cross-certify each other. All relying parties in this model MUST have a trust list. There SHOULD be different validation policies for every trust anchor. Considerations Shimaoka [Page 6] INTERNET DRAFT January 2004be each appropriate validation parameters for every trust points in trust list. Considerations In this model,A relying partytrusts more than oneusing the trustpoints. Butlist MAY trust multiple trust anchors, but finding out a revocation of each trustpointsanchor is more difficult thandoingfinding out itto one trust point.for one. Trust List +--------------------------------------------------------------+ | Trusted CA | | | | +---------------+ +---------------+ +----------------------+ | | | PKI 1 | | PKI 2 | | PKI 3 | | | | | | | | | | | | +-----+ | | +-----+ | | +-----+ | | | | +---| PCA | | | | PCA | | | | PCA |<--+ | | | | | +-----+ | | +-----+ | | +-----+ | | | | | | | | | | | | ^ | | | +-----|------|-----------|----------------|-------|------------+ | | | | | | | | | | | | | | | | | | | | v | | | | | | | | | | +----+ | | | | | | | | | | | CA |---+ | | | | | | | | | | +----+ | | | | | | | | | | | ^ | | | | | | | | v | | v | | | | | | | | | +----+ | | +----+ | | | | | | | | | | CA |---+ | | | CA |---+ | | | | | | | | +----+ | | | +----+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | v v | | v v | | v v v | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ | | | EE | | EE | | | | EE | | EE | | | | EE | | EE | | EE | | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ | +---------------+ +---------------+ +----------------------+ Figure 2 - Trust List model 3.1.1 User Trust List model Definition The model in which a trust list is managed by EndEntitiy (EE).Entities (EEs). Each EE is able to have its own user trustlist individually. Shimaoka [Page 7] INTERNET DRAFT January 2004 Advantagelist. Characteristics EE is able to manage its own user trust list. EE is able to add or delete a"trusted CA" certificate totrust anchor from its own user trustlist or delete it.list. This is an Shimaoka [Page 7] INTERNET DRAFT January 2004 easier and typical method for making a trust relationshipto otherwith another PKI.DisadvantageExcept for EE itself,anyoneno one isnotable to control the trust relationship.IfThere is a risk that EE trusts unknown PKI domain irresponsibility. If EE trusts unknown PKI domains irresponsibly, then its issuer CA cannot applytheirits certificate policy to the EE. A trust anchor MAY not apply its validation policy to the EE. Considerations To consider how to update the user trust list, when a CA certificate in the user trust list is updated. 3.1.2 Authority Trust List model Definition The model in which a trust list isissuedmanaged by the trust anchor of relying party. The trust anchor MAY issuepluralmultiple trustlistlists for somepurposepurposes orsomeparties. EEswho sharetrusting the same trust anchorMAYmay sharea uniquethe authority trust listprovidedgiven byitsthe trust anchor.AdvantageCharacteristics EEcannotdoes not have controlitsover any trustrelationshiprelationships from its trustanchor to other.anchor. Trust anchor SHOULD control an appropriate trust relationship.Disadvantage In Internet PKI,Considerations Since there is no standardtofor the use of thismodel. And,model and managementmethodmethods for authority trust listisare not establishedgenerally. Considerations This is just theory for comparison with user trust list model. Since there is no standard,generally, this model MAYNOTnot achieve interoperability sufficiently. 3.2Cross-Certification Shimaoka [Page 8] INTERNET DRAFT January 2004Certificate based Trust Relationship DefinitionCross-Certification is an issuing certificate to another CA.defined in terminology section 2.2 Requirement CAthat issues a cross-certificate MUST have a self-signed certificate. CAissued the cross-certificatealsoMUST have a self-signedcertificate. Advantagecertificate except for subordination model. If cross-certifying to the CA, issuer CA MUST require the responsibility for existing of the CA, like the subordination Shimaoka [Page 8] INTERNET DRAFT January 2004 model. Characteristics Cross-Certification is a stricter trust relationship than the trust list model, because the trust relationship isindicatedrepresented by a certificate and (authority) revocation list and is recorded to an audit log. Cross-certification is able to manage the trust relationship without changing the trust list of EEs. Because all subject CAs have a self-signed certificate, revoking across-certificate revocationcross- certificate does not alwayslink tomean also compromising the subjectCA compromise. Disadvantage CA MUST support cross-certification.CA. PKI SHOULD have a repository, e.g., a directory server to store a crossCertificatePair, and CA SHOULD generate a crossCertificatePair attribute. Considerations For path construction Becausea calculation method forthe key identifier of each CA MAYNOTbesame,calculated differently, subject CA SHOULD issue a cross-certification requestwhichthat contains subjectKeyIdentifier in extensionRequest,and itswith a value that MUST be identicalwithto the subjectKeyIdentifier in the self-signed certificate. Then, issuer CA SHOULD issue across- certificate which containscross-certificate with the subjectKeyIdentifier set to the same value in the corresponding cross-certification request. For PKI issuing Revocation List Issuer CA MAY issue Authority Revocation List (ARL), or SHOULDissue fullCRLatleast.least issue fullCRL. However, ARLincludingwith an issuingDistributionPoint extension MAY NOT be processed by some applications.When update the Cross-Certificate There3.2.1 Unilateral cross-certification Definition The model in which a CA issues a cross-certificate to another CA unilaterally. Characteristics This certification isno rule for whatusable like subordination, but is able todo whenestablish acertainmore flexible trust relationship than subordination; even if the cross-certificate isupdatedrevoked, subject CA MAY be able tomodify some contents, e.g., policy identifier, of cross-certificate.continue its operation. Shimaoka [Page 9] INTERNET DRAFT January 2004When issuer CA-X re-issues a cross-certificate to subject CA-Y beforeIf theissued cross-certificate is expired, CA-X MUST update its crossCertificatePair and MUST populate it toPKI use a directorysystem of CA-X, and CA-Y MUST update its crossCertificatePair corresponding tosystem, thecross-certificate andCA MUSTpopulategenerate a crossCertificatePair, even if it means unilaterally, todirectory system of CA-Y. Until done it, changeavoid being categorized as subordination. Considerations Subordination is a special case of unilateral cross-certification. Note that unilateral cross-certification is easily established without an agreement from the requested CA when a cross- certificationis not reflected completely to certification path. In addition, CA-X MUST revoke old cross-certificate to CA-Y when CA-X modifies some contents of the cross-certificate. When update CA keypair When CA issues a set of self-issued certificates for key rollover, to update cross-certificate is not required. When CA does not issue a set of self-issued certificates for key rollover, to update cross-certificate is required. Note that CA DN might not change without a set of self-issued certificates for key rollover when CA keypair are compromised. When compromise the keypair of subject CA When the keypair of subject CA-Y is compromised, issuer CA-X SHOULD revoke the cross-certificate for subject CA-Y, then CA-X MUST remove the crossCertificatePair attribute for the CA-Y from its repository. 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 use like subordination, and is able to establish more flexible trust relationship than subordination. Even if cross-certificate is revoked, subject CA MAY be able to continue its operation. Disadvantage for PKI using directory system CA SHOULD generate a crossCertificatePair, even though unilaterally. Shimaoka [Page 10] INTERNET DRAFT January 2004 Considerations Subordination is peculiar case of unilateral cross-certification. Note that unilateral cross-certification is established easily without agreement from requested CA when a cross-certificationrequest is stolen by other CA.for PKI using directory system When CA-X cross-certify CA-Y unilaterally, Both CA SHOULD operate their directory server as below. CA-X SHOULD generate a following crossCertificatePair and store it in own directory entry. issuedToThisCA := NULL issuedByThisCA := cross-certificate for CA-Y issued by CA-X CA-Y SHOULD generate a following crossCertificatePair and store it in own directory entry. issuedToThisCA := cross-certificate for CA-Y issued by CA-X issuedByThisCA := NULL+---------------+ +----------------------+ | Trusting | | Trusted | | PKI 1 | | PKI 2 | | | cross-certified | | | +-----+ | PKI 1 to PKI 2 | +-----+ | | | PCA |--------------------------->| PCA |<--+ | | +-----+ | | +-----+ | | | | | | ^ | | | | | | | v | | | | | | +----+ | | | | | | | CA |---+ | | | | | | +----+ | | | | | | | ^ | | | | v | | v | | | | | +----+ | | +----+ | | | | | | CA |---+ | | | CA |---+ | | | | +----+ | | | +----+ | | | | | | | | | | | | | | | | | | | | | | v v | | v v v | | +----+ +----+ | | +----+ +----+ +----+ | | | EE | | EE | | | | EE | | EE | | EE | | | +----+ +----+ | | +----+ +----+ +----+ | +---------------+ +----------------------+Shimaoka [Page 11] INTERNET DRAFT January 2004Figure 3 - Unilateral Cross-Certification 3.2.2 Mutual cross-certification Definition The model in which a CA issues a cross-certificate to anothertrustedCA mutually.Advantage TBD DisadvantageCharacteristics Both CAs cross-certify with each other mutually. Shimaoka [Page 10] INTERNET DRAFT January 2004 for PKI using directory system Both CAs MUST generate a crossCertificatePair thatis composedconsits ofathe cross-certificate it issued and the correspondingissued cross-certificate.cross- certificate that it was issued. When either CA updates across-certificate,cross- certificate, each CA MUST re-generate their crossCertificatePair synchronously. Considerations Both CAs MUSTagree aboutaccept upon more information in order to issue across- certificatecross-certificate (e.g., validity, keyUsage, andsomeconstraints) and MUST exchangeit. for PKI using directory system Each CAs MUST generate a crossCertificatePair that is composed by cross-certificate it issues and issued cross-certificate. CA-X SHOULD generate a following crossCertificatePair and store it in own directory entry. issuedToThisCA := cross-certificate for CA-X issued by CA-Y issuedByThisCA := cross-certificate for CA-Y issued by CA-X CA-Y SHOULD generate a following crossCertificatePair and store it in own directory entry. issuedToThisCA := cross-certificate for CA-Y issued by CA-X issuedByThisCA := cross-certificate for CA-X issued by CA-Y In mutual cross-certification model, each CA SHOULD NOT generate two crossCertificatePair individually, which Shimaoka [Page 12] INTERNET DRAFT January 2004 includes only one cross-certificate. Each CA SHOULD NOT generate two crossCertificatePair like a unilateral cross- certification model individually.the information. +---------------+ +----------------------+ | PKI 1 | | PKI 2 | | | cross-certified | | | +-----+ | PKI 1 and PKI 2 | +-----+ | | | PCA |<-------------------------->| PCA |<--+ | | +-----+ | | +-----+ | | | | | | ^ | | | | | | | v | | | | | | +----+ | | | | | | | CA |---+ | | | | | | +----+ | | | | | | | ^ | | | | v | | v | | | | | +----+ | | +----+ | | | | | | CA |---+ | | | CA |---+ | | | | +----+ | | | +----+ | | | | | | | | | | | | | | | | | | | | | | v v | | v v v | | +----+ +----+ | | +----+ +----+ +----+ | | | EE | | EE | | | | EE | | EE | | EE | | | +----+ +----+ | | +----+ +----+ +----+ | +---------------+ +----------------------+ Figure 4 - Mutual Cross-Certification 3.3 Subordination (Hierarchy) Subordination is apeculiarspecial unilateral cross-certification.DefinitionSubordination is to issue a certificateissuingto a CA that has noself-signedself- signed certificate.SubordinateDefinition Shimaoka [Page 11] INTERNET DRAFT January 2004 The model in which a PKI has always only one superior CA. Requirements A subordinate CA MUST have only one superiorCA. SubordinateCA and be managed by the superior CA strictly. A subordinate CA MUST never issue its self-signed certificate. Characteristics Subordination is different from unilateral cross-certification, in that this model MUST NOT allowthata subordinate CAisto be certified by more than one issuer CAs.Advantage SubordinateA subordinate CA MAY NOT require any accreditation,ratherrather, the accreditation is required only for the superior CA or the top CA.Shimaoka [Page 13] INTERNET DRAFT January 2004 SubordinateAn existence of the subordinate CA is dependent on the superior CA. A subordinate CA is able to inherit some policies and constraints from its superior CA. BecauseSubordinatea subordinate CA hasclearan explicit trust relationship with its superior CA, the subordinate CA is able to be trusted easily by all EEs who trust the superior CA.DisadvantageSubordinateCACAs MUST NOT cross-certifyany CAs,with another PKI domains, but MAY just allowsubordination.a subordination to the same PKI domain. When a subordinate CA certificate is revoked by a superior CA,alsoall certificates issued by thesubordinate CA MUST NOTsubordinate CA MUST NOT be trusted. Considerations A subordinate CA MUST NOT override the constraints given by the superior CA. Subordination MUST be used only in single-domain PKI, not multi-domain PKI. When a subordinate CA issues a self-signed certificate, the subordinate CA MUST need an agreement from its superior CA on issuing the certificate, because certificates issued by the subordinate CA will be not constrained by the superior CA. When the subordinate CA issues a self-signed certificate, the PKI changes from the subordination model into the unified domain model. 4 PKI Domain 4.1 Requirements for PKI domain PKIs in a PKI domain SHOULD share one or more certificate policy, and the PKI domain MUST have a principal CA. This shared policy is called the "domain policy". The domain policy SHOULD be described in the policyIdentifier of the certificate policies extension for each certificate. All CAs in a PKI domain MUST be operated under each CP/CPS that conform to the domain policy. All CAs in a PKI domain MUST be able Shimaoka [Page 12] INTERNET DRAFT January 2004 to issue a verifiable certificate by using the principal CA as the trust anchor. 4.2 Risk Analysis of non-interoperable PKI domain A PKI domain that satisfies the foregoing requirements MAY betrusted. Subordinate CA MUST NOT overrideused in thecertificate policy, whichmulti-trust point model. However, such requirements are insufficient for thesuperior CA allowed. Considerations Subordination MUSTsingle-trust point model. To use a PKI domain under the single-trust point model, more requirements are necessary. Therefore, such a PKI domain SHOULD NOT be used inSingle-domain PKI, not multi-domain PKI. When subordinate CA issuessingle-trust point model. If such aself-signed certificate, the subordinate CA MUST require agreement of its superior CA about issuingPKI domain makes thecertificate, because almost certificates issued bysingle-trust point model, thesubordinate CAfollowing problems will benot constrained byconsidered: - A lack of thesuperior CA.PKI Domain identification method for the third party All certificates in the PKIusing directory system Superior CA MUSTdomain MAY NOTstore a subordinate CA certificate to issuedByThisCA elementhave the identification information ofcrossCertificatePair attribute in own (superior CA) entry,the PKI domain. Distinguished Name cannot be used as the identity for the PKI domain, becausepath construction becomes non- efficiency. Subordinate CA MAY store own subordinate CA certificate to issuedToThisCA element of crossCertificatePair attribute in own (subordinate CA) entry. Subordinate CA MUST store own subordinate CA certificate to cACertificate attributeno one administers the name space. - Case inown entry. 4 PKI Domainwhich a PKI domain isa set of PKIs gathered upon some trust relationship. 4.1 Requirements fornot trusted by another PKI domainPKIs inWhen a relying party specifies aPKI domain MUST have more than one sharedcertificate policyand more thanas oneprincipal CA. This sharedof the validation parameters, the certification path validation MAY fail, because the policy of the relying party isnamed as "domain policy". All CAs inincapable of mapping to an appropriate certificate policy. If a PKI domainMUST be operated by each CP/CPS which is conformedinterconnects to another PKI domain, In addition to thedomain policy. There SHOULD be more than one principal CA that issued self-signed certificateabove requirements in section 4.1, the following consideration is necessary. - Conflict of a name space The name constraints extension MAY not perform the constraint that PKIdomain. All CAs inintended, if no one manages aPKI domain MUST be able to issuename space. - Policy management When validating averifiable certificate by usingcertification path crossing theprincipal CA as trust anchor.PKI domains, relying party MAY identify the PKI domains by referring the certificate policies extensions. If the domainMUST publishpolicy is not described in the certificate policies extension, the path validation MAY fail. Especially thetrust information below todomainEEs securely.policy is necessary in the path validation through the PKI that use some constraints or policy mapping. Shimaoka [Page14]13] INTERNET DRAFT January 2004 -PrincipalAuthority constrained A CAcertificate and its fingerprint - CP/CPSthat wants to constrain something for the certification path MUST include explicitly the extensions forPrincipalthe constraints in the certificates that the CA- Obtaining method of revocation information 4.2 Risk Analysis of non interoperable PKI domain A PKI domainissues, since thatsatisfiesa CA assumes theforegoing requirements MAY bevalidation policy used by a relying party is difficult. For example; Alice inmulti-trust point model. But such requirements arePKI domain A: She does notsufficient for single-trust point model. To usespecify an user-initial- policy-set. Bob in PKI domain B: PKI domain B assumes specifying a certain certificate policy (cP-B.1) insingle-trust point model, more requirement is necessary. However, suchthe user-intial-policy-set to a relying party. A certificate issued in PKI domain B does not include the policyConstraints extension. Bob's certificate includes cP-B.1 in the policyIdentifier of the certificate policies extension. PKI domainSHOULD NOT be usedB assumes specifying a certain certificate policy insingle-trust point model. If suchthe user-intial-policy-set to a relying party. a certificate issued in PKI domainmakesB does not include thesingle-trust point model,policyConstraints extension. Bob's certificate includes cP- B.1 in thefollowing problem will be considered. - LackpolicyIdentifier of the certificate policies extension. PKIDomain identification method fordomain B assumes no using cP-B.1 outside thethird party All certificates inPKI domain B. Alice can validate successfully the certification path to Bob without user-initial-policy-set. It is different from a result to expect of PKI domainMAY NOTB. Domain B has to specify explicit-policy on the certificate to havean identification information foryou inspect it according to the expectation of PKIdomain. Distinguished Name cannot use asdomain B. to make a result according to theidentity forexpectation of the PKIdomain, because nobody administersdomain B, PKI domain B MUST use thename space. - CaserequireExplicitPolicy in the policy constraints extension ofthata certificate that PKI domain B issues. Alice can succeed the certification path to Bob with no specified user-initial-policy-set. It isnot trusted by anotherdifferent from a result to expect of PKI domainWhen a relying party specifies aB. Domain B has to specify explicit-policy on the certificatepolicy as oneto have you inspect it according to the expectation of PKI domain B. To make a result according to thevalidation parameters,expectation of thecertification path validation will fail becausePKI domain B, PKI domain B MUST use the requireExplicitPolicy in the policy constraints extension ofthe relying party cannot map to an appropriatea certificatepolicy.that PKI domain B issues. 4.3 Requirements for multi-domain PKI interoperabilityTo achieve moreIn multi-domain PKI, there MAY be a PKIinteroperability,domain that assumes requiring the explicit policy. To validate correctly such certification path, the following requirements are necessary forPKI domain. - PKI domain MUST have the policyId ofthedomain policy for mapping to otherPKIdomain. * policyId MUST be unique with a domain policy. * policyId MUST NOT be any-policy.domains: Shimaoka [Page 14] INTERNET DRAFT January 2004 - All CAs in a PKI domainMUSTthat has explicit domain policy as policyIdentifier SHOULD be able to issue averifiablecertificateby usingwhich is verifiable with the following validationparameters.policy: * user-initial-policy-set which includes its own domainPolicyId. * initial-explicit-policyasset to TRUE. * trust anchor which is the principal CAcertificateofthe ownits PKI domain. - Each PKI domain SHOULDpublishshow the trust relationship with other PKIdomain. Shimaoka [Page 15] INTERNET DRAFT January 2004domains as follows: * Trusted PKI domain SHOULD show to the trusting PKI domainMUST publishwhat kind of PKI it includes. * Trusted PKI domain SHOULDpublishshow to trusting PKI domain what kind of other PKIdomaindomains it trusts. * Trusted PKI domain MAY publish to the trusting PKI domain what kind of other PKIdomaindomains it is trusted by. In addition, the following requirements MAY be necessarydepending onfor the certificate based trustrelationship with other PKI domain. (1) Single-trust point modelrelationship. SHOULD give an appropriate policy mapping between the trusting PKI domain andathe trusted PKI domainto cross-certification. (2) Multi-trust point model SHOULD give an appropriate validation parameters conforming to domain policy to relying party. - Appropriate (it may be newest) trust anchorfor certificate* MAY be principal CA of subscriber PKI domain - Appropriate acceptable policy * MAY be domain policy of subscriber PKI domain * MUST NOT be any-policy - Appropriate other validation parameters if necessarybased trust relationship. 5 Single-domain PKI This section describes appropriate PKI architecturesto establishfor establishing a single PKI domain. All PKIs that are going to participate inmulti- domainmulti-domain PKI SHOULD adopt anymodelsof the following models formulti-domainmulti- domain PKI interoperability. 5.1 Single PKI model This is the simplest PKI model. All PKI models are composed of this. Definition Single PKIis composedconsists ofan onlya single self-signed CA and its EEs. All EEs SHOULD trust only the CA. All subscribers MUST be issued theircertificatecertificates byonly the CA. Principal CA Principal CA MUST bethesingleonly CA.Shimaoka [Page 16] INTERNET DRAFT January 2004Trust anchorTrustThe trust anchor MUST be the single self-signed CA. +----+ +---| CA |---+ | +----+ | Shimaoka [Page 15] INTERNET DRAFT January 2004 | | | | | | v v v +----+ +----+ +----+ | EE | | EE | | EE | +----+ +----+ +----+ Figure 5 - Single PKI model 5.2 Hierarchy PKI model This is a typical architecture of PKI. Definition Hierarchy PKIis composedconsits ofan onlya single top CA, some subordinateCAsCAs, and EEs. Onlyathe 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 onlyathe top CA. +---------+ +---| top CA |---+ | +---------+ | | | | | v v +----+ +----+ +-----| CA | +-----| CA |------+ | +----+ | +----+ | | | | v v v +----+ +----+ +----+Shimaoka [Page 17] INTERNET DRAFT January 2004+--| CA |-----+ | CA |-+ +---| CA |---+ | +----+ | +----+ | | +----+ | | | | | | | | | | | | | | | | | v v v v v v v v +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ | EE | | EE | | EE | | EE | | EE | | EE | | EE | | EE | +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ Figure 6 - Hierarchy PKI model Shimaoka [Page 16] INTERNET DRAFT January 2004 5.3 Mesh PKI model Definition Mesh PKIis composedconsists ofpluralmultiple CAs and their EEs. All CAs MUST cross-certify more than one CA unilaterally,andor MUST be cross- certified by more than one CA unilaterally. Some CAs MAY cross- certify mutually.In Internet PKI, there is no standard to propose this model. Principal CA Principal CA SHOULD be unique in the PKI domain.Trust anchorTrustThe trust anchor for a relying party SHOULD be a CAwhich issued a certificate to them. Considerations All EEs MUST trust only a CA thatwho issuedtheir ownit a certificate.DetermineConsiderations A trust anchor SHOULD be self-signed CA by some reason on the operation. For example, aprincipalself-signed CAfor foreign PKI domain.is verifiable about the binding of the private key and the public key by itself. This model SHOULDNOTbedesigned intentionally, butavoided as possible, because it may be complex to the certification path building. However, do not assume that there is not this model. Full Mesh PKI MAY beformeduseful conversely forsome reason.the certification path building, because it is able to reach certainly to the trusting PKI domain with one path. cross certified +-------+ cross certified +---------------->| CA |<----------------+ | +-------+ | | | | | | | | | | v v | | +----+ +----+ | | | EE | | EE | | | +----+ +----+ | v vShimaoka [Page 18] INTERNET DRAFT January 2004+------+ +------+ | CA |<--------------------------------->| CA |-----+ +------+ cross certified +------+ | | | | | | | | | | | v v v v v +----+ +----+ +----+ +----+ +----+ | EE | | EE | | EE | | EE | | EE | +----+ +----+ +----+ +----+ +----+ Figure 7 - Mesh PKI model Shimaoka [Page 17] INTERNET DRAFT January 2004 6 multi-domain PKIMulti-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. To achieve interoperability, all PKIsthat composein a multi-domain PKI SHOULD apply the following models. ConsiderationsRequired allMulti-domain PKI MAY need policy mapping or constraints to maintain each domain policy. All required information for path validation MUST be able to be obtained through the Internet. - Intermediate certificate - Target certificate (optional) - Revocation information for all certificates For this,CACAs MAY operate a repository, and SHOULD include authorityInfoAccess or cRLDistributionPoints extensions in the certificatesit issues.they issue. 6.1 Multi Trust point model (based on Trust List) The model in which a relying party trustspluralmultiple PKI domains by a trust list.Relying party is able to use trust list for specifying the trust point in other PKI domains. Trust list MUST be more than one principalConsiderations A CAcertificate, as a trust point, of other PKI domain, and SHOULD have individually appropriate validation parameters including acceptable policy for each trust point. CAsina trust list SHOULD not cross-certify each other. Considerations The format of trust list, which SHOULD be more than one pair of a trust point andthecorresponded validation parameters, has no standard. The format of trust list has no standard. The list MUST Shimaoka [Page 19] INTERNET DRAFT January 2004 be more than one trusted CA (self-signed) certificate as trust point, whichexisting certification path SHOULDinclude validation parameters for eachNOT be added to the trustpoint. Actual mostlist, since a constraint in the certification path MAY not be evaluated correctly. Most of the actual public PKIs establishona multi-trust point model without a domain policy. When using such public PKI,user- initial-policy-setuser-initial- policy-set SHOULD NOT be specified, andinitial-explicit- policyinitial-explicit-policy SHOULD NOT be true.Generally,In general, sincethatit is difficult for the EEchecksto check if arevocation ofCA's self-signed certificateis difficult,has been revoked, a CA SHOULD announce it to allEEEEs when the CA is compromised. In the multi-trustlist model, each CA SHOULD announce it to all EEs in not its PKI domain but all trusted PKI domain. 6.1.1 Based on User Trust List Considerations This is an easier and typical method for making a trust relationship to other PKI domain. Relying Party is able to establish trust relationship with other PKI domain irresponsibly to his trust anchor. Relying party MUST notice whether each CA certificates as trustpointupdated or are revoked. Relying party MAY need 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. 6.1.2 Based on Authority Trust List Since there is no standard or established method, this memo does not recommend using this model in multi-domain PKI. 6.2 Single Trust Point model (based on Cross-Certification) The model in which all PKI domains related by Cross-Certification. In thismodel, atrust point is just a trust anchor. Therefore, certification path always start fromcompromised trust anchorof relying party. Considerations Each PKI domain SHOULD use policy mapping for acrossing different PKI domains. In addition, cross-certificateSHOULDset zero to requireExplicitPolicy inbe removed from thepolicyConstraints extension,trust list, andMAY set any value to inhibitPolicyMappings in the policyConstraints extension. IfthePKI domain does not use policy mapping, it MAY seem same PKI domain. All certification path MUSTremoving SHOULD bestarted fromperformed by the subject of managing theonlytrustanchor, then validation parameters MAY be an only set.list. 6.1.1 Based on User Trust List Considerations Shimaoka [Page20]18] INTERNET DRAFT January 2004Cross-Certificate SHOULD use authorityKeyIdentifier extensionThis is an easier andsubjectKeyIdentifier extensiontypical method forpath construction. 6.2.1 Peer-to-Peermaking a trust relationship to another PKI domain. The relying party MUST understand a certificate status of the trust anchor in the trust list. 6.1.2 Based on Authority Trust List Since there is no standard or established method, this memo does not recommend using this model in multi-domain PKI. 6.2 Single Trust Point model (based on Cross-Certification) The model in whichtwo peerall PKI domainstrust each otherare related by Cross- Certification. Thistrust relationship SHOULD be established bycross-certification is either mutualCross-Certification,orMAY be established by unilateral Cross-certification.unilateral. InCross-Certificationthis model,because trust-anchora trust anchor isanonlyone,one. 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 validationparameterspolicy of the relying party, but SHOULDbe authority-constrained things.include the constraints in the certificate explicitly. For example, when each PKI domain wants to effect always 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 can not effect the constraints always. 6.2.2 Unified Domain model (based on unilateral Cross-Certification) The model in whichpluralmultiple PKI domains have a joint superior CA that issues cross-certificates to each PKI domain unilaterally. Such a joint superior CA is defined as unificate CA.Each PKI domain MUST have more than one shared certificate policy at least.This modellooks likeis asubordination model, exceptmethod to unify or fake the multiple PKI domains to one PKI domain, or is a method for transforming from subordinaion. Except for that there is a self-signed certificate as the intermediateCA hascertificate, this model looks like aself-signed certificate.subordination model. Therefore, often this model is used like the hierarchy model in multi-domain PKI. cross-certified cross-certified Unificate CA to PKI 1 +--------------+ Unificate CA to PKI 3 +---------| Unificate CA |---+ | +--------------+ | | | | | cross-certified| | Shimaoka [Page 19] INTERNET DRAFT January 2004 | Unificate CA | | | to PKI 2 | | +-----------|---+ +-----------|---+ +----|-----------------+ | PKI 1 | | | PKI 2 | | | | PKI 3 | | v | | v | | v | | +-----+ | | +-----+ | | +-----+ | | +---| PCA | | | | PCA | | | | PCA |<--+ | | | +-----+ | | +-----+ | | +-----+ | | | | | | | | | | ^ | | | | | | | | | | | v | | | | | | | | | | +----+ | | | | | | | | | | | CA |---+ | | | | | | | | | | +----+ | | | | | | | | | | | ^ | | | | | | | | v | | v | | | | | | | | | +----+ | | +----+ | | | | | | | | | +---| CA | | | | CA |---+ | | | | | | | | | +----+ | | +----+ | | |Shimaoka [Page 21] INTERNET DRAFT January 2004| | | | | | | | | | | | | | | | | | | | | | | | | | | v v | | v v | | v v v | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ | | | EE | | EE | | | | EE | | EE | | | | EE | | EE | | EE | | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ | +---------------+ +---------------+ +----------------------+ Figure 8 - Unified Domain model 6.2.3Hub model (a.k.aBridgeCA)model The model in which every PKIdomainsdomain trust each other through a Bridge CA by Cross-Certification. In this model, trust relationship is not established between a subscriber domain and a relying party domain directly, but established through the Bridge CA. This is usefulto reducein reducing thecomplexitynumber of cross-certification. Requirements forHubBridge model - Bridge CA MUST NOT be used as the trust anchor in any PKI domain. - Bridge CAMUSTSHOULD issuecross-certificatecross-certificates with other PKIdomain mutually. - Bridge CA SHOULD issue ARL and CRL,domains mutually or MAY issuefullCRL.it unilaterally. - Bridge CA MUST NOT issue EEcertificate exceptingcertificates except when it is necessaryonefor theCACA's operation.And at least, the EE certificate MUST be constrained to fail in the path validation from other PKI domain.- Bridge CA MUST use its own domain policy in the policy mapping between a trusting PKI domain and a trusted PKI domain. - The domain policy of Bridge CA MUST be a subset of the trusting PKI domain policy that is mapped. - The domain policy of Bridge CA MUST be a superset of the trusted Shimaoka [Page 20] INTERNET DRAFT January 2004 PKI domain policy that is mapped. Cross-Certificate from Trusting PKI domain to Bridge CA issuerDomainPolicy := Trusting PKI domain policy subjectDomainPolicy := Bridge CA domain policy Cross-Certificate from Bridge CA to Trusted PKI domain issuerDomainPolicy := Bridge CA domain policy subjectDomainPolicy := Trusted PKI domain policy -Cross-CertificateCross-Certificates issued by Bridge CA and Cross-Certificate issued to Bridge CA SHOULD include the requireExplicitPolicymorewith a value that is greater thanequalzero in the policyConstaints extension. -To trustCross-certificate issued to Bridge CA SHOULD include the requireExplicitPolicy with atrusted PKI domain, trusting PKI domain MUST do via BCA.value that is greater than zero in the policyConstratints extension. - Cross-certificate issued by Bridge CA SHOULD NOT include any constraints to keep its transparency. - PKIdomaindomains cross-certified with Bridge CA SHOULD NOT cross- certify directly to other PKIdomaindomains cross-certified with the same Bridge CA. - Bridge CA SHOULD clarify the method for the policy mapping ofcross-certification.cross-certification to keep its transparency. ConsiderationsShimaoka [Page 22] INTERNET DRAFT January 2004The Bridge CA SHOULD be operated by neutral trusted third party. The Bridge CA SHOULD do policymapping appropriately with both PKI domains. Both PKI domainsmapping appropriately with both PKI domains. For using the name constraints, 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 Bridge CA SHOULD confirm the following: - Does the trusted third CA perform the policy mapping via its own domain policy? - Does the trusted third CA clarify the method of policy mapping in cross-certification? - Is the trusted third CA able to accept the domain policy thatcross-certifies with Bridge CA SHOULD NOT use nameConstraints extension because they cannot limit name-spaces via Bridge CA. Bridge CA MUST have an independent certificatethe trusting PKI domain desires? * If the domain policyfrom bothis mapped to one with a lower security level, the trusting PKIdomain, anddomain MUSTuse it for policy mapping.NOT accept it. cross-certified cross-certified PKI 1 with BCA +-----------+ PKI3 with BCA +------->| Bridge CA |<------+ | +-----------+ | Shimaoka [Page 21] INTERNET DRAFT January 2004 | ^ | | 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 9 -HubBridge model6.2.47 Operational Considerations This chapter explains the point that you should pay attention to about management of a mutual certification certificate and use of a directory. 7.1 Directory (1) Unilateral cross-certification When CA-X cross-certifies CA-Y unilaterally, both CAs SHOULD operate their directory server in the following way. CA-X SHOULD generate a following crossCertificatePair and store it in its own directory entry. issuedToThisCA := NULL Shimaoka [Page 22] INTERNET DRAFT January 2004 issuedByThisCA := cross-certificate for CA-Y issued by CA-X CA-Y MAY generate a following crossCertificatePair and store it in its own directory entry. issuedToThisCA := cross-certificate for CA-Y issued by CA-X issuedByThisCA := NULL (2) Mutual cross-certification Each CA MUST generate a crossCertificatePair that consists of the cross-certificate it issues and the cross-certificate it is issued. CA-X SHOULD generate the following crossCertificatePair and store it in its own directory entry: issuedToThisCA := cross-certificate for CA-X issued by CA-Y issuedByThisCA := cross-certificate for CA-Y issued by CA-X CA-Y SHOULD generate the following crossCertificatePair and store it in its own directory entry: issuedToThisCA := cross-certificate for CA-Y issued by CA-X issuedByThisCA := cross-certificate for CA-X issued by CA-Y In the mutual cross-certification model, each CA SHOULD NOT individually generate two crossCertificatePairs each containing only one cross-certificate, similar to the unilateral cross-certification model. (3) Subordination A superior CA MAY store a subordinate CA certificate to issuedByThisCA element of crossCertificatePair attribute in its own entry fortrusted thirdthe reverse path building. However, it SHOULD be only for compatibility with the reverse path building, since a path building for subordination SHOULD be the forward direction. A superior CAThis clause considersSHOULD NOT store a subordinate CA certificate in its own entry for thecase of that trust relationship is not established between subscriber domain and relying party domain directly, but established via trusted thirdforward path building. A subordinate CA(e.g., BridgeMAY store its own subordinate CA certificate to the issuedToThisCA element of the crossCertificatePair attribute inHub model, and Unificateits own (subordinate CA) entry for the forward path building. A subordinate CA MUST store its own subordinate CA certificate to the cACertificate attribute inUnified domain model).its own entry. 7.2 Cross-Certification Shimaoka [Page 23] INTERNET DRAFT January 2004(1) Advantage of using trusted third CA - Via trusted third CA, trusting PKI domain can automatically deploy trusted PKI domains that have mappable domain policy. - Trusting PKI domain can open its security level of own domain policy by certifying with trusted third CA. * This means that the trusting PKI domain passedWhen updating thecriteriaCross-Certificate There is no rule forthe cross-certificationwhat to do when a certain cross-certificate is updated to modify some contents, e.g., policy identifier of thetrusted third CA. * This means thatcross-certificate. When issuer CA-X re-issues a cross-certificate to subject CA-Y before thetrusting PKI domain has no riskissued cross-certificate expires, both CA-X and CA-Y MUST each update their own crossCertificatePair corresponding to the cross-certificate, and MUST populate it to their own directory system. Until this is done, change ofmismapping with other PKI domain whichcross- certification islower security level. - PKI domain can suggestnot reflected completely to certification path. In addition, CA-X MUST revoke thecross-certification with trusted third CA as indexold cross-certificate tobe trusted from other PKI domains. - WhatCA-Y when CA-X does not intend to enable the old cross-certificate either. When updating the CAcross-certifies with trusted thirdkeypair When a CAsuggests that such CAs are able to be trusted by third PKI domain. (2) Confirmationissues a set of self-issued certificates fortrustingkey rollover, update of thetrusted thirdcross-certificate is not required. However, when a CA- Doesdoes not issue a set of self-issued certificates for key rollover, update of thetrusted thirdcross-certificate is required. When a CAdo the policy mapping via own domain policy? - Doeskeypair is compromised, thetrusted thirdCAclear the method of policy mapping in cross-certification? - IsDN SHOULD NOT be re- used by thetrusted thirdsame CAable to acceptwithout issuing thedomain policy thatself-issued certificate. When thetrusting PKI domain desired? * Ifkeypair of subject CA is compromised When thedomain policykeypair of subject CA-Y ismapped to lower security level, trusting domain MUST NOT accept it. * Trusting PKI domaincompromised, issuer CA-X SHOULDrequest sufficient policy controlrevoke the cross-certificate for subject CA-Y, then CA-X MUST remove the crossCertificatePair attribute formaintainingCA-Y from itssecurity level. (3) Considerations If trusted third CA cannot keep neutrality, trusting domain will cross-certify with PKI domain that is lower security level. 7repository. 8 Security Considerations7.18.1 Certificate and CRL Profile Defining the concrete Certificate and CRL profile for multi-domain PKI interoperability is not within the scope of this memo. AllCertificateCertificates andCRLCRLs MUST comply with [RFC 3280]. In addition,CACAs in multi-domain PKI SHOULD consideraboutthe following for the Certificate and CRLprofile.profile: * The extensions foronlyprocessing only in local PKI domainMUSTSHOULD be non-critical. * The cRLDistributionPoint extension SHOULD be used for obtainingtheShimaoka [Page 24] INTERNET DRAFT January 2004 the revocation list. distributionPoint field SHOULDpreferinclude also the UniformResourceIdentifier. When the CRL is separatedtointo CARL and EPRL, the issuingDistributionPoint extensionalsoSHOULD also be used. * The Authority Key Identifier extension and Subject Key Identifier extension SHOULD be used foraiding aassisting in path construction. * The policyIdentifier field of the Certificate Policies extension SHOULD be used for identifying each policy domain. * The Policy Mapping extension MAY be used forpolicy mapping in single-trust point model.the validating that mutual domain policies are equivalent. * The Name Constraints extension MAY NOT be used for multi-domain PKI because the name space of multi-domain PKI is not managed by anyone.* Policy Constraints extension MAY be used for path validation of foreign PKI domain. 7.2 Repository Relying party MUST obtain all required information for path construction and validation.Ifnecessary, CA issuesacertificate including Authority Information Access extension or CRL Distribution Points extension for aidingPKI domain use the name constraints inthat a relying party doesmulti-domain PKI, thepath construction. 7.3PKI domain SHOULD pay attention to preventing a conflict of each name space. 8.2 Path Validation Validation parameters used for path validationSHOULD beis the intersectionbetweenof authority-constrained parameters and user-constrained parameters.Therefore, CAs SHOULD design an validation parameters so that it is divided as user-constrainted parameters and authority-An authority constrainedparameters. Non certificate holders MUST determine carefully their validation parameters including the trust anchor. 7.4 Public PKI and Private PKI Public PKI is more important for interoperability since many certificates are issued and distributed already. Public PKI MUST keep interoperability with existing certification path, and alot of current paths still have no domain policy. Therefore, relying party using such Public PKI SHOULD NOT specify user-initial-policy-set and initial-explicit-policy. Any certificates in Public PKIparameter SHOULD NOTbe designed assuming processing such certificate policies, policy mapping, or policyConstraints extension. In fact, some CA softwares Shimaoka [Page 25] INTERNET DRAFT January 2004 cannot issue a certificate including such extensions. Private PKI has less impact to re-issue the certificates than Public PKI since the deployments are limited. Onrely on theother hand, Private PKI may require more strict pathvalidationbecause it may be used for more critical transaction. Whenpolicy of acertificate is used to both and has certificate policies extension, the extensionrelying party, but SHOULD benon-critical. Relying party usingincluded in thecertificate as Private PKI MAY specify user- initial-policy-set and initial-require-policy, but relyingcertificates explicitly. A Relying partyusing it as Public PKI SHOULD NOT specify them. 7.5MUST carefully determine their validation parameters, including the trust anchor. 8.3 Asymmetric problem7.5.18.3.1 Hybrid trust model This clause considersathe caseof thatin which PKI domains trust each other by a different trust relationship.Trust relationship for inter-domain doesInter-domain trust relationships do not have to be symmetric.As actual model, there isThe hybrid trustmodel likemodel, similar to the user trust list model and the unilateral cross-certificationmodel.model, serves as an actual model for such trust relationships. Since inter-domain trust relationshipsfor inter-domainin this document are defined as directional trustrelationship,relationships, there is no additional requirement for such amodelmodel. What each PKIdomains dodomain does is merely the same as symmetric trust relationship. For example, inathe case that PKI domain-X trusts PKI domain-Y by the Shimaoka [Page 25] INTERNET DRAFT January 2004 user trust list model and PKIdomain- Ydomain-Y trusts PKI domain-X by unilateral cross-certification, PKI domain-Xhasmerely has to comply with the user trust listmodelmodel, and PKI domain-Yhas merely to complywith the unilateral cross-certification model.7.5.28.3.2 Asymmetric policy mapping This clause considersathe caseof that resultwhere results of the policy mapping in mutual cross-certification model is asymmetric. +-------+ cP-1.1 := cP-2.1 +-------+ | |------------------->| | | PCA 1 | | PCA 2 | | |<-------------------| | +-------+ cP-2.1 := cP-1.2 +-------+ Figure 10 - Asymmetric policy mapping When path building allowsa loop ofthe certificationpath,path to loop, then cP-1.1 is mapped tocP-1.2cP-1.2, and such a policy mapping MAY derive an unforeseen security holeofin the certification path.e.g.,E.g., CA-X that cross-certified to PCA-1 with cP-1.1 MAY be able to grow its certification path to another PKI domain via PCA-1 by cP-1.2. Since different policy identifiers managed by same PKImeanactually describes differentShimaoka [Page 26] INTERNET DRAFT January 2004policies,what differentdiffering policy identifiersaremapped unexpectedly in the same entityisrepresents anessentialcritical security issue. To prevent such a security hole, a loop certification path,whatone where the same DN appears twice and non-continuously on one certification path MUST NOT be allowed.89 References8.19.1 Normative 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. [RFC 2256] Wahl, M., "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, Dec 1997. [ISO-X509] ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information Technology - Open Systems Interconnection: The Directory: Authentication Framework," 2001 edition.8.29.2 Informative References Housley, R. and Polk, W., JOHN WILEY & SONS, INC., "Planning for PKI", Shimaoka [Page 26] INTERNET DRAFT January 2004 Aug 2001. Lloyd, S., PKI Forum, "PKI Interoperability Framework", March 2001. Lloyd, S., PKI Forum, "CA-CA Interoperability", March 2001. Shimaoka, M., Japan Network Security Association, and ISEC, Information Technology Promotion Agency, Japan, "Interoperability Issues for multi PKI domain", Jul 2002. Japan Network Security Association, ISEC, Information Technology Promotion Agency, Japan, "Implementation Problems on PKI", Feb 2003. Japan PKI Forum, Korea PKI Forum, PKI Forum Singapore, Chinese Taipei PKI Forum, "Achieving PKI Interoperability 2003", Jul 2003. Japan PKI Forum, Korea PKI Forum, PKI Forum Singapore, "Achieving PKI Interoperability", Apr 2002. Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S. and Nicholas, R., "Internet X.509 Public Key Infrastructure: Certification Path Building", Work in Progress, Oct 2003.Shimaoka [Page 27] INTERNET DRAFT January 2004 910 Acknowledgements This document is based on some valuable documents and many experiences with PKI interoperability experiments. The authors gratefully acknowledge the contributions of members of various multi- domain PKI interoperability experiments, in particular: Kenji Nakada, Kiyoshi Watanabe, Sang Hwan Park, Ryu Inada, Hiroyuki Yoshida and Yasushi Matsumoto. The author are also grateful to members of the Internet Engineering Task Force (IETF) Public Key Infrastructure working group (PKIX), and the Technical Working Group in Interoperability Working Group, which is consisted of Japan PKI Forum, Korea PKI Forum, Singapore PKI Forum and Chinese Taipei PKI Forum (JKST-IWG) for ideas and useful discussions which helped us in this effort. This work is aided by Information-technology Promotion Agency Information-technology Security Center (IPA/ISEC) and Japan Network Security Association (JNSA).1011 Author's Address Masaki SHIMAOKA SECOM Trust.net Co., Ltd. SECOM SC Center, 8-10-16, Shimorenjaku Shimaoka [Page 27] INTERNET DRAFT January 2004 Mitaka, Tokyo JAPAN Email: shimaoka@secom.ne.jp1112 Full Copyright Statement"CopyrightCopyright (C) The Internet Society(2004). All Rights Reserved.(year). This documentand translations of it may be copied and furnishedis subject toothers, 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 thattheabove copyright notice and this paragraph are included on all such copiesrights, licenses andderivative works. However, this document itself may not be modifiedrestrictions contained inany way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations,BCP 78, and except asneeded 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. Shimaoka [Page 28] INTERNET DRAFT January 2004 The limited permissions granted above are perpetual and will not be revoked byset forth therein, theInternet Society or its successors or assigns.authors retain all their rights. This document and the information contained hereinisare 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 FORCEDISCLAIMSDISCLAIM 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 [Page29]28] ----