RFC 5217
Memorandum for Multi-Domain Public Key Infrastructure Interoperability
RFC 5217: Memorandum for Multi-Domain Public Key Infrastructure Interoperability 🎀
Okay bestie, come sit with me 💖 This RFC is all about how separate PKI domains, each running under its own policy, can actually trust each other ✨ The header is giving a lot: it's from the Network Working Group 🌸, published in July 2008 📅, and it's an Informational doc, so it's sharing info for the Internet community and is not a standard 🙈 Three authors wrote it: M. Shimaoka (the editor, marked Ed., from SECOM), N. Hastings (from NIST), and R. Nielsen (from Booz Allen Hamilton) 🫶 The header doesn't list anything it obsoletes or updates, so there's no drama there 💅
Status of This Memo 📣
This memo is here to provide information for the Internet community 💌 It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 🦋
Abstract ✨
The goal here is to set up a shared terminology framework and suggest the operational requirements of a Public Key Infrastructure (PKI) domain, so multiple PKI domains that each run under a distinct policy can interoperate 🔥 It explains how Certification Authorities (CAs) relate to each other, gives the definition and requirements for PKI domains, and walks through typical multi-domain PKI models 🧚
Table of Contents 📜
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Objective . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Document Outline . . . . . . . . . . . . . . . . . . . . . 3
2. Public Key Infrastructure (PKI) Basics . . . . . . . . . . . . 3
2.1. Basic Terms . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Relationships between Certification Authorities . . . . . 4
2.2.1. Hierarchical CA Relationships . . . . . . . . . . . . 5
2.2.2. Peer-to-Peer CA Relationships . . . . . . . . . . . . 6
2.3. Public Key Infrastructure (PKI) Architectures . . . . . . 7
2.3.1. Single CA Architecture . . . . . . . . . . . . . . . . 7
2.3.2. Multiple CA Architectures . . . . . . . . . . . . . . 8
2.4. Relationships between PKIs and Relying Parties . . . . . . 12
3. PKI Domain . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. PKI Domain Properties . . . . . . . . . . . . . . . . . . 13
3.2. Requirements for Establishing and Participating in PKI
Domains . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1. PKI Requirements . . . . . . . . . . . . . . . . . . . 13
3.2.2. PKI Domain Documentation . . . . . . . . . . . . . . . 14
3.2.3. PKI Domain Membership Notification . . . . . . . . . . 15
3.2.4. Considerations for PKIs and PKI Domains with
Multiple Policies . . . . . . . . . . . . . . . . . . 16
3.3. PKI Domain Models . . . . . . . . . . . . . . . . . . . . 16
3.3.1. Unifying Trust Point (Unifying Domain) Model . . . . . 16
3.3.2. Independent Trust Point Models . . . . . . . . . . . . 17
3.4. Operational Considerations . . . . . . . . . . . . . . . . 21
4. Trust Models External to PKI Relationships . . . . . . . . . . 22
4.1. Trust List Models . . . . . . . . . . . . . . . . . . . . 22
4.1.1. Local Trust List Model . . . . . . . . . . . . . . . . 22
4.1.2. Trust Authority Model . . . . . . . . . . . . . . . . 23
4.2. Trust List Considerations . . . . . . . . . . . . . . . . 24
4.2.1. Considerations for a PKI . . . . . . . . . . . . . . . 24
4.2.2. Considerations for Relying Parties and Trust
Authorities . . . . . . . . . . . . . . . . . . . . . 24
4.2.3. Additional Considerations for Trust Authorities . . . 25
5. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 25
6.1. PKI Domain Models . . . . . . . . . . . . . . . . . . . . 25
6.2. Trust List Models . . . . . . . . . . . . . . . . . . . . 26
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.1. Normative References . . . . . . . . . . . . . . . . . . . 27
7.2. Informative References . . . . . . . . . . . . . . . . . . 271. Introduction 🌈
1.1. Objective
The goal is to set up a terminology framework and provide operational requirements that different Public Key Infrastructure (PKI) authorities can use when they're thinking about building trust relationships with each other 🤝 The doc defines the different kinds of trust relationships that are possible, flags the design and implementation considerations that PKIs should implement to make cross-PKI trust easier, and points out issues to think about when putting those trust relationships in place 💜 It defines terminology and interoperability requirements for multi-domain PKIs from one perspective. A PKI domain can reach multi-domain PKI interoperability by following the requirements in this document, but there are other ways to define and realize it too 🦋
1.2. Document Outline
Section 2 covers the PKI basics, which set the scene for multi-domain PKI 📖 Section 3 defines 'PKI domain', lays out its requirements, and describes the typical models of multi-domain PKI 🧚 Section 4 looks at the Trust List Models, depending on relationships between relying parties and CAs (not CA-CA trust relationships, since those aren't the focus of this document) 💅 Section 5 lists the abbreviations used in the document ✨
2. Public Key Infrastructure (PKI) Basics 🔐
2.1. Basic Terms
These are the terms used throughout this document. Where it was possible, the definitions come from RFC 4949 [RFC4949] 📚
- Certificate: a digitally signed data structure that attests to a system entity's identity being bound to a public key value (this one's based on the public key certificate definition in RFC 4949 [RFC4949]).
- Certificate Policy: a named set of rules showing where a certificate applies: a particular community and/or class of application with shared security requirements (X.509 [CCITT.X509.2000]). Heads up, to avoid confusion, this document uses "Certificate Policy Document" for the doc that defines the rules, and "Policy Object Identifier (OID)" for one specific rule set 👀
- Certificate Policy Document: a document that defines the rules for issuing and managing certificates and identifies Policy Object Identifiers (OIDs) for those rules. One of these can define more than one Policy OID 📄
- Policy Object Identifier (Policy OID): an identifier attached to a set of rules that govern issuing and managing certificates. Policy OIDs are defined in the Certificate Policy Documents 🏷️
- Certification Authority (CA): an entity that issues certificates (especially X.509 certificates) and vouches for the binding between the data items in a certificate (RFC 4949 [RFC4949]) 🏛️
- End Entity (EE): a system entity that's the subject of a certificate and uses, or is allowed and able to use, the matching private key only for a purpose other than signing a certificate. In other words, an entity that is not a CA (RFC 4949 [RFC4949]) 🙋♀️
- Relying party: a system entity that depends on the validity of information, like another entity's public key value, that a certificate provides (from the RFC 4949 [RFC4949] definition of certificate user) 🫶
2.2. Relationships between Certification Authorities
CAs set up trust relationships by issuing certificates to other CAs 🤩 CA relationships come in two flavours: 'certification hierarchy' [RFC4949] and 'cross-certification' [RFC4949] 💫
In a certification hierarchy there are two types of CAs: 'superior CA' and 'subordinate CA', as described in RFC 4949 [RFC4949] 👑
- Superior CA: a CA that is an issuer of a subordinate CA certificate.
A cross-certification can be either unilateral or bilateral 💕
- Unilateral cross-certification: one CA (CA1) gets cross-certified by another CA (CA2), but CA2 does not get cross-certified by CA1.
- Bilateral cross-certification: one CA (CA1) gets cross-certified by another CA (CA2), and CA2 also gets cross-certified by CA1.
2.2.1. Hierarchical CA Relationships 🌳
In a hierarchical relationship, as shown in Figure 1, one CA takes on a parent role to the other CA 🌸
+----+
| CA |
+----+
|
v
+----+
| CA |
+----+Figure 1: Hierarchical CA Relationship
There are two kinds of hierarchical relationships, depending on whether a subordinate CA certificate or a unilateral cross-certificate gets used. When one (superior) CA issues a subordinate CA certificate to another, the CA at the top of the hierarchy, which must itself have a self-signed certificate, is called a root CA 🌟 When one CA issues unilateral cross-certificates to other CAs, the CA doing the issuing is called a Unifying CA 🦋 Unifying CAs only use unilateral cross-certificates ✨
NOTE: In this document, the definition of root CA follows the second definition (context for hierarchical PKI) of 'root CA' in RFC 4949 [RFC4949]. This document uses the terminology 'trust anchor CA' for the first definition (context for PKI) of 'root CA' in RFC 4949.
- Root CA: a CA that sits at the top of a hierarchy and itself should not issue certificates to end entities (except those required for its own operation), but issues subordinate CA certificates to one or more CAs 👑
- Subordinate CA: a CA whose public key certificate is issued by another superior CA, and which itself must not be used as a trust anchor CA 🌱
- Unifying CA: a CA that sits at the top of a hierarchy and itself should not issue certificates to end entities (except those required for its own operation), but establishes unilateral cross-certification with other CAs. A Unifying CA must permit the CAs to which it issues cross-certificates to have self-signed certificates 🧚♀️
2.2.2. Peer-to-Peer CA Relationships 🦋
okay so in a peer relationship, no parent-child relationship gets made at all 🙅♀️ 💅 the only tool you use to set one up is cross-certificates. peer relationships can be unilateral or bilateral, as shown in Figure 2. ✨
Bilateral
Unilateral Cross-Certification
Cross-Certification +----+ +----+
+----+ +----+ | | ---> | |
| CA | ---> | CA | | CA | | CA |
+----+ +----+ | | <--- | |
+----+ +----+
Figure 2: Peer-to-Peer CA Relationshipsnow, if a CA only exists to manage cross-certificates, it gets the name Bridge CA 🌉🫶 CAs can set up unilateral or bilateral cross-certification with a Bridge CA, as shown in Figure 3.
Bridge CA: A CA that, itself, does not issue certificates to end entities (except those required for its own operation) but establishes unilateral or bilateral cross-certification with other CAs.
Bilateral
Cross-Certification
+----+ ----------+ +--------- +----+
| CA | | | | CA |
+----+ <-------+ | | +------> +----+
| v v |
+-----------+
| Bridge CA |
+-----------+
+----+ | | +----+
| CA | <-------+ +-------> | CA |
+----+ Unilateral +----+
Cross-Certification
Figure 3: Bridge CA2.3. Public Key Infrastructure (PKI) Architectures 🏛️✨
the big umbrella term here is the Public Key Infrastructure (PKI) 👑 it's a system of CAs that handle certificate management, archive management, key management, and token management for a community of users using asymmetric cryptography. the CAs share trust relationships, operate under the same Certificate Policy Document (which specifies a shared set of Policy OID(s)), and are either run by a single organization or under the direction of a single organization.
Public Key Infrastructure (PKI): A system of CAs that perform some set of certificate management, archive management, key management, and token management functions for a community of users in an application of asymmetric cryptography and share trust relationships, operate under the same Certificate Policy Document specifying a shared set of Policy OID(s), and are either operated by a single organization or under the direction of a single organization.
also, a PKI that wants to enter into trust relationships with other PKIs must designate a Principal CA (PCA) to manage all of those trust relationships 🧚 this Principal CA should also be the trust anchor CA for the PKI's relying parties.
Principal CA (PCA): A CA that should have a self-signed certificate is designated as the CA that will issue cross-certificates to Principal CAs in other PKIs, and may be the subject of cross-certificates issued by Principal CAs in other PKIs.
when we talk about the different possible PKI architectures, we need the idea of a certification path 🛤️ it gets built from the trust relationships between CAs.
Certification Path: An ordered sequence of certificates where the subject of each certificate in the path is the issuer of the next certificate in the path. A certification path begins with a trust anchor certificate and ends with an end entity certificate.
2.3.1. Single CA Architecture 🌸
the simplest one 🥹 Definition: A simple PKI consists of a single CA with a self-signed certificate that issues certificates to End Entities (EEs), as shown in Figure 4.
+----+
| CA |
+----+
|
+------+-----+
v v v
+----+ +----+ +----+
| EE | | EE | | EE |
+----+ +----+ +----+
Figure 4: Simple PKI ArchitectureTrust anchor CA: The trust anchor CA must be the CA that has a self-signed certificate.
Principal CA: Since this PKI architecture has one CA, the Principal CA must be that CA.
2.3.2. Multiple CA Architectures 💖
2.3.2.1. Hierarchical PKI Architecture 🌳
Definition: A hierarchical PKI consists of a single root CA and one or more subordinate CAs that issue certificates to EEs. A hierarchical PKI may have intermediate CAs, which are subordinate CAs that themselves have subordinate CAs. The root CA must distribute a trust anchor (public key and associated data), but the format and protocol are irrelevant for this specification. And all subordinate CAs must have subordinate CA certificates, as shown in Figure 5.
Trust anchor CA: The trust anchor CA must be the root CA.
Principal CA: The Principal CA must be the root CA.
+---------+
| Root CA |
+---------+
|
+------------+------------+
v v
+----+ +----+
| CA | | CA |
+----+ +----+
| |
+------+------+ +--------+-------+
v v v v v
+----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | CA | | CA |
+----+ +----+ +----+ +----+ +----+
| |
+---+--+ +------+------+
v v v v v
+----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | EE | | EE |
+----+ +----+ +----+ +----+ +----+
Figure 5: Hierarchical PKI Architecture2.3.2.2. Mesh PKI Architectures 🕸️🦋
Definition: A mesh PKI consists of multiple CAs with self-signed certificates that issue certificates to EEs and issue cross-certificates to each other. A mesh PKI may be a full mesh, where all CAs issue cross-certificates to all other CAs, as shown in Figure 6. A mesh PKI may also be a partial mesh, where all CAs do not issue cross-certificates to all other CAs. In a partial mesh PKI, certification paths may not exist from all CAs to all other CAs, as shown in Figure 7.
+--------- +-----+ <--------+
| | CA1 | |
| +------> +-----+ -------+ |
| | | | |
| | +---+--+ | |
| | v v | |
| | +----+ +----+ | |
| | | EE | | EE | | |
| | +----+ +----+ | |
v | v |
+-----+ ----------------> +-----+
| CA2 | | CA3 |
+-----+ <---------------- +-----+
| |
+---+--+ +------+------+
v v v v v
+----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | EE | | EE |
+----+ +----+ +----+ +----+ +----+
Figure 6: Full Mesh PKI Architecture
+--------- +-----+
| | CA1 | --------+
| +------> +-----+ |
| | | |
| | +---+--+ |
| | v v |
| | +----+ +----+ |
| | | EE | | EE | |
| | +----+ +----+ |
v | v
+-----+ +-----+
| CA2 | ----------------> | CA3 |
+-----+ +-----+
| |
+---+--+ +------+------+
v v v v v
+----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | EE | | EE |
+----+ +----+ +----+ +----+ +----+
Figure 7: Partial Mesh PKI ArchitectureTrust anchor CA: The trust anchor CA for an end entity is usually the CA that issued the end entity's certificate. The trust anchor CA for an end entity that is not issued a certificate from the mesh PKI may be any CA in the PKI. In a partial mesh, selection of the trust anchor may result in no certification path from the trust anchor to one or more CAs in the mesh. For example, in Figure 7 above, the selection of CA1 or CA2 as the trust anchor CA will result in paths from all end entities in the figure. However, the selection of CA3 as the trust anchor CA will result in certification paths only for those EEs whose certificates were issued by CA3. No certification path exists to CA1 or CA2.
Principal CA: The Principal CA may be any CA within the mesh PKI. However, the mesh PKI must have only one Principal CA, and a certification path should exist from the Principal CA to all other CAs within the mesh PKI.
Considerations: This model should be used sparingly, especially the partial mesh model, because of the complexity of determining trust anchors and building certification paths. A full mesh PKI may be useful for certification path building because paths of length one exist from all CAs to all other CAs in the mesh. 🚨💀
2.3.2.3. Hybrid PKI Architectures ✨
Definition: okay so a hybrid PKI is a PKI that mixes two vibes: the pure hierarchical model (using subordinate CA certificates) and the pure mesh model (using cross-certificates). Two models, one PKI 💅
+-----+ <----- +-----+
| CA2 | | CA1 |
+-----+ -----> +-----+
| |
+---+--+ +---+--+-------+
v v v v v
+----+ +----+ +----+ +----+ +-----+
| EE | | EE | | EE | | EE | | CA3 |
+----+ +----+ +----+ +----+ +-----+
|
+------+------+
v v v
+----+ +----+ +----+
| EE | | EE | | EE |
+----+ +----+ +----+
Figure 8: Hybrid PKI ArchitectureTrust anchor CA: the trust anchor CA for a hybrid PKI may be any CA with self-issued certificates in the hybrid PKI. However, because a hybrid PKI can get seriously complex, the PKI should give relying parties some guidance on picking a trust anchor 🫶. A relying party may fail to build an appropriate certification path to a subscriber if they choose an inappropriate trust anchor, and that is a whole mess 😭.
Principal CA: the Principal CA may be any CA within the hybrid PKI and should have a self-signed certificate for cross-certification with other PKI domains. However, the hybrid PKI must have only one Principal CA, and a certification path must exist from the Principal CA to every CA within the PKI 👑.
Considerations: this model should be used sparingly, because figuring out trust anchors and building certification paths is a lot 💀. Still, hybrid PKIs may show up as a PKI evolves over time, like when CAs inside an organization team up and become a single PKI 🌈.
2.4. Relationships between PKIs and Relying Parties
Relying Parties set up trust by trust anchor to a PKI 🦋. Relying Parties may use a Trust List to establish trust relationships with one or more PKIs. A Trust List is a set of one or more trust anchors for trusting one or more PKIs.
There are two maintenance models for a Trust List: the Local Trust List Model and the Trust Authority Model. Both are described in detail in Section 4.1 🌸.
3. PKI Domain ✨
Two or more PKIs may choose to enter into trust relationships with each other 🫶. In these relationships, each PKI keeps its own set of Certificate Policy OIDs and its own Principal CA. Making the business decision to consider a trust relationship is only part of it. Each PKI also decides how much to trust each external PKI by reviewing the external PKI's Certificate Policy Document(s) and any other PKI governance documentation, through a process called policy mapping 🔍. Trust relationships are technically formalized by issuing cross-certificates. A collection of two or more PKIs like this is known as a PKI domain 💜.
PKI domain: a set of two or more PKIs that have chosen to enter into trust relationships with each other through the use of cross-certificates. Each PKI that has entered the PKI domain is considered a member of that PKI domain.
NOTE: This definition specifies a PKI domain recursively in terms of its constituent domains and associated trust relationships. That is different from the definition in RFC 4949 [RFC4949], which gives PKI domain as a synonym for CA domain and defines it in terms of a CA and its subject entities.
Domain Policy Object Identifier: a domain Policy Object Identifier (OID) is a Policy OID that is shared across a PKI domain. Each CA in the PKI domain must be operated under the domain Policy OID. Each CA may also have its own Policy OID(s) in addition to the domain Policy OID. When it does, the CA must comply with both policies. The domain Policy OID is used to identify the PKI domain 🎀.
Policy Mapping: a process by which members of a PKI domain evaluate the Certificate Policies (CPs) and other governance documentation of other potential PKI domain members. The goal is to work out how much trust each PKI in the PKI domain places on certificates issued by each other PKI in the PKI domain 🧚.
3.1. PKI Domain Properties
- A PKI domain may operate a Bridge CA or a Unifying CA that defines members of the domain by issuing cross-certificates to those members ✨.
- A single PKI may simultaneously belong to two or more PKI domains 🦋.
- A PKI domain may contain PKI domains within its own membership 🌈.
- Two or more PKI domains may enter into a trust relationship with each other, creating a new PKI domain. They may choose to keep the existing PKI domains alongside the new PKI domain, or collapse the existing PKI domains into the new PKI domain 👑.
- A member of a PKI domain may choose to participate in the PKI domain but restrict or deny trust in one or more other member PKIs of that same PKI domain 💅.
3.2. Requirements for Establishing and Participating in PKI Domains
Trust relationships have a direct impact on the trust model of relying parties 👀. So the creation and maintenance of PKI domains need careful thought, to prevent creating inadvertent trust relationships 🚨.
3.2.1. PKI Requirements
For a PKI to participate in one or more PKI domains, that PKI must have the following:
- A Certificate Policy Document documenting the requirements for operation of that PKI. The Certificate Policy Document should be in RFC 3647 [RFC3647] format 📄.
- One or more Policy OIDs defined in the Certificate Policy Document that are also asserted in all certificates issued by that PKI 🏷️.
- A defined Principal CA 👑.
PKI domains may also impose additional technical, documentation, or policy requirements for membership 💜.
When participating in a PKI domain, the domain Policy OID(s) must be asserted at least in cross-certificates issued by a participating PKI. After participating, the PKI can assert the domain Policy OID(s) in certificates it issues, or it may map the domain Policy OID(s) to the Policy OID(s) asserted in its own certificates 🦋.
3.2.2. PKI Domain Documentation
PKI domains must be formally defined and documented. The documentation may vary a lot depending on the PKI domain 📚. However, it must:
- Establish the existence of the PKI domain;
- Define the authority for maintaining the PKI domain;
- Examples of PKI domain Authorities are (1) representatives from two PKIs that agree to form a simple PKI domain, (2) a single entity that may or may not be related to any of the PKIs in the PKI domain, and (3) a governance board made up of representatives from each PKI domain member 🧑⚖️.
- Define how the PKI domain is governed;
- Define the purpose and community of interest of the PKI domain; and
- Examples of PKI domain intents are (1) allowing relying parties of one PKI to trust certificates issued by another PKI, (2) allowing PKIs that support similar subscriber communities of interest to interact with each other, and (3) allowing relying parties to trust certificates issued by a number of PKIs that all meet a set of requirements 🌸.
- Unless the PKI domain has a predetermined membership, describe the requirements and methods for joining the PKI domain, such as FPKIMETHOD [FPKIMETHOD] 🚪.
Examples of governance documents that PKI domains may choose to use are:
- Statement of intent between two or more parties;
- Memorandum of Agreement between two or more parties;
- Certificate Policy Document for the PKI domain;
- Charter for the PKI domain; or
- Methodology for PKI domain membership 📜.
3.2.3. PKI Domain Membership Notification
A cross-certificate from the Principal CA of one PKI to the Principal CA of another PKI indicates a mapping between one or more policies of the first PKI and one or more policies of the second PKI 🔗. When a relying party is figuring out whether a certificate can be validated, it builds a certification path from the presented certificate to a trust anchor 🕵️♀️. To prevent inadvertent trust relationships across PKI domains when a single PKI belongs to two or more disparate PKI domains, each PKI domain must be aware of which PKI domains its member PKIs take part in. Figure 9 shows this concept 🦋.
+-----------------------------+
| PKI domain 2 |
+----------------------------+ |
| | | |
| +------+ <------ +------+ <------ +------+ |
| | PKI1 | | | PKI2 | | | PKI3 | |
| +------+ ------> +------+ ------> +------+ |
| | | |
| +-----------------------------+
| PKI domain 1 |
+----------------------------+
Figure 9: Participation in Multiple PKI DomainsAs Figure 9 shows, PKI2 is a member of both PKI domain 1 and PKI domain 2 🌈. Since a certification path exists from PKI1 to PKI2, and from PKI2 to PKI3, a certification path also exists from PKI1 to PKI3. However, PKI1 does not share domain membership with PKI3, so certification path validation from PKI1 to PKI3 with a validation policy for PKI domain 1 must not succeed 🙈. To ensure correct certification path validation and policy mapping, the cross-certificates issued by both PKI1 and PKI3 to PKI2 must contain constraints, such as policy mapping or name constraints, that disallow the validation of certification paths outside their respective domains 🔒.
To fully prevent inadvertent trust, any PKI that is a member of one or more PKI domains must inform all of those PKI domains of its membership in all other PKI domains. That PKI must also inform all of those PKI domains of which it is a member any time its membership status changes with regard to any other PKI domain 📣. If a PKI domain is informed of a change in status of one of its member PKIs with regard to other PKI domains, that PKI domain must review the constraints in any cross-certificate issued to that PKI. If the change in membership would change the allowed or disallowed certification paths, the PKI domain must ensure that all such cross-certificates are revoked and re-issued with correct constraints 💖.
3.2.4. Considerations for PKIs and PKI Domains with Multiple Policies 💅
okay so, a single PKI might issue certs at more than one assurance level 👀. If it does, the Certificate Policy Document must define separate Policy OIDs for each assurance level, and must define the differences between certificates of different assurance levels 📝.
A PKI domain can also support more than one assurance level 🫶. If it does, the PKI domain must also define separate Policy OIDs for each assurance level, and must define the differences in requirements for each level 💖.
When PKIs and PKI domains choose to establish trust relationships, those relationships may exist for only one defined assurance level, may have a one-to-one relationship between PKI assurance levels and PKI domain assurance levels, or may have many-to-one or one-to-many relationships between assurance levels 🦋. These relationships must be defined in cross-certificates issued between PKIs in the PKI domain 🔥.
3.3. PKI Domain Models 🌈
two or more PKI domains may choose to enter into trust relationships with each other, and that's giving collab energy 🤝. In that case, they may form a larger PKI domain by establishing a new Unifying or Bridge CA, or by issuing cross-certificates between their Principal CAs ✨.
3.3.1. Unifying Trust Point (Unifying Domain) Model 👑
in the Unifying Trust Point Model, a PKI domain is created by establishing a joint, superior CA that issues unilateral cross-certificates to each PKI domain, as shown in Figure 10 🧚. That joint, superior CA is called a Unifying CA, and the Principal CAs in each PKI domain have the hierarchical CA relationship with that Unifying CA 🎀. In this model, any relying party from any of the PKI domains must specify the Unifying CA as its trust anchor CA in order to validate a subscriber in the other PKI domains 🚨. If the relying party doesn't want to validate subscribers in other PKI domains, it may keep using the Principal CA from the old PKI domain as its trust anchor CA 🍓.
this model may be used for merging multiple PKI domains into a single PKI domain with less change to existing PKI domains, or it may be used to combine multiple PKI domains into one PKI domain for relying parties 💜. The unilateral cross-certificate that the Unifying CA issues to the Principal CAs in each PKI domain may include any policy mapping 🌸.
Cross-certified Cross-certified
Unifying CA Unifying CA
to PKI domain 1 +--------------+ to PKI domain 3
+---------| Unifying CA |---+
| +--------------+ |
| | |
| Cross-certified| |
| Unifying CA | |
| to PKI domain 2| |
+-----------|---+ +-----------|---+ +----|-----------------+
| PKI | | | PKI | | | | PKI |
| domain 1 | | | domain 2 | | | | domain 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 10: Unifying Trust Point (Unifying Domain) Model3.3.2. Independent Trust Point Models 🦋
in Independent Trust Point Models, relying parties keep using only the trust anchor of their PKI domain 💅. A relying party in the individual trust point model can keep using the trust anchor of its PKI domain, no drama 🫶.
3.3.2.1. Direct Cross-Certification Model 🔥
in this model, each PKI domain trusts each other by issuing a cross-certificate directly between each Principal CA, as shown in Figure 11 🌈. This model may be used for shortening a certification path or establishing a trust relationship expeditiously ⭐.
Considerations: a PKI domain in this model needs to take into account that the other PKI domain may cross-certify with any other 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 💖. A PKI domain that relies on the validation policy of the relying party about such constraints cannot guarantee that the constraints will be recognized and followed 💀.
+---------------+ +------------------------+
| PKI | cross-certified | PKI |
| domain 1 | each other | domain 2 |
| +-----+ --------------------> +-----+ ----+ |
| | PCA | | | | PCA | | |
| +-----+ <-------------------- +-----+ <-+ | |
| | | | ^ | v |
| | | | | +----+ |
| | | | | | CA |---+ |
| | | | | +----+ | |
| v | | v ^ | | |
| +----+ | | +----+ | | | |
| +---| CA | | | | CA |--+ | | |
| | +----+ | | +----+ | | |
| | | | | | | | |
| v v | | v v v |
| +----+ +----+ | | +----+ +----+ +----+ |
| | EE | | EE | | | | EE | | EE | | EE | |
| +----+ +----+ | | +----+ +----+ +----+ |
+---------------+ +------------------------+
Figure 11: Direct Cross-Certification Model3.3.2.2. Bridge Model
okay so in this model, every PKI domain trusts each other through a Bridge CA 🌉 by cross-certification (see Figure 12 💅). the trust relationship isn't set up directly between a subscriber domain and a relying party domain 🙅♀️. instead it's established from the Principal CA of the relying party's PKI domain, going through a Bridge CA. this is lowkey amazing because it cuts down on how many cross-certifications a PKI domain needs to interoperate with other PKI domains ✨
Requirements for Bridge model:
- The Bridge CA MUST NOT be used as the trust anchor CA in any PKI domain. 🚫
- The Bridge CA SHOULD issue cross-certificates with other PKI domains mutually, or MAY issue cross-certificates unilaterally. 🤝
- The Bridge CA MUST NOT issue End Entity (EE) certificates except when it is necessary for the CA's operation. 🙅♀️
- The Bridge CA MUST use its own domain Policy OID, not other PKI domain Policy OID(s), for the policy mapping. 🎀
- The Bridge CA SHOULD be in a neutral position to all PKI domains which trust through the Bridge CA. 👑 For example, in Figure 12, say a relying party trusts the PCA of PKI domain 1 as its trust anchor CA and builds the certification path to a subscriber in PKI domain 3. it's giving:
Cross-Certificate from PKI domain 1 to the Bridge CA:
issuerDomainPolicy ::= domain Policy OID of PKI domain 1
subjectDomainPolicy := domain Policy OID of the Bridge CA
Cross-Certificate from the Bridge CA to PKI domain 3:
issuerDomainPolicy ::= domain Policy OID of the Bridge CA
subjectDomainPolicy ::= domain Policy OID of PKI domain 3- Cross-certificates issued by the Bridge CA and cross-certificates issued to the Bridge CA SHOULD include the requireExplicitPolicy with a value that is greater than zero in the policyConstraints extension, because a relying party may not set the initial-explicit-policy to TRUE. 🧐
- PKI domains cross-certified with the Bridge CA SHOULD NOT cross-certify directly to other PKI domains cross-certified with the same Bridge CA. 🙈
- The Bridge CA SHOULD clarify the method for the policy mapping of cross-certification to keep it transparent. 🔍
Considerations: The Bridge CA SHOULD be operated by an independent third party agreed upon by the PKI domains, or by a consortium made up of representatives from the PKI domain members. 🏛️ The Bridge CA SHOULD do policy mapping in a well-documented and agreed-upon manner with all PKI domains. when applying the name constraints, the Bridge CA needs to avoid creating conflicts between the name spaces of the cross-certified PKI domains. ⚠️ The PKI domains that do cross-certification with the Bridge CA SHOULD confirm the following:
- Does the Bridge CA perform the policy mapping via its own domain Policy OID? 🤔
- Does the Bridge CA clarify the method of policy mapping in the cross-certification? 🤔
- Is the Bridge CA able to accept the domain policy that the PKI domain desires? 🫶
- If the domain policy is mapped to one with a lower security level, the PKI domain SHOULD NOT accept it. Otherwise, the PKI domain MUST carefully consider the risks involved with accepting certificates with a lower security level. 💀
- Is the Bridge CA able to accept the domain policy that the PKI domain desires? 🫶
Here's the picture 🖼️ (Figure 12):
cross-certified cross-certified
PKI domain 1 with BCA PKI domain 3 with BCA
+---------> +-----------+ -----+
| | Bridge CA | |
| +-------- +-----------+ <--+ |
| | ^ | | |
| | cross-certified | | | |
| | PKI domain 2 | | | |
| | with BCA | | | |
+---------|-|---+ +-----------|-|-+ +--|-|-----------------+
| PKI | | | | PKI | | | | | | PKI |
|domain 1 | v | | domain 2 | v | | | v domain 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 12: Bridge Model3.4. Operational Considerations
okay so each PKI domain MAY use policy mapping when crossing different PKI domains. 🌈 if a PKI domain wants to restrict a certification path, it SHOULD NOT rely on the validation policy of the relying party. instead it SHOULD include the constraints in the cross-certificate explicitly. 📝
for example, when each PKI domain wants to affect the constraints on 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't guarantee the constraints will be recognized and followed 😭
4. Trust Models External to PKI Relationships ✨
as opposed to PKI domain trust relationships that PKIs set up themselves, trust across multiple PKIs can be created by entities outside the PKIs, through locally configured lists of trust anchors. 🦋
- Trust List: A set of one or more trust anchors used by a relying party to explicitly trust one or more PKIs. 📋
note that Trust Lists are often created without the knowledge of the PKIs that are included in the list. 👀
4.1. Trust List Models
4.1.1. Local Trust List Model
a Trust List can be created and maintained by a single relying party for its own use. 🧚
- Local Trust List: A Trust List installed and maintained by a single relying party for its own use. NOTE: This definition is similar to "trust-file PKI" defined in RFC 4949 [RFC4949]. However, this document prefers the term "Local Trust List" in contrast with "Trust Authority" defined below. 🤓
Figure 13 illustrates a Local Trust List. 🖼️
+-------------------------------------------------------------+
| Relying party |
| +---------------------------------------------------------+ |
| | Trust List | |
| | +--------------+ +--------------+ +--------------+ | |
| | | PKI 1 | | PKI 2 | ... | PKI n | | |
| | | Trust anchor | | Trust anchor | | Trust anchor | | |
| | +--------------+ +--------------+ +--------------+ | |
| +---------------------------------------------------------+ |
+-------------------------------------------------------------+
Figure 13: Relying Party Local Trust List Modelcreating a Local Trust List is the simplest method for relying parties to trust EE certificates ✨ using Local Trust Lists doesn't require cross-certification between the PKI that issued the relying party's own certificate and the PKI that issued the EE's certificate, nor does it require implementing mechanisms for processing complex certification paths, since all CAs in a path can be included in the Local Trust List. 🙌 as a result, Local Trust Lists are the most common model in use today 💖 however, because Local Trust Lists are created and managed independently by each relying party, they can be really hard for an enterprise to manage 😩
4.1.2. Trust Authority Model
alternatively, a Trust List can be created and maintained for use by multiple relying parties. 🌸 in this case, the entity responsible for the Trust List is known as a Trust Authority. 👑
- Trust Authority: An entity that manages a Trust List for use by one or more relying parties. 🫶
Figure 14 illustrates a Trust Authority and how it is used by Relying Parties. note that the Trust Authority replaces the PKI trust anchor(s) in the Local Trust List for each participating relying party. 💜
+-------------------------------------------------------------+
| Trust Authority |
| +---------------------------------------------------------+ |
| | Trust List | |
| | +--------------+ +--------------+ +--------------+ | |
| | | PKI 1 | | PKI 2 | ... | PKI n | | |
| | | Trust anchor | | Trust anchor | | Trust anchor | | |
| | +--------------+ +--------------+ +--------------+ | |
| +---------------------------------------------------------+ |
+-------------------------------------------------------------+
+---------------------+ +---------------------+
| Relying party 1 | | Relying party 2 |
| +-----------------+ | | +-----------------+ | ...
| | Trust Authority | | | | Trust Authority | |
| +-----------------+ | | +-----------------+ |
+---------------------+ +---------------------+
Figure 14: Trust Authority Modela Trust Authority may be operated by a PKI, a collection of relying parties that share a common set of users, an enterprise on behalf of all of its relying parties, or an independent entity 🏢 although PKIs generally set up trust relationships through cross-certificates, a PKI may choose to provide a Trust Authority to support relying parties that don't support processing of certification paths 🔧 a collection of relying parties that share a common set of users may choose to maintain a single Trust Authority to make managing Trust Lists simpler 🧩 an enterprise may choose to provide a Trust Authority to implement enterprise policies and direct all Relying Parties within the enterprise to use its Trust Authority 📋 and finally, an independent entity may choose to operate a Trust Authority as a managed service ☁️
4.2. Trust List Considerations
4.2.1. Considerations for a PKI 🎀
Okay so, a PKI should publish its Certificate Policy Document so that Relying Parties and Trust Authorities can figure out what, if any, warranties the PKI gives for relying on EE certificates. Transparency is the whole vibe here 💅
A PKI should also broadly publicize information about revocation or compromise of a trust anchor CA or Principal CA certificate. It can post a notice on a web page, put out a press release, and/or use other appropriate mechanisms. That way Relying Parties and Trust Authorities can tell whether a trust anchor CA or Principal CA certificate sitting in a Trust List should be removed 🫶
A PKI should publish Certificate Revocation Lists (CRLs) or other information about the revocation status of EE certificates to a repository. The repository needs to be reachable by any party that wants to rely on those EE certificates ✨
4.2.2. Considerations for Relying Parties and Trust Authorities 🧚
Relying Parties and Trust Authorities are responsible for the following before they include a PKI in the Trust List 👑
- Reviewing the Certificate Policy Document of each PKI to confirm that the PKI is operated to an acceptable level of assurance 🔥
- Reviewing the Certificate Policy Document of each PKI to make sure any requirements imposed on Relying Parties are met 💖
- Figuring out whether the PKI provides any warranties about relying on EE certificates, and whether those warranties are acceptable for the intended reliance on the EE certificates. Reliance may be at the relying party's own risk 😭
- Periodically checking the information the PKI publishes to its repository, including Certificate Policy Document updates or notices of CA revocation or compromise 🌸
A PKI can choose to join or leave PKI domains in accordance with its Certificate Policy Document. If the relying party or Trust Authority does not want to inherit trust in other members of those PKI domains, then it's on the relying party or Trust Authority to inhibit policy mapping. Main character responsibility, bestie 🦋
4.2.3. Additional Considerations for Trust Authorities 🌈
A Trust Authority should establish a Trust Authority Policy that covers the following:
- The intended community of Relying Parties that will use the Trust Authority 🍓
- The process by which trust anchors are added or removed from the Trust List 🫶
- Any warranties provided by the Trust Authority for reliance on EE certificates. These warranties may be the ones provided by the PKIs themselves, or they may be additional warranties provided by the Trust Authority 💅
- Information about how the Trust Authority protects the integrity of its Trust List 🔥
- Information about how Relying Parties interact with the Trust Authority to find out whether an EE certificate is trusted ✨
5. Abbreviations 📚
- CA: Certification Authority
- EE: End Entity
- OID: Object Identifier
- PCA: Principal Certification Authority
- PKI: Public Key Infrastructure
6. Security Considerations 🔐
This section highlights security considerations related to establishing PKI domains. Serious business, so read carefully 💀
6.1. PKI Domain Models 🌸
For all PKI domain models described in Section 3.3 that are created through the issuance of cross-certificates, standard threats including message insertion, modification, and man-in-the-middle are not applicable. Why? Because all information created by CAs, including policy mapping and constraints, is digitally signed by the CA that generated the cross-certificate 🔒
Verifying that a given certificate was issued by a member of a PKI domain may be a time-critical determination. If cross-certificates and revocation status information cannot be obtained in a timely manner, the end entity may experience a denial of service. When that verification is critical, caching cross-certificates and revocation status information may be warranted 😭
An additional security consideration for PKI domains is creating inadvertent trust relationships. This can happen if a single PKI is a member of multiple PKI domains. See Section 3.2.3 for a discussion of creating inadvertent trust relationships and the mechanisms to prevent it 🙈
Finally, members of PKI domains must participate in domain governance or, at a minimum, be informed any time a PKI joins or leaves the domain. That way domain members can make appropriate decisions about maintaining their own membership in the domain, or about choosing to restrict or deny trust in the new member PKI 👑
6.2. Trust List Models 🦋
In these models, many standard attacks are not applicable, since certificates are digitally signed. Additional security considerations do apply when trust is created through a Trust List 💜
A variation of the modification attack is possible in Trust List Models. If an attacker is able to add or remove CAs from the relying party's or Trust Authority's Trust List, the attacker can affect which certificates will or will not be accepted. To prevent this attack, access to Trust Lists must be adequately protected against unauthorized modification. This protection is especially important for trust anchors that are used by multiple applications, because that's a key vulnerability of this model. The attack may result in unauthorized usage if a CA is added to a Trust List, or in denial of service if a CA is removed from a Trust List 😱
For Trust Authority models, a denial-of-service attack is also possible if the application cannot obtain timely information from the trust anchor. Applications should specify service-level agreements with the Trust Authority. In addition, applications may choose to locally cache the list of CAs maintained by the Trust Authority as a backup, in case the trust anchor's repository (for example, a Lightweight Directory Access Protocol (LDAP) directory) is not available 🫶
7. References 📖
7.1. Normative References 🔥
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen,
S., Housley, R., and W. Polk, "Internet X.509
Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile",
RFC 5280, May 2008.7.2. Informative References ✨
[CCITT.X509.2000] International Telephone and Telegraph Consultative
Committee, "Information Technology - Open Systems
Interconnection - The Directory: Authentication
Framework", CCITT Recommendation X.509,
March 2000.
[FPKIMETHOD] "US Government PKI Cross-Certification Criteria
and Methodology", January 2006, <http://
www.cio.gov/fpkia/documents/
crosscert_method_criteria.pdf>.
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C.,
and S. Wu, "Internet X.509 Public Key
Infrastructure Certificate Policy and
Certification Practices Framework", RFC 3647,
November 2003.
[RFC4949] Shirey, R., "Internet Security Glossary, Version
2", RFC 4949, August 2007.Authors' Addresses 🎀
Masaki Shimaoka (editor)
SECOM Co., Ltd. Intelligent System Laboratory
SECOM SC Center, 8-10-16 Shimorenjaku
Mitaka, Tokyo 181-8528
JP
EMail: m-shimaoka@secom.co.jp
Nelson Hastings
National Institute of Standard and Technology
100 Bureau Drive, Stop 8930
Gaithersburg, MD 20899-8930
US
EMail: nelson.hastings@nist.gov
Rebecca Nielsen
Booz Allen Hamilton
8283 Greensboro Drive
McLean, VA 22102
US
EMail: nielsen_rebecca@bah.comFull Copyright Statement ⚖️
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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
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.📦 where this page comes from
- ietf: rfc5217 2008-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms