Network Working Group M. Shimaoka
Request for Comments: DRAFT SECOM
<draft-shimaoka-multidomain-pki-05.txt> N. Hastings
NIST
July 2005
Memorandum for multi-domain
Public Key Infrastructure (PKI) Interoperability
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on Jan 10, 2006.
Abstract
This memo is intended to describe the foundation necessary to the
deployment of a multi-domain PKI. The scope of this memo is to
establish and clarify the trust relationships and interoperability
between multiple PKI domains. A Certification Authority (CA) is able
to extend a certification path by establishing trust with other CAs.
Both single- and multi-domain PKIs are established by such trust
relationships between CAs. Typical and primitive PKI model is a
single-domain PKI that shares the same certificate policy at a
specified trust level. A multi-domain PKI is established by
combining more than one single-domain PKI. A multi-domain PKI can be
Shimaoka & Hastings [Page 1]
INTERNET DRAFT July 2005
categorized as either a multi-trust point model based on the trust
list model; or single-trust point model based on the Cross-
Certification model.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Requirements and Assumptions . . . . . . . . . . . . . . . . . 4
2.1 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Trust Relationship . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 Operation based Trust Relationship . . . . . . . . . . . . . . 9
3.1.1 User Trust List model . . . . . . . . . . . . . . . . . . . . 10
3.1.2 Authority Trust List model . . . . . . . . . . . . . . . . . 10
3.2 Certificate based Trust Relationship . . . . . . . . . . . . . 11
3.2.1 Unilateral Cross-Certification . . . . . . . . . . . . . . . 12
3.2.2 Mutual Cross-Certification . . . . . . . . . . . . . . . . . 13
3.3 Subordination (Hierarchy) . . . . . . . . . . . . . . . . . . . 14
4 PKI Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1 Requirements for PKI domain . . . . . . . . . . . . . . . . . . 16
4.2 Risk Analysis of non-interoperable PKI domains . . . . . . . . 16
4.3 Trust Relationship Disclosure Requirements for multi-domain PKIs17
5 Single-domain PKI . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1 Single CA PKI model . . . . . . . . . . . . . . . . . . . . . . 18
5.2 Hierarchy PKI model . . . . . . . . . . . . . . . . . . . . . . 19
5.3 Mesh PKI model . . . . . . . . . . . . . . . . . . . . . . . . 19
6 multi-domain PKI . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1 Multi Trust point model . . . . . . . . . . . . . . . . . . . . 21
6.1.1 Based on User Trust List . . . . . . . . . . . . . . . . . . 22
6.1.2 Based on Authority Trust List . . . . . . . . . . . . . . . . 22
6.2 Single Trust Point model . . . . . . . . . . . . . . . . . . . 22
6.2.1 Unified Domain model . . . . . . . . . . . . . . . . . . . . 22
6.2.2 Bridge model . . . . . . . . . . . . . . . . . . . . . . . . 23
7 Operational Considerations . . . . . . . . . . . . . . . . . . 26
7.1 Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.2 Cross-Certification . . . . . . . . . . . . . . . . . . . . . . 27
7.3 Providing Directory Information Across PKI-domains . . . . . . 28
8 Security Considerations . . . . . . . . . . . . . . . . . . . . 28
8.1 Certificate and CRL Profile . . . . . . . . . . . . . . . . . . 28
8.2 Path Validation . . . . . . . . . . . . . . . . . . . . . . . . 29
8.3 Asymmetric problem . . . . . . . . . . . . . . . . . . . . . . 29
8.3.1 Hybrid trust model . . . . . . . . . . . . . . . . . . . . . 29
8.3.2 Asymmetric policy mapping . . . . . . . . . . . . . . . . . . 29
9 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1 Normative References . . . . . . . . . . . . . . . . . . . . . 30
9.2 Informative References . . . . . . . . . . . . . . . . . . . . 30
10 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 31
Shimaoka & Hastings [Page 2]
INTERNET DRAFT July 2005
11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31
12 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 32
1 Introduction
PKIs are extendable to realize various architectures, through the way
in which CAs establish trust relationships with each other. When a
CA wishes to establish a trust relationship with another CA, the CAs
MUST compare the security requirements defined in their certificate
policies since certificate policies vary greatly across CAs. Those
CAs should choose an appropriate trust relationship which satisfies
both security requirements, as a result of that comparison. To
establish appropriate trust relationships, a complete understanding
of the relationship between the establishment method and a comparison
of security requirements in each certificate policies is required.
In addition, all established trust relationships fall into one of two
categories: a single- or multi-domain PKI. In order to establish
trust relationships between CAs, technology, such as protocol
specifications and data formats, alone is insufficient. The existing
protocol specifications and data formats do not define the PKI
architectures and boundary of the PKI domains and do leave those
decisions up to the designers of specific PKIs. Therefore, an
understanding of the CAs' PKI architectures and domains are required
to determine the appropriateness of establishing the trust
relationship. This document clarifies these definitions for multi-
domain PKI interoperability.
Section 2 describes the terminology necessary to consider multi-
domain PKI. Section 3 categorizes the trust relationships between
CAs as Trust List, Cross-Certification, and Subordination. Section 4
defines a PKI domain and requirements for multi-domain
interoperability. Section 5 defines major models necessary to
establish single-domain PKIs. Section 6 profiles multi-domain PKIs
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, Repositories, and path validation.
+------------------+ +-------------------+
| PKI domain | | PKI domain |
| | Domain-Domain | |
| | Trust | |
| +-----+ | Relationship | +-----+ |
| | PCA |<===========================>| PCA | |
| +-----+ | | +-----+ |
| ^ | | ^ |
Shimaoka & Hastings [Page 3]
INTERNET DRAFT July 2005
| | 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",
"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
CA: Certification Authority
EE: End Entity
CRL: Certificate Revocation List
ARL: Authority Revocation List
PCA: Principal Certificate Authority
RP: Relying Party
CP: Certificate Policy
CPS: Certification Practice Statement
DN: Distinguished Name
2.2 Terminology
End Entity (EE)
The preferred definition of EE is based on the X.509 4th edition
definition instead of that found in RFC 2828, since it includes
relaying parties and not just subjects of certificates as EEs.
That is, a certificate subject that uses its private key for
purposes other than signing certificates or an entity that is a
relying party [sic].
Shimaoka & Hastings [Page 4]
INTERNET DRAFT July 2005
Relying Party (RP)
Entity who verifies the certificate. RP MUST have one or more
trust anchors and MAY have a set of validation policies. In
single-domain PKI, the trust anchors and validation policies MAY be
omitted implicitly.
Responsible EE
Responsible EE directly trusts the CA that issued a self-signed
certificate used as a trust anchor and has been issued a
certificate by the CA under its subscriber agreement. Responsible
EE assumes some responsibilities and rights based on a contract or
agreement with the trust anchor. For example, the responsible EE
is issued its certificate under the contract or agreement with the
trust anchor, and should specify a certain validation policy in the
path validation.
Irresponsible EE
Unlike a responsible EE, an irresponsible EE trusts directly the
trust anchor but has no contract with the trust anchor. In other
words, irresponsible EE trusts the trust anchor one-sidedly without
having rights from the trust anchor.
Subscriber
An entity that is the subject identified within a public key
certificate issued by a certificate authority of a PKI.
Subscriber Agreement
A document used to describe the rights, obligations, and
responsibilities of a subscriber to a PKI. This may take the form
of a contract.
Intermediate Certificate
Certificates in a certification path except the trust anchor
certificate and the certificate being validated.
PKI domain
The word "PKI domain" is used to represent and identify a set of
PKIs which share the same trust level. PKI domain MUST have one or
more principal CAs and SHOULD have one or more domain policy.
The scale of the PKI domain MAY vary by the required trust level.
For example, a PKI domain which requires the high trust level may
Shimaoka & Hastings [Page 5]
INTERNET DRAFT July 2005
be quite narrow and a PKI domain which requires the low trust level
may be broad. PKI domain is established by the specific trust
relationship which is achieved by the agreement on the certificate
policy representing the shared trust level.
Domain Policy
A common or agreed upon certificate policy that is shared in a PKI
domain. When the PKIs in a PKI domain can share multiple
certificate policies of different levels, there can be multiple
domain policies within the PKI domain. The Object Identifier(s)
belonging to a PKI domain is used to distinguish that PKI domain
from another. A PKI domain having no certificate policy MAY not be
identified by the relying party in another PKI domain.
Top CA
Only CA that is a root in 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 as
defined later in this section.
Trust Anchor
Starting point of a certification path specified by a relying
party. If a relying party has to perform a validation of the trust
anchor, it SHOULD be verified by some trustworthy out-of-band
procedure which is beyond the scope of this memo. In addition,
trust anchor SHOULD be a CA issuing a self-signed certificate for
an operational reason, which is capable of verifying easily the
binding of the private key and the public key.
Posterior PKI domain
This term is used to describe the relative trust relationship of
adjoined PKI domains in the certification path and is used in
combination with the term "prior PKI domain". The next trusted PKI
domain(s) in the certification path from the trust anchor to the
target certificate is called the posterior PKI domain. That is,
the posterior PKI domain is trusted from the prior PKI domain.
Prior PKI domain
This term is used to describe the relative trust relationship of
adjoined PKI domains in the certification path and is used in
combination with the term "posterior PKI domain". The previous PKI
domain in the certification path from the trust anchor to the
target certificate is called the prior PKI domain. That is, the
Shimaoka & Hastings [Page 6]
INTERNET DRAFT July 2005
prior PKI domain trusts the posterior PKI domain. First prior PKI
domain in the certification path is the PKI domain trusted directly
by a relying party.
Trust Relationship
Generally, trust relationship in PKI means a relationship between
each CA or between CA and EE. In this document however, this means
a trust relationship between CAs. This relationship is required
for tracing trust from a trust anchor to a subscriber.
Validation policy
The concept of this is defined in RFC 3379. In this document, the
items which should be focused on are the following.
(c) user-initial-policy-set
(d) trust anchor information,
(e) initial-policy-mapping-inhibit
(f) initial-explicit-policy
(g) initial-any-policy-inhibit
These are parts of input for the path validation, which is defined
in RFC 3280 section 6.1.1. The reason why this document focuses on
these items is that these values may be different depending on each
trust anchor.
Principal CA
CA which has a self-signed certificate and is trusted from the
other PKI domain. The reason why a principal CA has a self-signed
certificate is the principal CA must be independent from all other
certification including inside of its PKI domain.
Unificate CA
CA which has a self-signed certificate and issues unilateral cross-
certificates to each principal CA of other posterior PKI domains.
Unificate CA is specified as a trust anchor for the PKI domains
that are cross-certified with it.
Trust List
Trust list is a list of one or more trust anchors, which MAY be a
set of the trust anchor certificates in general. Otherwise, it MAY
be a set of public keys or Distinguished Names. Trust list is used
for specifying a trust anchor by a relying party.
Subordination
Shimaoka & Hastings [Page 7]
INTERNET DRAFT July 2005
Subordination is a mechanism to authorize the existence of a
subject CA. The authorization of the existence means issuing a
certificate called subordinate (CA) certificate to a CA who has no
certificate.
Cross-Certification
Cross-certification is a mechanism to recognize the existence of a
subject CA. The recognition of the existence means issuing a
certificate called cross-certificate to a CA who has another
certificate already. In this document, this wording is more
limited than the definition in RFC 2828. That is, cross-
certification in RFC 2828 means mutual cross-certification, but
cross-certification in this document allows unilateral cross-
certification.
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 for multiple PKI(CA)
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 Trust Relationship
Definition
Trust List is defined in terminology 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,
except the case that those trust anchors are operated by the same
body.
Considerations
A relying party using the trust list MAY trust multiple trust
anchors, but finding out a revocation of each trust anchor is more
difficult than finding out it for one.
Shimaoka & Hastings [Page 8]
INTERNET DRAFT July 2005
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 End Entities (EEs).
Each EE is able to have its own user trust list.
Characteristics
EE is able to manage its own user trust list. EE is able to add or
delete a trust anchor from its own user trust list. This is easier
than cross-certification and is typical method for making a trust
relationship with another PKI.
Except for EE itself, no one is able to control the trust
Shimaoka & Hastings [Page 9]
INTERNET DRAFT July 2005
relationship. There is a risk that EE trusts unknown PKI domain
irresponsibility. If EE trusts unknown PKI domains irresponsibly,
then the issuer CA cannot apply its 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 is managed by the trust authority,
which manages the trust anchors that are to be used by a relying
party. The trust authority MAY issue multiple trust lists for some
purposes or parties. EEs trusting the same trust authority may
share the authority trust list given by the trust authority.
Characteristics
EE does not have control over any trust relationships from its
trust anchor. Trust anchor SHOULD control an appropriate trust
relationship with other CAs keeping the same security level.
Considerations
Since there is no standard for the use of this model, management
methods for authority trust list are not established. In
generally, this model MAY not achieve sufficient interoperability.
3.2 Certificate based Trust Relationship
Certificate based trust relationship is realized by the cross-
certification unilaterally or mutually.
Definition
Cross-certification is defined in terminology section 2.2.
Requirement
A subject CA in the cross-certification MUST have a self-signed
certificate.
Characteristics
Shimaoka & Hastings [Page 10]
INTERNET DRAFT July 2005
Cross-Certification is a more formal expression of the trust
relationship than the trust list model, because the trust
relationship is represented by a certificate, (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 a cross-certificate does not
always mean also compromising the subject CA.
A PKI which issues a cross-certificate SHOULD have a repository.
The issuing CA SHOULD publish the cross-certificate in the
repository for relying parties. In general, the cross-certificate
is populated to the crossCertificatePair attribute of a repository
such as a LDAP or X.500 directory server. At minimum, a PKI which
issues a cross-certificate MUST provide a mechanism for obtaining
the cross-certificate to a relying party, like a caIssuers in
accessMethod of the AIA extension.
Considerations
When a subject CA does not have a self-signed certificate, such
subject CA is established by another CA issuing the cross-
certificate to the subject CA. This, however, means the issuer CA
of the cross-certificate may not be able to recognize the existence
of the subject CA because the issuer CA may not have a formal
agreement or contract to the establishing CA. Therefore, this
document strongly recommends that a subject CA SHOULD have a self-
signed certificate.
Especially for the inter-domain cross-certification, this document
recommends that issuer CA SHOULD accept and agree on the way the
subject CA is operated.
For path construction
Because the key identifier of each CA MAY be calculated
differently, subject CA SHOULD issue a cross-certification
request that contains subjectKeyIdentifier in extensionRequest,
with a value that MUST be identical to the subjectKeyIdentifier
in the self-signed certificate. Then, issuer CA SHOULD issue a
cross-certificate with the subjectKeyIdentifier set to the same
value in the corresponding cross-certification request.
For PKI issuing Revocation List
Issuing CAs MAY issue Authority Revocation Lists (ARLs), or
SHOULD at least issue full CRLs. However, ARL with an
issuingDistributionPoint extension MAY NOT be processed by some
Shimaoka & Hastings [Page 11]
INTERNET DRAFT July 2005
applications.
3.2.1 Unilateral cross-certification
Definition
The model in which a CA issues a cross-certificate unilaterally to
another CA which has a self-signed certificate.
Characteristics
This certification is used like subordination, but is able to
establish a more flexible trust relationship than subordination;
even if the cross-certificate is revoked, subject CA MAY be able to
continue its operation.
If the PKI uses a directory system, the CA MUST populate a
crossCertificatePair, even when the cross-certification is
unilateral, to avoid 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 subject CA because a cross-
certificate can be issued from the public key of the subject CA.
In the example of figure 3 below, RPs who use the PCA of PKI 1 as
the trust anchor can trust EEs of PKI 2 not only EEs of PKI 1. But
RPs who use the PCA of PKI 2 as the trust anchor cannot trust EEs
of PKI 1. This configuration means helping RPs who use PCA of PKI
1 to interoperate with EEs of PKI 2, but not vice versa.
+---------------+ +----------------------+
| PKI 1 | | PKI 2 |
| | cross-certified | |
| +-----+ | PKI 1 to PKI 2 | +-----+ |
| | PCA |--------------------------->| PCA |<--+ |
| +-----+ | | +-----+ | |
| | | | ^ | |
| | | | | v |
| | | | | +----+ |
| | | | | | CA |---+ |
| | | | | +----+ | |
| | | | | ^ | | |
| v | | v | | | |
| +----+ | | +----+ | | | |
| | CA |---+ | | | CA |---+ | | |
Shimaoka & Hastings [Page 12]
INTERNET DRAFT July 2005
| +----+ | | | +----+ | | |
| | | | | | | | |
| | | | | | | | |
| 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 self-signed CA issues a cross-certificate to
the other self-signed CA, and vice versa.
Characteristics
Both CAs cross-certify with each other mutually.
For PKI using directory system
Both CAs MUST generate a crossCertificatePair that consists of
the cross-certificate it issued to the other CA and the
corresponding cross-certificate that it was issued by the other
CA. When either CA updates a cross-certificate, each CA MUST
re-generate their crossCertificatePair synchronously.
If re-generating asynchronously, the result of the path
validation may differ by the method of path building, such as
forward path building and reverse path building.
Considerations
Both CAs MUST agree and accept more information in order to issue a
cross-certificate (e.g., validity, keyUsage, and constraints) and
MUST exchange the information.
+---------------+ +----------------------+
| PKI 1 | | PKI 2 |
| | cross-certified | |
| +-----+ | PKI 1 and PKI 2 | +-----+ |
| | PCA |<-------------------------->| PCA |<--+ |
| +-----+ | | +-----+ | |
| | | | ^ | |
| | | | | v |
Shimaoka & Hastings [Page 13]
INTERNET DRAFT July 2005
| | | | | +----+ |
| | | | | | 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 special unilateral cross-certification.
Definition
The model in which a CA issues a certificate to a CA which has no
self-signed certificate. The model in which a PKI has always only
one root CA.
Requirements
A subordinate CA MUST have only one superior CA and be managed by
the superior CA strictly. A subordinate CA MUST never issue its
self-signed certificate.
Characteristics
EEs can trust all following subordinate CA and its EEs by trusting
only the root CA. Subordination is different from unilateral
cross-certification, in that this model MUST NOT allow a
subordinate CA to be issued a certificate by more than one issuer
CAs. A subordinate CA MAY NOT require an accreditation
necessarily, such as WebTrust or license under the e-signature law.
The accreditation is rather required only for the superior CA or
the root CA. Although a full third party accreditation of the
subordinate CA is not required, it is the responsibility of the
superior or root CA to ensure it issues CA certificates to CAs that
operate under its accredited policies and procedures. In this
case, accreditation means that the subordinate CA can succeed the
Shimaoka & Hastings [Page 14]
INTERNET DRAFT July 2005
benefit on the trustworthiness of the superior CA. An 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. Because a subordinate CA has an explicit trust
relationship with its superior CA, the subordinate CA is able to be
trusted easily by all EEs who trust the superior CA.
Subordinate CAs MUST NOT cross-certify with another PKI domains,
but MAY just allow a subordination within the same PKI domain.
When a subordinate CA certificate is revoked by a superior CA, all
certificates issued by the subordinate CA are also invalid.
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.
The violation with issuing a self-signed certificate to a
subordinate CA may be considered as the following two cases. If
the subordinate CA issues a self-signed certificate, and if RPs
change their trust anchor from the original root CA to the former
subordinate CA, the entities which the RPs can trust will shrink to
only under the former subordinate CA.
If the subordinate CA issues a self-signed certificate, but if RPs
do not change their trust anchor (original root CA), the entities
which the RPs can trust will still be same but the trust
relationship will change from the subordination model into the
unified domain model as described in section 6.2.2.
4 PKI Domain
4.1 Requirements for PKI domain
PKIs in a PKI domain SHOULD share a common "domain policy" consisting
of one or more certificate policies. The certificate policies of the
domain policy SHOULD be populated in the certificate policies
extension for each certificate. The PKI domain MUST have at least
one principal CA that can be trusted by other PKI domains. The PKI
domain MUST have a mechanism to propagate certificate status
information to other PKI domains. The PKI domain SHOULD agree to a
minimum common certificate profile.
All CAs in a PKI domain MUST be operated under a CPS that conforms to
the domain policy. All CAs in a PKI domain MUST be able to issue a
certificates under including a valid certificate policy of the domain
policy.
Shimaoka & Hastings [Page 15]
INTERNET DRAFT July 2005
4.2 Risk Analysis of non-interoperable PKI domains
A PKI domain that satisfies the requirements presented in the section
4.1 of this document MAY be used in the multi-trust or single-trust
point model. However when one PKI domain interconnects with another
PKI domain, the following items need to be considered to reduce the
risk of being non-interoperable:
- Namespace Conflicts
PKI domains SHOULD agree to use namespaces that do not overlap.
If PKI domain namespaces overlap, a namespace conflict occurs
resulting in the name constraints extension possibly not perform
the specified name constraint as intended.
- PKI Domain Policy in Certificates
CAs of PKI domains SHOULD populate the certificate policy
extension with the PKI domain policy. If the PKI domain policy
is not described in the certificate policies extension, the path
validation MAY fail when relying parties use the certificate
policy extension to identify PKI domain. The PKI domain policy
is necessary in path validation through PKI domains that use
policy constraints or policy mapping.
- Certificate Authority Certification Path Constraints
A CA that wants to assert constraints for the certification path
MUST include explicitly the extensions for the constraints in
the certificates that the CA issues, since that CA assumes the
validation policy used by a relying party which MAY NOT be under
the CA's control. By explicitly including the constraints in
certificates, a certification path that otherwise would validate
will fail, regardless of a relying party's path validation
settings or configuration.
For example; Assume the CA-X expects its RPs to evaluate an
appropriate certificate policy in the path validation. Even if
the CA-X expects its RP to set the initial-explicit-policy flag
to TRUE, there is no guarantee that RP sets the flag to TRUE
because there are responsible EE and irresponsible EE. A
responsible EE may set the flag to TRUE, but an irresponsible EE
may not set it. Therefore, CA-X SHOULD issue a certificate
which uses requireExplicitPolicy explicitly in the
policyConstraints extension. If CA-X issues all certificates
which use requireExplicitPolicy in the policyConstraints
extension, RP MUST evaluate the certificate policy whether it
has responsibility or not.
Shimaoka & Hastings [Page 16]
INTERNET DRAFT July 2005
- End Entity Certification Path Constraints
Some PKI domains that require an explicit policy MAY NOT assert
the requiredExplicitPolicy constraint in certificates they
issue. These PKI domains assume relying parties will configure
their validation policy appropriately. A PKI domain requiring
an explicit domain policy SHOULD set the following validation
policy for its end entities:
* user-initial-policy-set which includes its own
domainPolicyId. * initial-explicit-policy set to TRUE. *
trust anchor which is the principal CA of its PKI domain.
- Distribution of Certificate and Certificate Status Information
PKI domains SHOULD make certificate and certificate revocation
lists (CRLs) available using LDAP or HTTP. This provides the
ability for other certificate status protocols such as OCSP and
SCVP to be implemented without requiring the PKI domain
providing the certificates and CRLS to implement the protocol.
If certificate and certificate status information is not made
available by a PKI domain, certification paths passing through
that PKI domain MAY not be constructed and validated.
4.3 Trust Relationship Disclosure Requirements for multi-domain PKIs
For any multi-domain PKI model, each PKI domain SHOULD show the trust
relationship(s) it has with other PKI domains as follows:
* Posterior PKI domain X SHOULD show its PKI architecture to the
prior PKI domain Y, because the trust relationship from the PKI
domain Y to the PKI domain X MAY depend on such PKI architecture.
* Posterior PKI domain X SHOULD show all PKI domains that it trusts
to the prior PKI domain Y, because the prior PKI domain Y MUST
consider not to trust an unnecessary PKI domain.
* Posterior PKI domain X MAY publish what kind of all PKI domain it
is trusted by to the prior PKI domain Y, because the PKI domain Y
MAY consider the other certification path to the PKI domain X.
In addition, PKI domains SHOULD give the appropriate policy mappings
between prior PKI domains and the posterior PKI domains for
certificate based trust relationship.
5 Single-domain PKI
This section describes appropriate PKI architectures for establishing
a single PKI domain. All PKIs that are going to participate in
multi-domain PKI SHOULD adopt any of the following models for multi-
domain PKI interoperability.
Shimaoka & Hastings [Page 17]
INTERNET DRAFT July 2005
5.1 Single CA PKI model
This is the simplest PKI model which is a special case of a
hierarchical PKI which has no subordinate CAs. All PKIs in this
model are composed using this building block of a CA and its EE.
Definition
Single PKI consists of a single self-signed CA and its EEs. All
EEs MUST be issued their certificates by the only CA.
Trust anchor
The trust anchor MUST be the self-signed certificate of the CA.
+----+
+---| CA |---+
| +----+ |
| | |
| | |
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 PKI consists of a single root CA, a number of subordinate
CAs, and EEs. Only the root CA MUST issue a self-signed
certificate. All subordinate CAs MUST have only one superior CA.
Trust anchor
Trust anchor MUST be the root CA. All EEs SHOULD trust only the
root CA.
+---------+
+---| top CA |---+
| +---------+ |
| |
| |
v v
Shimaoka & Hastings [Page 18]
INTERNET DRAFT July 2005
+----+ +----+
+-----| CA | +-----| CA |------+
| +----+ | +----+ |
| | |
v v v
+----+ +----+ +----+
+--| CA |-----+ | CA |-+ +---| CA |---+
| +----+ | +----+ | | +----+ |
| | | | | | | |
| | | | | | | |
v v v v v v v v
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | EE | | EE | | EE | | EE | | EE |
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
Figure 6 - Hierarchy PKI model
5.3 Mesh PKI model
Definition
Mesh PKI consists of multiple CAs and their EEs. All CAs MUST
cross-certified with more than one CA unilaterally. Some CAs MAY
cross-certify mutually.
Trust anchor
The trust anchor for a relying party who is issued a certificate
from a CA in the mesh PKI SHOULD be the CA who issued the
certificate to the relying party. The trust anchor for the relying
party who is not issued a certificate from the mesh PKI MAY be any
CA in the mesh PKI.
Considerations
A trust anchor which has not a self-signed certificate means that
trust anchor is authorized by another CA. In such a case, relying
parties may not recognize the revocation of the CA even if the
issuing CA publish the revocation information about that CA.
Therefore, this document recommends that relying party SHOULD trust
other self-signed CA. If there is no self-signed CA in that mesh,
such as what all CAs in the mesh certify with each other, relying
party SHOULD choose a trust anchor from those CAs carefully. For
example, relying party may choose a CA which is highly unlikely
that CA is revoked.
This model SHOULD be used sparingly, because of the complexity in
certification path building. However, one should not assume that
Shimaoka & Hastings [Page 19]
INTERNET DRAFT July 2005
this model does not exist or is implemented. A Full Mesh PKI,
which is one where all CAs in the PKI mutually cross-certify each
other directly, MAY be useful for certification path building,
because it is able to reach any prior PKI domain directly without
passing through another 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 |
+----+ +----+ +----+ +----+ +----+
Figure 7 - Mesh PKI model
6 multi-domain PKI
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 PKIs in a multi-domain PKI SHOULD apply
the following models.
Considerations
Multi-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 some distribution methods.
- Intermediate certificate
- Target certificate (optional)
- Revocation information for all certificates
For this, CAs MAY operate a repository, and SHOULD include
Shimaoka & Hastings [Page 20]
INTERNET DRAFT July 2005
authorityInfoAccess or cRLDistributionPoints extensions in the
certificates they issue to maximize PKI interoperability.
6.1 Multi Trust point model (based on Trust List)
The model in which a relying party trusts multiple PKI domains by a
trust list.
Considerations
If the owner of the trust list add a CA in the existing
certification path, it SHOULD do carefully since a constraints in
the certification path MAY NOT be evaluated correctly. The reason
is the following:
Assume certification path X->Y->Z->EE(Z) exists. When cross-
certificate X->Y includes pathLenConstraints=1, CA-Z cannot
extend the certification path started from CA-X by more cross
certificates. However, if the relying party trust CA-Y
directly, the cross certificate constraint in X->Y is ignored
allowing CA-Z to extend the certification path by more cross
certificates. Thus, relying party MUST recognize a risk of
trusting another CA directly.
Most of the actual public PKIs establish a multi-trust point model
without a domain policy. When using such public PKI, this document
recommends:
- user-initial-policy-set SHOULD NOT be specified, - and
initial-explicit-policy SHOULD NOT be true.
In general, since it is difficult for the EE to check if a CA's self-
signed certificate has been revoked, a CA SHOULD announce it to all
its EEs when the CA is compromised and MAY issue the CRL. Anyway,
for announcement to all its EEs, the CA SHOULD do the best: phoning,
emailing, press release, and etc. In the multi-trust point model, a
compromised trust anchor SHOULD be removed from the trust list, and
the removal SHOULD be performed by the subject managing the trust
list.
6.1.1 Based on User Trust List
Considerations
This is a simple and typical method for making a trust relationship
to another PKI domain. The relying party MUST understand the
certificate status of the trust anchor in the trust list.
Shimaoka & Hastings [Page 21]
INTERNET DRAFT July 2005
6.1.2 Based on Authority Trust List
Since there is no standard or established method to achieve
interoperability, 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 are related by Cross-
Certification. This cross-certification is either mutual or
unilateral. In this model, only one trust anchor is required by EEs.
Considerations
Each PKI domain MAY use policy mapping for crossing different PKI
domains. If a PKI domain wants to restrict a certification path,
the PKI domain SHOULD NOT rely on the validation policy of the
relying party, but SHOULD include the constraints in the cross-
certificate explicitly.
For example, when each PKI domain wants to effect 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 guarantee the constraints will
be recognized and followed.
6.2.1 Unified Domain model (based on unilateral Cross-Certification)
The model in which multiple 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. This model is used as
a method to unify or reconfigure the multiple PKI domains to one PKI
domain by subordinating the individual PKI domains. Except that
Principal CAs transformed into subordinate CAs have both self-signed
certificates and intermediate certificates issued by the Unificate
CA, this model looks like a subordination model with the Unificate CA
as the trust anchor across the PKI domains. Therefore, this model is
often 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| |
| Unificate CA | |
| to PKI 2 | |
Shimaoka & Hastings [Page 22]
INTERNET DRAFT July 2005
+-----------|---+ +-----------|---+ +----|-----------------+
| 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 - Unified Domain model
6.2.2 Bridge model
The model in which every PKI domain 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 useful in
reducing the number of cross-certifications required for a PKI domain
to interoperate with other PKI domains.
Requirements for Bridge model
- Bridge CA MUST NOT be used as the trust anchor in any PKI domain.
- Bridge CA SHOULD issue cross-certificates with other PKI domains
mutually or MAY issue cross certificates unilaterally.
- Bridge CA MUST NOT issue EE certificates except when it is
necessary for the CA's operation.
- Bridge CA MUST use its own domain policy in the policy mapping
between a prior PKI domain and a posterior PKI domain.
- The domain policy of Bridge CA MUST be a subset of the prior PKI
domain policy that is mapped.
- The domain policy of Bridge CA MUST be a superset of the
posterior PKI domain policy that is mapped.
Shimaoka & Hastings [Page 23]
INTERNET DRAFT July 2005
Cross-Certificate from prior PKI domain to Bridge CA
issuerDomainPolicy := Prior PKI domain policy
subjectDomainPolicy := Bridge CA domain policy
Cross-Certificate from Bridge CA to posterior PKI domain
issuerDomainPolicy := Bridge CA domain policy
subjectDomainPolicy := Posterior PKI domain policy
- Cross-Certificates issued by Bridge CA and Cross-Certificate
issued to Bridge CA SHOULD include the requireExplicitPolicy with a
value that is greater than zero in the policyConstaints extension.
- Cross-certificate issued to Bridge CA SHOULD include the
requireExplicitPolicy with a 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.
- PKI domains cross-certified with Bridge CA SHOULD NOT cross-
certify directly to other PKI domains cross-certified with the same
Bridge CA.
- Bridge CA SHOULD clarify the method for the policy mapping of
cross-certification to keep its transparency.
Considerations
The Bridge CA SHOULD be operated by neutral trusted third party
agreed upon by the PKIs or consortium consisting of the PKIs. The
Bridge CA SHOULD do policy mapping in a well documented and agreed
upon manner with all 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 Bridge CA perform the policy mapping via its own
domain policy?
- Does the Bridge CA clarify the method of policy mapping in
cross-certification?
- Is the Bridge CA able to accept the domain policy that the
prior PKI domain desires?
* If the domain policy is mapped to one with a lower
security level, the prior PKI domain SHOULD NOT accept it.
Otherwise, the prior PKI domain MUST carefully consider the
risks involved with accepting certificates with a lower
security level.
cross-certified cross-certified
PKI 1 with BCA +-----------+ PKI3 with BCA
+------->| Bridge CA |<------+
Shimaoka & Hastings [Page 24]
INTERNET DRAFT July 2005
| +-----------+ |
| ^ |
| 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 - Bridge model
7 Operational Considerations
This chapter explains the issues one needs to consider about the
management of cross-certificate(s) 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
issuedByThisCA := cross-certificate for CA-Y issued by CA-X
Shimaoka & Hastings [Page 25]
INTERNET DRAFT July 2005
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 for the 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 CA SHOULD NOT store a subordinate CA certificate in its
own entry for the forward path building. A subordinate CA MAY
store its own subordinate CA certificate to the issuedToThisCA
element of the crossCertificatePair attribute in its own
(subordinate CA) entry for the forward path building. A
subordinate CA MUST store its own subordinate CA certificate to the
cACertificate attribute in its own entry.
7.2 Cross-Certification
When updating the Cross-Certificate:
There is standard method for what to do when a cross-certificate
is updated by modifying some of its contents, e.g., policy
identifier
Shimaoka & Hastings [Page 26]
INTERNET DRAFT July 2005
When issuer CA-X re-issues a cross-certificate to subject CA-Y
before the issued 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, the change of cross-
certification is not reflected completely in certification
paths. In addition, CA-X MUST revoke the old cross-certificate
to CA-Y when CA-X does not intend to enable the old cross-
certificate. The reason why both CAs MUST update each
crossCertificatePair is relying party may use the issuedToThisCA
attribute of the crossCertificatePair (in subject CA-Y entry of
the repository) for tracing the certification path.
When updating the CA keypair:
When a CA issues a set of self-issued certificates for key
rollover, update of the cross-certificate is able to have a
migration period up to the expiration of the originally issued
self-issued certificate.
When the keypair of subject CA is compromised:
When the keypair of subject CA-Y is compromised, issuer CA-X
MUST revoke the cross-certificate for subject CA-Y, then CA-X
SHOULD remove the crossCertificatePair attribute for CA-Y from
its repository.
7.3 Providing Directory Information Across PKI-domains
The directory infrastructures used by individual PKI domains to
distribute certificates and CRLs usually consist of either a set of
interconnected or stand alone directories.
An interconnected directory infrastructure connects directories via
the use of a directory protocol such as chaining, replicating, or
shadowing. An interconnected directory infrastructure allows relying
parties to reduce the number of directories they need to be aware of
in order to obtain certificates and CRLs. However, this technique
MAY lead to infrastructure propagation delays as directory
information is updated or changes.
Directory infrastructures composed of stand alone directories
provides certificate and CRL information from a set (list) of
directories the relying parties is aware of. If a directory that is
queried but cannot satisfy the request, it MAY provide referrals to
another directory might be able to provide the requested information.
Shimaoka & Hastings [Page 27]
INTERNET DRAFT July 2005
To help promote interoperability, PKI domains SHOULD provide access
to the PKI domainfs directory infrastructure via LDAP or HTTP and
information to access (e.g. IP address or FQDN) at least one of the
PKI domainfs directories. EE SHOULD be able to process LDAP
referrals in order to operate with a set of stand alone directories.
8 Security Considerations
8.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. All
Certificates and CRLs MUST comply with [RFC 3280]. In addition, CAs
in multi-domain PKI SHOULD consider the following for the Certificate
and CRL profile:
* Extensions intended for processing only by a local PKI domain
SHOULD be non-critical.
* The cRLDistributionPoint extension SHOULD be used for obtaining
the revocation list. distributionPoint field SHOULD include also
the UniformResourceIdentifier. When the CRL is separated into ARL
and CRL, the issuingDistributionPoint extension SHOULD also be
used.
* The Authority Key Identifier extension and Subject Key Identifier
extension SHOULD be used for assisting 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 for 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 a
single authority allowing for the possibility of a name space
conflict. If a name space conflict exists, the name constraint
extension MAY unintentionally exclude a PKI domain.
If a PKI domain uses the name constraints in multi-domain PKI,
the PKI domain SHOULD pay attention for conflicts in PKI domain
name spaces.
8.2 Path Validation
Validation policy used for path validation is the intersection of
authority-constrained parameters and user-constrained parameters. An
authority constrained parameter SHOULD NOT assume the validation
policy of a relying party, but SHOULD be included in the certificates
explicitly.
A Relying party MUST carefully determine their validation policies,
including the trust anchor.
Shimaoka & Hastings [Page 28]
INTERNET DRAFT July 2005
8.3 Asymmetric problem
8.3.1 Hybrid trust model
This clause considers the case in which PKI domains trust each other
by different trust relationship models such as user trust lists and
unilateral cross-certification trust models.
Inter-domain trust relationships do not have to be symmetric. Since
inter-domain trust relationships in this document are defined as
directional trust relationships, there is no additional requirement
for a hybrid trust model. What each PKI domain does is merely the
same as a symmetric trust relationship model. For example when PKI
domain-X trusts PKI domain-Y by the user trust list model and PKI
domain-Y trusts PKI domain-X by unilateral cross-certification; PKI
domain-X merely has to comply with the user trust list model, and PKI
domain-Y with the unilateral cross-certification model.
8.3.2 Asymmetric policy mapping
This clause considers the case where a result of the policy mapping
in mutual cross-certification model is asymmetric. This document
does not strongly recommend using asymmetric mapping because the
following unequivalent mapping often derives a security hole.
+-------+ cP-1.1 := cP-2.1 +-------+
| |------------------->| |
| PCA 1 | | PCA 2 |
| |<-------------------| |
+-------+ cP-2.1 := cP-1.2 +-------+
Figure 10 - Asymmetric policy mapping
When path building allows the certification path to loop, then cP-1.1
is mapped to cP-1.2, and such a policy mapping MAY derive an
unforeseen security hole in the certification path. 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 PKI actually describes
different policies, differing policy identifiers mapped unexpectedly
in the same entity represents a critical security issue.
To prevent such a security hole, a loop certification path, one where
the same DN appears twice and non-continuously on one certification
path MUST NOT be allowed.
9 References
Shimaoka & Hastings [Page 29]
INTERNET DRAFT July 2005
9.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.
9.2 Informative References
Housley, R. and Polk, W., JOHN WILEY & SONS, INC., "Planning for PKI",
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.
10 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.
Shimaoka & Hastings [Page 30]
INTERNET DRAFT July 2005
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).
11 Author's Address
Masaki SHIMAOKA
SECOM Co., Ltd. Intelligent Systems Lab.
SECOM SC Center, 8-10-16, Shimorenjaku
Mitaka, Tokyo 181-8528
JAPAN
Email: shimaoka@secom.ne.jp / m-shimaoka@secom.co.jp
Nelson E. Hastings
NIST
100 Bureau Drive, Stop 8930
Gaithersburg, MD 20899-8930
USA
EMail: nelson.hastings@nist.gov
12 Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
Shimaoka & Hastings [Page 31]
INTERNET DRAFT July 2005
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Shimaoka & Hastings [Page 32]