view Side-By-Side changes
Network Working Group M.SHIMAOKAShimaoka Request for Comments: DRAFTJapan PKI Forum JuneSECOM Trust.net <draft-shimaoka-multidomain-pki-01.txt> October 2003 Memorandum for multi-domainPKIPublic Key Infrastructure (PKI) Interoperabilitydraft-shimaoka-multidomain-pki-00.txtStatus 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).(2003). 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 betweenCAs.Certification Authorities (CAs). Typical and primitive PKI models are specified as single-domain PKI.Multi-domainMulti- domain PKI established by pluralsingle-domsinsingle-domain 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 oncross- certification.cross-certification. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2 Requirements and Assumptions . . . . . . . . . . . . . . . . .23 2.1 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.3 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3 Trust Relationship . . . . . . . . . . . . . . . . . . . . . . .35 3.1 Trust List . . . . . . . . . . . . . . . . . . . . . . . . . .35 3.1.1 User Trust List . . . . . . . . . . . . . . . . . . . . . . .56 3.1.2 Authority Trust List . . . . . . . . . . . . . . . . . . . .57 3.2 Cross-Certification . . . . . . . . . . . . . . . . . . . . . .67 3.2.1 Unilateral Cross-Certification . . . . . . . . . . . . . . .68 3.2.2 Mutual Cross-Certification . . . . . . . . . . . . . . . . .710 3.3 Subordination (Hierarchy) . . . . . . . . . . . . . . . . . . .812 4Single-domainPKI Domain . . . . . . . . . . . . . . . . . . . . . . . .9. . . 13 SHIMAOKA [Page 1] INTERNET DRAFT October 2003 4.1SingleRequirements for PKI domain . . . . . . . . . . . . . . . . . . 13 4.2 Risk Analysis of non interoperable PKI domain . . . . . .9 4.2 Hierarchy. . . 13 4.3 Requirements for multi-domain PKI interoperability . . . . . . 14 5 Single-domain PKI . . . . . . . . . . . . . . . . . . .9 4.3 Mesh. . . . . 15 5.1 Single PKI model . . . . . . . . . . . . . . . . . . . . . . . 15 5.2 Hierarchy PKI model . . . .9 SHIMAOKA [Page 1] INTERNET DRAFT June 2003 5. . . . . . . . . . . . . . . . . . 16 5.3 Mesh PKI model . . . . . . . . . . . . . . . . . . . . . . . . 17 6 multi-domain PKI . . . . . . . . . . . . . . . . . . . . . . . .10 5.118 6.1 Multi Trust point model (based on Trust List) . . . . . . . . .10 5.1.118 6.1.1 Based on User Trust List . . . . . . . . . . . . . . . . .11 5.1.218 6.1.2 Based on Authority Trust List . . . . . . . . . . . . . . . .11 5.219 6.2 Single Trust Point model (based on Cross-Certification) . . . .11 5.2.119 6.2.1 Peer-to-Peer model (based on Cross-Certification) . . . . . .12 5.2.219 6.2.2 Super Domain model (based on unilateral Cross-Certification).12 5.2.319 6.2.3 Hub model (a.k.a Bridge CA) . . . . . . . . . . . . . . . . .12 620 6.2.4 Considerations for trusted third CA . . . . . . . . . . . . . 22 7 Security Considerations . . . . . . . . . . . . . . . . . . . .12 6.123 7.1 Certificate and CRL Profile . . . . . . . . . . . . . . . . . .12 6.223 7.2 Repository . . . . . . . . . . . . . . . . . . . . . . . .12 6.323 7.3 Path Validation . . . . . . . . . . . . . . . . . . . . . . . .12 7 References24 7.4 Asymmetric problem . . . . . . . . . . . . . . . . . . . . . . 24 7.4.1 Hybrid trust model . . . . .13 8 Acknowledgements. . . . . . . . . . . . . . . . 24 7.4.2 Asymmetric policy mapping . . . . . . . .13 9 Author's Address. . . . . . . . . . 24 8 References . . . . . . . . . . . . . .13 10 Full Copyright Statement. . . . . . . . . . . . . 24 8.1 Normative References . . . . . . .13. . . . . . . . . . . . . . 24 8.2 Informative References . . . . . . . . . . . . . . . . . . . . 25 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 25 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 11 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 25 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 atrust-relationshiptrust relationship with another CA, the CA MUST compare the policy of each CAs carefully because various CAs have various policy. So, establishment method for everytrust-relationshiptrust relationship MAY differ by the result of comparison. To establish appropriatetrust-trust relationship, fully understanding about a relationship between such establishment method and comparison is required. In addition, alltrust-relationshipstrust 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- SHIMAOKA [Page 2] INTERNET DRAFT October 2003 domain PKI. Section 3 categorizes the trust relationships between CAs as Trust List, Cross-Certification, andHierarchy.Subordination. 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-domainsuper domain model and hub model. Finally, section 6 describes considerations focused oncertificateCertificate andCRLCertificate Revocation List (CRL) profiles, Repository, 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 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 Abbreviations PKI: Public Key Infrastructure PKI based on X.509 is a set of CA and EE in a narrow sense. But in a wide sense, PKI sometime means a PKI domain itself. CA: Certification Authority EE: End Entity CRL: Certificate Revocation List ARL: Authority Revocation List SHIMAOKA [Page 3] INTERNET DRAFT October 2003 2.2 Terminology Subscriber Holder of the certificate which is verified. Relying Party Entity who verifies the certificate. At least, relying party MUST have one set of a trust anchor and an acceptable certificate policy. In Single domain PKI, these MAY be omitted tacitly. 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 domainAPKI domain is a set ofPKIs, which gathersPKIs gathered upona certainsome trustrelationship, andrelationship. They MUSTshare a certain policy, at least one.have more than one common policy and more than one principal CA. This common policy is named as "domain policy". Essentially, PKI domain is only a view fromrelying-partyrelying party outside of subscriber domain. Domain PolicyA set of certificate policies what areMore than one common policy 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 MeshPKI.PKI model. Principal CA A CA that trusts other PKI domain or is trusted from other PKI domain. Principal CA SHOULD issue a self-signed certificate. Trusted PKI domain PKI domain which is trusted by trusty PKI domain. Usually, trusted PKI domain means a PKI domain of subscriber. Trusty PKI domain SHIMAOKA [Page 4] INTERNET DRAFT October 2003 PKI domain which trusts other PKI domains. Usually, trusty PKI domain means a PKI domain of relying party. Trust Anchor Trust anchor is a principal CA inRELYING-PARTYRELYING PARTY domain, and is also one oftrust-points.trust points. Trust Anchor SHOULD be a self-signed certificate, except for MeshPKI.PKI model. If it is necessary to claim clearly that CA is a trust anchor ofaan issued certificate, CA MAY indicate URI of its published CA certificate to caIssuer in AuthorityInformationAccess extension. Trust Relationship In this document, this means a trustrelation shiprelationship between CAs. This relationship is required for tracking from a trust point to aSHIMAOKA [Page 3] INTERNET DRAFT June 2003subscriber.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'. 2.3 Assumptions In this document, each PKI MUST have a repository for supporting the path validation, but this document do not specify whether web server or directory server. 3 Trust Relationship This section describes majortrust-relationshipstrust relationships for plural PKI interconnection. All PKIs that are going to participate in multi- domain PKI SHOULD use these trust relationships for multi-domain PKI interoperability. SHIMAOKA [Page 5] INTERNET DRAFT October 2003 3.1 Trust List Definition Trust list is a list of more than oneCA"trusted CA" certificate that means a trust point. Trust list is used for specifying a trust point byrelying-party.relying party. Requirements CA in a trust list SHOULD NOT cross-certify each other. Allrelying-partiesrelying parties in this model MUST have a trust list. Considerations TBD 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 SHIMAOKA [Page4]6] INTERNET DRAFTJuneOctober 2003 3.1.1 User Trust List Definition The model in which a trust list is managed byEE.End Entitiy (EE). EE is able to have its own user trust list individually. Advantage#EE is able to managetheits own user trust list. EE is able to add anyCA"trusted CA" certificate to its own user trust list or delete it. This is an easier andtypicallytypical method for making a trust relationship to other PKI. DisadvantageAnybody exceptExcept for EEitselfitself, anyone is not able to control the 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"userthe user trustlist",list, when CA certificate in"userthe user trustlist"list is updated. 3.1.2 Authority Trust List Definition The model in whichana trust list is issued by the trust anchor ofrelying-party.relying party. All EEs who share the same trust anchor SHOULD share asingleunique authority trust list provided by its trust anchor. Advantage EE cannot controlhisits trust relationship fromhisits trust anchor to other.AuthorityTrust anchor SHOULD control trust relationship. Disadvantage Management method for authority trust list is not established. Considerations To consider about a format of"authoritythe authority trustlist"list that is able to be processed by various applications. To consider about a management method for"authoritythe authority trustlist".list. SHIMAOKA [Page5]7] INTERNET DRAFTJuneOctober 2003 3.2 Cross-Certification Definition Cross-Certification is an issuing certificate to anotherCA."trusted CA". Requirement CA issued cross-certificateSHOULDMUST have a self-signed certificate. Advantage Cross-Certification is stricter trust relationship than the 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, across- certificatecross-certificate revocation does not always link to the subject CA compromise. Disadvantage CA MUST support cross-certification. Considerations for path construction Subject CA SHOULD issue a cross-certification request which contains subjectKeyIdentifier in extensionRequest, and its value MUST be identical with subjectKeyIdentifier in self-signed certificate. Issuer CA SHOULD issue a cross-certificate which contains subjectKeyIdentifier set to the same value in the corresponding cross-certification request. for PKI issuing Revocation List Issuer CA MAY issueARL,Authority Revocation List (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 SHIMAOKA [Page 8] INTERNET DRAFT October 2003 Definition The model in which a CA issues a cross-certificate to another CA unilaterally. Advantage This certification is able touseduse 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 2003Disadvantage for PKI using directory system CA SHOULD generate a crossCertificatePair, even though unilaterally. Considerations Subordination is peculiar unilateral cross-certification.forIf a cross-certification request is got by any CA, unilateral cross- certification is established easily without agreement from requested CA. for PKI using directory systemIssuerWhen CA-X cross-certify CA-Y unilaterally, Both CAMUST storeSHOULD operate their directory server as below. CA-X SHOULD generate across-certificate, which he issued, to issuedByThisCA element offollowing crossCertificatePairattributeand store it in its own directoryentry, except subordinate CA certificate. Subject CAentry. issuedToThisCA := NULL issuedByThisCA := cross-certificate for CA-Y issued by CA-X CA-Y SHOULDstoregenerate aissued cross-certificate to issuedToThisCA element offollowing crossCertificatePairattributeand store it in its own directoryentry, except subordinate CA certificate.entry. issuedToThisCA := cross-certificate for CA-Y issued by CA-X issuedByThisCA := NULL the following is TBD. - Considerations for updating the keypair of CA-X * When CA-X keeps the cross-certification with CA-Y * When CA-X do not keep the cross-certification with CA-Y SHIMAOKA [Page 9] INTERNET DRAFT October 2003 - Considerations for updating the keypair of CA-Y * When CA-X keeps the cross-certification with CA-Y * When CA-X do not keep the cross-certification with CA-Y - Considerations for compromising the keypair of CA-X - Considerations for compromising the keypair of CA-Y CA-X SHOULD revoke the cross-certificate for CA-Y, then CA-X MUST remove the crossCertificatePair attribute for the CA-Y from its repository. +---------------+ +----------------------+ | 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 | | | +----+ +----+ | | +----+ +----+ +----+ | +---------------+ +----------------------+ Figure 3 - Unilateral Cross-Certification 3.2.2 Mutual cross-certification Definition The model in which a CA issues a cross-certificate to another trusted CA mutually. Advantage TBD Disadvantage SHIMAOKA [Page 10] INTERNET DRAFT October 2003 for PKI using directory system Both CAs MUST generate acrossCertificatePair. Considerations for PKI using directory system Each CAs MUST generate acrossCertificatePair that is composedbyof a cross-certificate itissuesissued and the corresponding issued cross-certificate.for issuing cross-certificateWhen either CA updates a cross-certificate, each CA MUST re-generate their crossCertificatePair synchronously. Considerations Both CAs MUST agree about more information to issue across-certificatecross- certificate (e.g., validity,SHIMAOKA [Page 7] INTERNET DRAFT June 2003keyUsage, 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 onlyfor 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 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 a 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 mutual cross-certification model, each CA SHOULD NOT generate two crossCertificatePair individually, which includes only one cross-certificate. the following is TBD. - Considerations for updating the keypair of CA-X * When CA-X keeps the cross-certification with CA-Y * When CA-X do not keep the cross-certification with CA-Y - Considerations for updating the keypair of CA-Y * When CA-X keeps the cross-certification with CA-Y * When CA-X do not keep the cross-certification with CA-Y - Considerations for compromising the keypair of CA-X - Considerations for compromising the keypair of CA-Y CA-X SHOULD revoke the cross-certificate for CA-Y, then CA-X MUST remove the crossCertificatePair attribute for the CA-Y from its repository. SHIMAOKA [Page 11] INTERNET DRAFT October 2003 +---------------+ +----------------------+ | 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 a peculiar unilateral cross-certification. Definition Subordination is certificate issuing to CA that has no self-signed certificate. Subordinate CA MUST have only one superior CA. Subordinate CA MUST never issue its self-signed certificate. 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 SHIMAOKA [Page 12] INTERNET DRAFT October 2003 trusted easily by all EEs who trust the superior CA. Disadvantage Subordinate CA MUST NOT cross-certify any CAs , MAY just allowasubordination. When a subordinate CA certificate is revoked by a superior CA, also all certificates issued by the subordinate CA MUST NOT be trusted. Subordinate CA MUST NOT override the security policy, which the superior CA allowed. Considerations Subordination MUST be used in Single-domain PKI, not multi-domain PKI.for PKI using directory system SuperiorWhen subordinate CAMUST NOT storeissues a self-signed certificate, the subordinate CAcertificate to issuedByThisCAMUST require agreement of its superior CA about issuing the certificate, because almost certificates issued by the subordinate CA will be not constrained by the superior CA. for PKI using directory system Superior CA MUST NOT store a subordinate CA certificate to issuedByThisCA element of crossCertificatePair attribute in its own(superiorCA)(superior CA) 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 20034Single-domain PKI This section describes appropriate PKI architectures for singlePKIdomain. 4.1 SingleDomain PKIThisdomain issimplest PKI model. All PKI models are composed ofa set ofthis. Definition SinglePKIs gathered upon some trust relationship. 4.1 Requirements for PKIis composed of an only top CAdomain PKIs in a PKI domain MUST have more than one certain common policy andits EEs. All EEs SHOULD trust only the topmore than one principal CA. This common policy is named as "domain policy". AllsubscribersCAs in a PKI domain MUST beissued their certificateoperated by each CP/CPS which is conformed to theonly top CA. Principal CA Principal CA MUST be the top CA. Trust anchor Trust anchor MUSTcommon policy. There SHOULD bethe top CA. 4.2 Hierarchy PKI This ismore than one principal CA that issued self-signed certificate in atypical architecture of PKI. Definition HierarchyPKIis composed of an only top CA, some subordinatedomain. All CAsand EEs. Onlyin aTop CAPKI domain MUST be able to issue aself-signed certificate. All subordinate CAsverifiable certificate by using the principal CA as trust anchor. PKI domain MUSThave only one superior CA.publish the trust information below securely. - Principal CA certificate and its fingerprint - CP/CPS for Principal CAMUST be- Obtaining method of revocation information SHIMAOKA [Page 13] INTERNET DRAFT October 2003 4.2 Risk Analysis of non interoperable PKI domain A PKI domain that satisfies thetop CA. Trust anchor Trust anchor MUSTabove requirements MAY bethe top CA. All EEs SHOULD trust onlyused in multi-trust point model. However, such atop CA. 4.3 MeshPKIDefinition SHIMAOKA [Page 9] INTERNET DRAFT June 2003 Meshdomain SHOULD NOT be used in single-trust point model. If such a PKIis composeddomain makes the single-trust point model, the following problem will be considered. - Lack ofplural CAs and their EEs.the PKI Domain identification method for the third party AllCAs 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 uniquecertificates in the PKI domain have no identity necessarily for the PKI domain.Trust anchor Trust anchor SHOULD be a CA which issuedDistinguished Name cannot use as the identity for the PKI domain, because nobody administers the name space. - Case of that acertificate to relying- party. Considerations All EEs MUST trust onlyPKI domain is not trusted by another PKI domain When aCA that issued their own certificate. Which SHOULD berelying party specifies aprincipal CA? 5policy as one of the validation parameters, the certification path validation will fail because the policy of the relying party cannot map to an appropriate policy. 4.3 Requirements for multi-domain PKIMulti-domaininteroperability To achieve more multi-domain PKIis composed of pluralinteroperability, the following requirements are necessary for PKI domain. - PKI domainthatMUST havedifferentthe policyId of the domain policywhich is ablefor mapping tomap each other. Eachother PKI domain. * policyId MUST be unique with a domainestablishespolicy. * policyId MUST NOT be any-policy. - All CAs in atrust relationship with more than onePKIdomain. This section describes topology models for multi-domain PKI. Considerations Required all information for path validationdomain MUST be able tobe obtained through Internet. - Intermediateissue a verifiable certificate- Revocation information For this,by using the following validation parameters. * user-initial-policy-set is including own domainPolicyId. * initial-explicit-policy is TRUE. * trust anchor is principal CAMAY operate a repository, andcertificate of the own PKI domain. - PKI domain SHOULDinclude authorityInfoAccess or cRLDistributionPoints extensions inpublish thecertificates it issues. 5.1 Multi Trust point model (based on Trust List) The model in which a relying-party trusts plural domains by atrustlist. Relying-partyrelationship with other PKI domain. * PKI domain MUST publish what kind of PKI it includes. * PKI domain SHOULD publish what kind of other PKI domain it trusts. * PKI domain MAY publish what kind of other PKI domain it isable to use trust list for specifyingtrusted by. In addition, the following requirements MAY be necessary depending on trustpoint inrelationship with otherdomains. Trust list is a list of more than one CA certificate as a principal CA certificate in anotherPKI domain. SHIMAOKA [Page10]14] INTERNET DRAFTJuneOctober 2003Considerations The CA in a trust list SHOULD not cross-certify each other. The validation parameters SHOULD be given to each trust(1) Single-trust pointindividually. 5.1.1 Based on User Trust List Considerations This ismodel SHOULD give aneasierappropriate policy mapping between the trusty PKI domain andtypically method for makingatrust relationship to othertrusted PKIdomain. Relying-Party is abledomain to cross-certification. (2) Multi-trust point model SHOULD give an appropriate validation parameters conforming toestablish trust relationship with otherdomainirresponsiblypolicy tohisrelying party. - Appropriate (it may be newest) trustanchor. Whenanchor certificate * MAY be principal CAupdated 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 Authorityof subscriber PKI domain - Appropriate acceptable policy * MAYdistribute thebe domain policy of subscriber PKI domain * MUST NOT be any-policy - Appropriate other validation parametersby includingif necessary 5 Single-domain PKI This section describes appropriate PKI architectures for single PKI domain. All PKIs that are going to participate in multi-domain PKI SHOULD adopt any models of thetrust 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,following forpath validation from somewhere. 5.2multi-domain PKI interoperability. 5.1 SingleTrust Point model (based on Cross-Certification) ThePKI modelin which all domains related by Cross-Certification. In this model, a trust pointThis isjust a trust anchor. Therefore, certification path always start from trust anchorsimplest PKI model. All PKI models are composed ofrelying-party. Considerations Each domain SHOULD use policy mapping for indicating different domain. In addition, cross-certificate SHOULDsetzero to requireExplicitPolicy in the policyConstraints extension,of this. Definition Single PKI is composed of an only top CA andMAY set any value to inhibitPolicyMappings in the policyConstraints extension. Ifits EEs. All EEs SHOULD trust only thedomain does not use policy mapping, it MAY seem same domain.top CA. Allcertification pathsubscribers MUST bestarted fromissued their certificate by the onlytrust anchor,top CA. Principal CA Principal CA MUST be the top CA. Trust anchor Trust anchor MUST be the top CA. +----+ +---| CA |---+ SHIMAOKA [Page11]15] INTERNET DRAFTJuneOctober 2003then 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| +----+ | | | | | | | v v v +----+ +----+ +----+ | EE | | EE | | EE | +----+ +----+ +----+ Figure 5 - Single PKI model(based on Cross-Certification) The5.2 Hierarchy PKI modelin which two peer domains trust each other by Cross- Certification.Thistrust relationship SHOULD be established by mutual Cross-Certification, or MAY be established by unilateral Cross-certification. In Cross-Certification model, because trust-anchoris a typical architecture of PKI. Definition Hierarchy PKI is composed of an onlyone,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 thevalidation parameters SHOULDtop CA. Trust anchor Trust anchor MUST beauthority-constrained things. 5.2.2 Super Domainthe top CA. All EEs SHOULD trust only a top CA. +---------+ +---| root CA |---+ | +---------+ | | | | | v v +----+ +----+ +-----| CA | +-----| CA |------+ | +----+ | +----+ | | | | v v v +----+ +----+ +----+ +--| CA |-----+ | CA |-+ +---| CA |---+ | +----+ | +----+ | | +----+ | | | | | | | | | | | | | | | | | v v v v v v v v +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ SHIMAOKA [Page 16] INTERNET DRAFT October 2003 | EE | | EE | | EE | | EE | | EE | | EE | | EE | | EE | +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ Figure 6 - Hierarchy PKI model(based on unilateral Cross-Certification) The5.3 Mesh PKI model Definition 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 whichplural domains haveissued a certificate to relying party. Considerations All EEs MUST trust only acommon superiorCA thatissues cross-certificates to each domain unilaterally. Eachissued their own certificate. Which SHOULD be a principal CA for foreign PKI domain? cross certified +-------+ cross certified +---------------->| CA |<----------------+ | +-------+ | | | | | | | | | | v v | | +----+ +----+ | | | EE | | EE | | | +----+ +----+ | v v +------+ +------+ | CA |<--------------------------------->| CA |-----+ +------+ cross certified +------+ | | | | | | | | | | | v v v v v +----+ +----+ +----+ +----+ +----+ | EE | | EE | | EE | | EE | | EE | +----+ +----+ +----+ +----+ +----+ SHIMAOKA [Page 17] INTERNET DRAFT October 2003 Figure 7 - Mesh PKI model 6 multi-domain PKI Multi-domain PKI is composed of plural PKI domain that MUST havea certain common certificatedifferent domain policyat least. 5.2.3 Hub model (a.k.a Bridge CA) The model inwhichevery domains trust each other through a Bridge CA by Cross-Certification. Thisisusefulable toreduce the complexity of cross-certification.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. All PKIs that compose multi-domain PKI SHOULD adopt any models of the following for multi-domain PKI interoperability. 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. 6.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. Considerations The CA in a trust list SHOULD not cross-certify each other. The validation parameters SHOULD be given to each trust point individually. 6.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 MAY need to obtain some inputs, e.g., user-initial-policy-set, initial-policy-mapping- inhibit, initial-explicit-policy and initial-any-policy-inhibit, SHIMAOKA [Page 18] INTERNET DRAFT October 2003 for path validation from somewhere. 6.1.2 Based on Authority Trust List Authority MAY distribute the validation parameters by including in the trust list. Considerations 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.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, then validation parameters MAY be an only set. Cross-Certificate SHOULD use authorityKeyIdentifier extension and subjectKeyIdentifier extension for path construction. 6.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. 6.2.2 Super Domain model (based on unilateral Cross-Certification) SHIMAOKA [Page 19] INTERNET DRAFT October 2003 The model in which plural domains have a common superior CA that issues cross-certificates to each domain unilaterally. Each domain MUST have more than one common certificate policy at least. This model looks like a subordination model, except for that the intermediate CA has a self-signed certificate. Therefore, often this model is used as hierarchy model in multi-domain PKI. cross-certified cross-certified Top CA to PKI 1 +--------+ Top CA to PKI 3 +-----------| Top CA |-------+ | +--------+ | | | | | cross-certified | | | Top CA to PKI 2 | | | | | +-----------|---+ +-----------|---+ +----|-----------------+ | 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 8 - Super Domain model 6.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. SHIMAOKA [Page 20] INTERNET DRAFT October 2003 Requirements for Hub model - Bridge CA MUST NOT be used as the trust anchor for any PKI domain. - Bridge CA MUST issue cross-certificate with other PKI domain mutually. - Bridge CA SHOULD issue ARL and CRL, or MAY issue fullCRL. - Bridge CA MUST NOT issue EE certificate except necessary one for the CA operation. And at least, the EE certificate MUST be constrained to fail in the path validation from other PKI domain. - Bridge CA MUST use own domain policy in the policy mapping between a trusty PKI domain and a trusted PKI domain. Trusty Domain Policy := Bridge Domain Policy Bridge Domain Policy := Trusted Domain Policy - Cross-Certificate issued by Bridge CA and Cross-Certificate issued to Bridge CA SHOULD include the requireExplicitPolicy more than equal zero in policyonstaints extension. - Trusty PKI domain MUST trust trusted PKI domain via Bridge CA. - PKI domain cross-certified with Bridge CA SHOULD NOT cross- certify directly to other PKI domain cross-certified with the same Bridge CA. - Bridge CA SHOULD clarify the method for the policy mapping of cross-certification. ConsiderationsBCABridge CA SHOULD be operated by neutral trusted third party. Bridge CA SHOULD do policy mapping appropriately with both domains. Both domains that cross-certified to Bridge CA SHOULD NOT use nameConstraints extension because they cannot limit name-spaces via Bridge CA. Bridge CA MUST have an independent certificate policy, and MUST use it for policy mapping for both domains. cross-certified cross-certified PKI 1 with BCA +-----------+ PKI3 with BCA +------->| Bridge CA |<------+ | +-----------+ | | ^ | | cross-certified | | | PKI 2 with BCA | | | | | +-----------|---+ +-----------|---+ +----|-----------------+ | PKI 1 | | | PKI 2 | | | | PKI 3 | | v | | v | | v | | +-----+ | | +-----+ | | +-----+ | | +---| PCA | | | | PCA | | | | PCA |<--+ | | | +-----+ | | +-----+ | | +-----+ | | | | | | | | | | ^ | | SHIMAOKA [Page 21] INTERNET DRAFT October 2003 | | | | | | | | | v | | | | | | | | | | +----+ | | | | | | | | | | | CA |---+ | | | | | | | | | | +----+ | | | | | | | | | | | ^ | | | | | | | | v | | v | | | | | | | | | +----+ | | +----+ | | | | | | | | | +---| CA | | | | CA |---+ | | | | | | | | | +----+ | | +----+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | v v | | v v | | v v v | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ | | | EE | | EE | | | | EE | | EE | | | | EE | | EE | | EE | | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ +----+ | +---------------+ +---------------+ +----------------------+ Figure 9 - Hub model 6.2.4 Considerations for trusted third CA This clause considers the case of that trust relationship is not established between subscriber domain and relying party domain directly, but established via trusted third CA (e.g., Bridge CA in Hub model, and Top CA in Super domain model). (1) Advantage of using trusted third CA - Trusty PKI domain can deploy automatically the trusted PKI domain that has corresponding security level of own policy. - Trusty PKI domain can publish a security level of own policy by cross-certification with trusted third CA. * This means that the trusty PKI domain passed the criteria for the cross-certification of the trusted third CA. * This means that the trusty PKI domain has no risk of mismapping with other PKI domain which is lower security level. - PKI domain can suggest the cross-certification with trusted third CA as index to beoperatedtrusted from other PKI domains. (2) Confirmation for trusting the trusted third CA byneutralPKI domain - Does the trusted thirdparty. BCA SHOULDCA do the policy mappingappropriatelyvia its own domain policy? - Does the trusted third CA clear the method of policy mapping in cross-certification? - Is the trusted third CA able to accept the domain policy that the trusty PKI domain desired? SHIMAOKA [Page 22] INTERNET DRAFT October 2003 * If the domain policy is mapped to lower security level, trusty domain MUST NOT accept it. * Trusty PKI domain SHOULD request that trusted third CA accept the enough policy control to achieve maintaining its security level. (3) Considerations If trusted third CA cannot keep neutrality, trusty PKI domain will cross-certify withboth domains. Both domainsPKI domain thatcross-certifiedis lower security level. 7 Security Considerations 7.1 Certificate and CRL Profile To define the Certificate and CRL profile for multi-domain PKI interoperability is not scope of this memo. CA in multi-domain PKI SHOULD consider about the following for the Certificate and CRL profile. * The extensions for only processing in local PKI domain MUST be non-critical. * cRLDistributionPoint extension SHOULD be used for obtaining the revocation list. distributionPoint SHOULD prefer UniformResourceIdentifier. When the CRL is separated toBCACARL and EPRL, issuingDistributionPoint extension also SHOULDNOT use nameConstraintsbe used. * Authority Key Identifier extension and Subject Key Identifier extension SHOULD be used for aiding a path construction. * Certificate Policies extension SHOULD be used for identifying each policy domain. * Policy Mapping extensionbecause they cannot limit name-spaces via BCA. BCA MUST have an independent certificate policy, and MUST use itMAY be used for policy mapping in single trust point model. * Name Constraints extension MAY NOT be used forboth domains. 6 Security Considerations 6.1 Certificate and CRL Profile TBD 6.2multi-domain PKI because 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 RepositoryAllRelying party MUST obtain all required information for path construction andvalidation SHOULD be obtained from relying-party. 6.3 Path Validationvalidation. If necessary, CA issues a certificate including Authority Information Access extension or CRL Distribution SHIMAOKA [Page12]23] INTERNET DRAFTJuneOctober 2003 Points extension for aiding in that a relying party does the path construction. 7.3 Path Validation Validation parameters used for path validation SHOULD be intersection betweenauthority- constrainedauthority-constrained parameters and user-constrained parameters.Which SHOULD beNon certificate holders MUST determine carefully their validation parameters including the trust anchor. 7.4 Asymmetric problem 7.4.1 Hybrid trust model This clause considers a case of that PKI domains trustanchor for non certificate holder? 7each other by different trust relationship. TBD 7.4.2 Asymmetric policy mapping This clause considers a case of that result 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 TBD 8 References[RFC 3280]8.1 Normative References [PKIX] 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. SHIMAOKA [Page 24] INTERNET DRAFT October 2003 [ISO-X509] ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information Technology - Open Systems Interconnection: The Directory: Authentication Framework," 2001 edition.8 Acknowledgements8.2 Informative References TBD 9 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). 10 Author's Address Masaki SHIMAOKA SECOM Trust.net Co., Ltd. SECOM SC Center, 8-10-16, Shimorenjaku Mitaka, Tokyo JAPANPhone: +81-422-91-8493Email: shimaoka@secom.ne.jp1011 Full Copyright Statement "Copyright (C) The Internet Society(date).(2003). 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 SHIMAOKA [Page 25] INTERNET DRAFT October 2003 document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or otherSHIMAOKA [Page 13] INTERNET DRAFT June 2003Internet 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 [Page14]26] ----