RFC 3647

RFC 3647 🎀 Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework

okay bestie, this is RFC 3647 💖 It was published in November 2003 and it's Informational, so it's giving "here's some super helpful guidance" energy, not a formal standard ✨ It obsoletes RFC 2527, which means it replaces that older doc 💅 No updates are listed in the header.

The squad behind it 🫶

• S. Chokhani, Orion Security Solutions, Inc.
• W. Ford, VeriSign, Inc.
• R. Sabett, Cooley Godward LLP
• C. Merrill, McCarter & English, LLP
• S. Wu, Infoliance, Inc.

---

Status of this Memo 📝

this memo gives info to the Internet community 🦋 It does not specify an Internet standard of any kind, and distribution of this memo is unlimited ✨

Copyright Notice ©

Copyright (C) The Internet Society (2003). All Rights Reserved. 💜

Abstract 💅

okay so this doc is a framework to help people writing certificate policies or certification practice statements 🎀 It's for folks in public key infrastructures, like certification authorities, policy authorities, and communities of interest that want to rely on certificates. The main thing? It gives a comprehensive list of topics that might need to be covered in a certificate policy or a certification practice statement, and the writer decides what's actually relevant 🌸 It also supersedes RFC 2527, so that one's officially retired, bestie 🫶

Table of Contents 🧚

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
    1.1.  Background . . . . . . . . . . . . . . . . . . . . . . .  4
    1.2.  Purpose. . . . . . . . . . . . . . . . . . . . . . . . .  5
    1.3.  Scope. . . . . . . . . . . . . . . . . . . . . . . . . .  6
2.  Definitions. . . . . . . . . . . . . . . . . . . . . . . . . .  6
3.  Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
    3.1.  Certificate Policy . . . . . . . . . . . . . . . . . . .  9
    3.2.  Certificate Policy Examples. . . . . . . . . . . . . . . 11
    3.3.  X.509 Certificate Fields . . . . . . . . . . . . . . . . 12

          3.3.1.  Certificate Policies Extension . . . . . . . . . 12
          3.3.2.  Policy Mappings Extension. . . . . . . . . . . . 13
          3.3.3.  Policy Constraints Extension . . . . . . . . . . 13
          3.3.4.  Policy Qualifiers. . . . . . . . . . . . . . . . 14
    3.4.  Certification Practice Statement . . . . . . . . . . . . 15
    3.5.  Relationship Between CP and CPS. . . . . . . . . . . . . 16
    3.6.  Relationship Among CPs, CPSs, Agreements, and
          Other Documents. . . . . . . . . . . . . . . . . . . . . 17
    3.7.  Set of Provisions. . . . . . . . . . . . . . . . . . . . 20
4.  Contents of a Set of Provisions. . . . . . . . . . . . . . . . 21
    4.1.  Introduction . . . . . . . . . . . . . . . . . . . . . . 22
          4.1.1.  Overview . . . . . . . . . . . . . . . . . . . . 22
          4.1.2.  Document Name and Identification . . . . . . . . 22
          4.1.3.  PKI Participants . . . . . . . . . . . . . . . . 23
          4.1.4.  Certificate Usage. . . . . . . . . . . . . . . . 24
          4.1.5.  Policy Administration. . . . . . . . . . . . . . 24
          4.1.6.  Definitions and Acronyms . . . . . . . . . . . . 24
    4.2.  Publication and Repository Responsibilities. . . . . . . 25
    4.3.  Identification and Authentication (I&A). . . . . . . . . 25
          4.3.1.  Naming . . . . . . . . . . . . . . . . . . . . . 25
          4.3.2.  Initial Identity Validation. . . . . . . . . . . 26
          4.3.3.  I&A for Re-key Requests. . . . . . . . . . . . . 27
          4.3.4.  I&A for Revocation Requests. . . . . . . . . . . 27
    4.4.  Certificate Life-Cycle Operational Requirements. . . . . 27
          4.4.1.  Certificate Application. . . . . . . . . . . . . 28
          4.4.2.  Certificate Application Processing . . . . . . . 28
          4.4.3.  Certificate Issuance . . . . . . . . . . . . . . 28
          4.4.4.  Certificate Acceptance . . . . . . . . . . . . . 29
          4.4.5.  Key Pair and Certificate Usage . . . . . . . . . 29
          4.4.6.  Certificate Renewal. . . . . . . . . . . . . . . 30
          4.4.7.  Certificate Re-key . . . . . . . . . . . . . . . 30
          4.4.8.  Certificate Modification . . . . . . . . . . . . 31
          4.4.9.  Certificate Revocation and Suspension. . . . . . 31
          4.4.10. Certificate Status Services. . . . . . . . . . . 33
          4.4.11. End of Subscription. . . . . . . . . . . . . . . 33
          4.4.12. Key Escrow and Recovery. . . . . . . . . . . . . 33
    4.5.  Facility, Management, and Operational Controls . . . . . 33
          4.5.1.  Physical Security Controls . . . . . . . . . . . 34
          4.5.2.  Procedural Controls. . . . . . . . . . . . . . . 35
          4.5.3.  Personnel Controls . . . . . . . . . . . . . . . 35
          4.5.4.  Audit Logging Procedures . . . . . . . . . . . . 36
          4.5.5.  Records Archival . . . . . . . . . . . . . . . . 37
          4.5.6.  Key Changeover . . . . . . . . . . . . . . . . . 38
          4.5.7.  Compromise and Disaster Recovery . . . . . . . . 38
          4.5.8.  CA or RA Termination . . . . . . . . . . . . . . 38
    4.6.  Technical Security Controls. . . . . . . . . . . . . . . 39
          4.6.1.  Key Pair Generation and Installation . . . . . . 39
          4.6.2.  Private Key Protection and Cryptographic

                  Module Engineering Controls. . . . . . . . . . . 40
          4.6.3.  Other Aspects of Key Pair Management . . . . . . 42
          4.6.4.  Activation Data. . . . . . . . . . . . . . . . . 42
          4.6.5.  Computer Security Controls . . . . . . . . . . . 42
          4.6.6.  Life Cycle Security Controls . . . . . . . . . . 43
          4.6.7.  Network Security Controls. . . . . . . . . . . . 43
          4.6.8.  Timestamping . . . . . . . . . . . . . . . . . . 43
    4.7.  Certificate, CRL, and OCSP Profiles. . . . . . . . . . . 44
          4.7.1.  Certificate Profile. . . . . . . . . . . . . . . 44
          4.7.2.  CRL Profile. . . . . . . . . . . . . . . . . . . 44
          4.7.3.  OCSP Profile . . . . . . . . . . . . . . . . . . 44
    4.8.  Compliance Audit and Other Assessment. . . . . . . . . . 45
    4.9.  Other Business and Legal Matters . . . . . . . . . . . . 45
          4.9.1.  Fees . . . . . . . . . . . . . . . . . . . . . . 46
          4.9.2.  Financial Responsibility . . . . . . . . . . . . 47
          4.9.3.  Confidentiality of Business Information. . . . . 47
          4.9.4.  Privacy of Personal Information. . . . . . . . . 48
          4.9.5.  Intellectual Property Rights . . . . . . . . . . 48
          4.9.6.  Representations and Warranties . . . . . . . . . 48
          4.9.7.  Disclaimers of Warranties. . . . . . . . . . . . 49
          4.9.8.  Limitations of Liability . . . . . . . . . . . . 49
          4.9.9.  Indemnities. . . . . . . . . . . . . . . . . . . 49
          4.9.10. Term and Termination . . . . . . . . . . . . . . 50
          4.9.11. Individual notices and communications
                  with participants. . . . . . . . . . . . . . . . 50
          4.9.12. Amendments . . . . . . . . . . . . . . . . . . . 50
          4.9.13. Dispute Resolution Procedures. . . . . . . . . . 51
          4.9.14. Governing Law. . . . . . . . . . . . . . . . . . 51
          4.9.15. Compliance with Applicable Law . . . . . . . . . 51
          4.9.16. Miscellaneous Provisions . . . . . . . . . . . . 51
          4.9.17. Other Provisions . . . . . . . . . . . . . . . . 53
5.  Security Considerations. . . . . . . . . . . . . . . . . . . . 53
6.  Outline of a Set of Provisions . . . . . . . . . . . . . . . . 53
7.  Comparison to RFC 2527 . . . . . . . . . . . . . . . . . . . . 60
8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 88
9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 88
10. Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
12. List of Acronyms . . . . . . . . . . . . . . . . . . . . . . . 91
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 92
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 94

---

1. Introduction ✨

1.1. Background 💖

Okay so, a public-key certificate (we're calling it "certificate" from here on, bestie) basically binds a public key held by an entity to a bunch of info that identifies that entity, the one using the matching private key. The entity can be a person, organization, account, device, or site. For most identity certificates, that entity is called the "subject" or "subscriber" 🎀 Two exceptions are devices, where the subscriber is usually the individual or organization controlling the device, and anonymous certificates, where the identity isn't available from the certificate itself 🙈 Other certificates bind public keys to attributes that aren't identity, like a role, a title, or creditworthiness info ✨

A certificate gets used by a "certificate user" or "relying party" who needs to use it and rely on the binding between the subject's public key and the subject's identity and/or other attributes inside the certificate being accurate 🦋 Relying parties are often entities that verify a digital signature from the subject, where the signature is attached to an email, web form, electronic document, or other data. Other examples: someone sending encrypted email to the subscriber, a web browser user trusting a server certificate during a secure sockets layer (SSL) session, or an entity running a server that controls access to online info using client certificates as its access control 💅 So basically, a relying party is any entity that uses a public key in a certificate, for signature verification and/or encryption.

How much a relying party can trust that binding depends on a bunch of stuff 👑 It can depend on the practices the certification authority (CA) follows when authenticating the subject, the CA's operating policy, procedures, and security controls, the scope of the subscriber's responsibilities (like protecting the private key, for example), and the CA's stated responsibilities and liability terms and conditions (like warranties, disclaimers of warranties, and limitations of liability). Trust is a whole vibe, periodt 😭

A Version 3 X.509 certificate can contain a field saying that one or more specific certificate policies apply to it [ISO1] 🌈 According to X.509, a certificate policy (CP) is "a named set of rules that indicates the applicability of a certificate to a particular community and/or class of applications with common security requirements." A relying party can use a CP to help decide whether a certificate, and the binding in it, is trustworthy enough and otherwise right for a particular application 🧚 The CP idea grew out of the policy statement concept developed for Internet Privacy Enhanced Mail [PEM1] and was expanded on in [BAU1]. The legal and liability stuff in Section 4.9 came from a team effort between the IETF PKIX working group and American Bar Association (ABA) members who worked on making digital signatures and the role of PKI legally accepted. Iconic teamwork, no cap ⭐

A more detailed explanation of how a CA issues and manages certificates may live in a certification practice statement (CPS), which the CA publishes or references 🍓 According to the American Bar Association Information Security Committee's Digital Signature Guidelines (hereinafter "DSG")(1) and the Information Security Committee's PKI Assessment Guidelines (hereinafter "PAG")(2), "a CPS is a statement of the practices which a certification authority employs in issuing certificates." [ABA1, ABA2] CPSs usually cover practices for all certificate lifecycle services (like issuance, management, revocation, and renewal or re-keying), plus other business, legal, and technical details 💜 The terms in a CP or CPS may or may not be binding on a PKI's participants as a contract. A CP or CPS can even claim to be a contract itself. More commonly though, an agreement incorporates a CP or CPS by reference and tries to bind the parties to some or all of its terms. For example, some PKIs use a CP or (more commonly) a CPS that's incorporated by reference into the agreement between a subscriber and a CA or RA (called a "subscriber agreement"), or the agreement between a relying party and a CA (called a "relying party agreement" or "RPA") 🫶 Other times, a CP or CPS has no contractual significance at all, and a PKI may intend them to be strictly informational or disclosure documents. Just vibes, no legal weight 🌸

---

1.2. Purpose 🎀

This document has two goals, bestie ✨ First, it explains what a CP and a CPS are, the differences between them, and how they relate to subscriber and relying party agreements. Second, it gives a framework to help the people writing and using certificate policies or CPSs draft and understand those documents 💅 Specifically, the framework lays out the elements that may need to be considered when formulating a CP or a CPS. It is not here to define particular certificate policies or CPSs, per se 🙈 And this document doesn't offer legal advice or recommendations about particular requirements or practices that should go in CPs or CPSs. (Such recommendations, however, appear in [ABA2].) Those are in the ABA's lane, not ours 🦋

---

1.3. Scope 🌈

The scope is limited to the topics that can be covered in a CP (as defined in X.509) or a CPS (as defined in the DSG and PAG) 🧚 Specifically, this document describes the types of information that should be considered for inclusion in a CP or a CPS. The framework generally assumes use of the X.509 version 3 certificate format for providing identity assurances, but the material isn't meant to be restricted to that format or to identity certificates 💖 Instead, the framework is meant to be adaptable to other certificate formats, and to certificates that provide assurances other than identity, which may come into use later. Adaptable era, periodt 🌟

The scope does not extend to defining security policies in general (like organization security policy, system security policy, or data labeling policy) 🍓 Also, this document doesn't define a specific CP or CPS. And in presenting a framework, it should be viewed and used as a flexible tool that presents topics of particular relevance to CPs or CPSs, not as a rigid formula for producing them 🫶 Think of it as a menu, not a recipe 💅

This document assumes the reader is already familiar with the general concepts of digital signatures, certificates, and public-key infrastructure (PKI), as used in X.509, the DSG, and the PAG 👑 If that's you, slay, let's keep going 🔥

2. Definitions ✨

okay so this section is the glossary bestie, and we're gonna go through it together 🎀 Only the terms that show up in this document get defined here, and the definitions are a little formal, but I'm translating them for you 💅

Activation data - Data values, other than keys, that are required to operate cryptographic modules and that need to be protected (e.g., a PIN, a passphrase, or a manually-held key share). 🔐 Basically the secret stuff that isn't a key but still keeps the crypto module running.

Authentication - The process of establishing that individuals, organizations, or things are who or what they claim to be. ✨ In the context of a PKI, authentication can be the process of establishing that an individual or organization applying for or seeking access to something under a certain name is, in fact, the proper individual or organization. This corresponds to the second process involved with identification, as shown in the definition of "identification" below. Authentication can also refer to a security service that provides assurances that individuals, organizations, or things are who or what they claim to be or that a message or other data originated from a specific individual, organization, or device. Thus, it is said that a digital signature of a message authenticates the message's sender. 💖 So a digital signature is how you prove who actually sent the message, periodt.

CA-certificate - A certificate for one CA's public key issued by another CA. 🦋

Certificate policy (CP) - A named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements. 👑 For example, a particular CP might indicate applicability of a type of certificate to the authentication of parties engaging in business-to-business transactions for the trading of goods or services within a given price range. It's giving rulebook for who a certificate is meant for 📖

Certification path - An ordered sequence of certificates that, together with the public key of the initial object in the path, can be processed to obtain that of the final object in the path. 🌸 It's a chain of certificates you walk down, one link at a time.

Certification Practice Statement (CPS) - A statement of the practices that a certification authority employs in issuing, managing, revoking, and renewing or re-keying certificates. 🧚 This is the how-we-actually-do-it doc.

CPS Summary (or CPS Abstract) - A subset of the provisions of a complete CPS that is made public by a CA. 🍓 The highlights reel of the CPS, shared publicly.

Identification - The process of establishing the identity of an individual or organization, i.e., to show that an individual or organization is a specific individual or organization. In the context of a PKI, identification refers to two processes:

(1) establishing that a given name of an individual or organization corresponds to a real-world identity of an individual or organization, and

(2) establishing that an individual or organization applying for or seeking access to something under that name is, in fact, the named individual or organization. A person seeking identification may be a certificate applicant, an applicant for employment in a trusted position within a PKI participant, or a person seeking access to a network or software application, such as a CA administrator seeking access to CA systems. 🔍 So two checks: is this name a real person or org, and is the person showing up under that name actually them? Iconic 🙈

Issuing certification authority (issuing CA) - In the context of a particular certificate, the issuing CA is the CA that issued the certificate (see also Subject certification authority). 🎀 The one who signed the paperwork.

Participant - An individual or organization that plays a role within a given PKI as a subscriber, relying party, CA, RA, certificate manufacturing authority, repository service provider, or similar entity. 🫶 Basically everyone in the PKI squad.

PKI Disclosure Statement (PDS) - An instrument that supplements a CP or CPS by disclosing critical information about the policies and practices of a CA/PKI. A PDS is a vehicle for disclosing and emphasizing information normally covered in detail by associated CP and/or CPS documents. Consequently, a PDS is not intended to replace a CP or CPS. 💅 It's the cheat sheet that points at the important stuff, not a replacement for the big docs.

Policy qualifier - Policy-dependent information that may accompany a CP identifier in an X.509 certificate. Such information can include a pointer to the URL of the applicable CPS or relying party agreement. It may also include text (or number causing the appearance of text) that contains terms of the use of the certificate or other legal information. 🌈 Extra notes that can ride along with the CP ID, like a link or some legal fine print.

Registration authority (RA) - An entity that is responsible for one or more of the following functions: the identification and authentication of certificate applicants, the approval or rejection of certificate applications, initiating certificate revocations or suspensions under certain circumstances, processing subscriber requests to revoke or suspend their certificates, and approving or rejecting requests by subscribers to renew or re-key their certificates. RAs, however, do not sign or issue certificates (i.e., an RA is delegated certain tasks on behalf of a CA). [Note: The term Local Registration Authority (LRA) is sometimes used in other documents for the same concept.] 🧚‍♀️ The RA does the vetting and paperwork, but it never signs the certificate itself. That's the CA's job, bestie.

Relying party - A recipient of a certificate who acts in reliance on that certificate and/or any digital signatures verified using that certificate. In this document, the terms "certificate user" and "relying party" are used interchangeably. 🦋 Anyone who trusts a certificate and acts on it.

Relying party agreement (RPA) - An agreement between a certification authority and relying party that typically establishes the rights and responsibilities between those parties regarding the verification of digital signatures or other uses of certificates. 📜 The contract between the CA and whoever's trusting its certs.

Set of provisions - A collection of practice and/or policy statements, spanning a range of standard topics, for use in expressing a CP or CPS employing the approach described in this framework. 🍰 A buffet of standard statements you can mix and match.

Subject certification authority (subject CA) - In the context of a particular CA-certificate, the subject CA is the CA whose public key is certified in the certificate (see also Issuing certification authority). 💜 The CA getting vouched for.

Subscriber - A subject of a certificate who is issued a certificate. 🌸

Subscriber Agreement - An agreement between a CA and a subscriber that establishes the right and responsibilities of the parties regarding the issuance and management of certificates. ✨

Validation - The process of identification of certificate applicants. "Validation" is a subset of "identification" and refers to identification in the context of establishing the identity of certificate applicants. 💖 So validation is just identification, but specifically for people applying for certs.

---

3. Concepts 🌈

okay, this section is where we get into the real vibes. It explains what CP and CPS are, and how they connect to other PKI docs like subscriber agreements and relying party agreements 🫶 A few other related concepts show up too. Some of this stuff is specific to certificate policies extensions as defined in X.509 version 3. Everywhere else, this framework is meant to be adaptable to other certificate formats that might come along later 🦋

3.1. Certificate Policy 👑

When a certification authority issues a certificate, it's basically making a statement to a certificate user (aka a relying party) that a particular public key is bound to the identity and/or other attributes of a particular entity. That entity is the certificate subject, and it's usually also the subscriber. 💅 The extent to which the relying party should rely on that statement, though, has to be assessed by the relying party, or by whoever controls or coordinates how relying parties or their apps use certificates. Different certificates get issued using different practices and procedures, so they may suit different applications and/or purposes 🌸

The X.509 standard defines a CP as "a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements" [ISO1]. An X.509 Version 3 certificate may identify a specific applicable CP. A relying party can use that to decide whether or not to trust a certificate, its associated public key, or any digital signatures verified with that public key for a particular purpose 🔍

CPs usually fall into two big categories. 🎀 First, some CPs "indicate the applicability of a certificate to a particular community" [ISO1]. These CPs set out requirements for how the certificate gets used, plus requirements for the members of that community. For example, a CP might focus on the needs of a geographical community, like the ETSI policy requirements for CAs issuing qualified certificates [ETS]. A CP of this kind could also focus on a specific vertical-market community, like financial services [IDT] 💖

The second category of typical CPs "indicate the applicability of a certificate to a . . . class of application with common security requirements." 🔐 These CPs name a set of applications or uses for certificates and say those uses need a certain level of security. Then they lay out the PKI requirements that fit those uses. A CP in this category often sets requirements for a certain "level of assurance" the certificates provide, compared to certificates under related CPs. These levels of assurance may line up with "classes" or "types" of certificates 🧚‍♀️

For instance, the Government of Canada PKI Policy Management Authority (GOC PMA) has set up eight certificate policies in a single document [GOC]. That's four policies for certificates used for digital signatures and four for certificates used for confidentiality encryption 😭 For each of those applications, the document sets four levels of assurance: rudimentary, basic, medium, and high. The GOC PMA described certain types of digital signature and confidentiality uses in the document, each with its own set of security requirements, and grouped them into eight categories. Then it set PKI requirements for each of those categories, which creates eight types of certificates, each providing rudimentary, basic, medium, or high levels of assurance. Going from rudimentary up to high means the security requirements go up, and the level of assurance goes up with them 🌟

A CP gets represented in a certificate by a unique number called an "Object Identifier" (OID) 🍓 That OID, or at least an "arc", can be registered. An "arc" is the beginning of the numerical sequence of an OID, and it gets assigned to a particular organization. The registration process follows the procedures specified in ISO/IEC and ITU standards. The party that registers the OID or arc can also publish the text of the CP, so relying parties can take a look. Any one certificate will usually declare a single CP or, sometimes, be issued consistent with a small number of different policies. That declaration shows up in the Certificate Policies extension of a X.509 Version 3 certificate. When a CA puts multiple CPs in a certificate's Certificate Policies extension, the CA is asserting that the certificate is appropriate for use under any of the listed CPs 🌈

CPs also form the basis for an audit, accreditation, or some other assessment of a CA. Each CA can be assessed against one or more certificate policies or CPSs that it's recognized as implementing ✨ When one CA issues a CA-certificate for another CA, the issuing CA must assess the set of certificate policies it trusts the subject CA for. That assessment may be based on an assessment of the certificate policies involved. The assessed set of certificate policies then gets indicated by the issuing CA in the CA-certificate. The X.509 certification path processing logic uses these CP indications in its well-defined trust model 💜

3.2. Certificate Policy Examples ✨

okay so bestie, let's do a fun example 💅 pretend the International Air Transport Association (IATA) decides to define some certificate policies for the whole airline industry. It runs a PKI itself, and the individual airlines run their own PKIs alongside it 🛫 Two CPs might be defined: the IATA General-Purpose CP and the IATA Commercial-Grade CP 🎀

The IATA General-Purpose CP is for everyday stuff, like protecting routine information (think casual electronic mail) and authenticating connections from World Wide Web browsers to servers for general information retrieval 🌸 The key pairs may be generated, stored, and managed using low-cost, software-based systems, such as commercial browsers. Under this policy, a certificate may be automatically issued to anybody listed as an employee in the corporate directory of IATA or any member airline who submits a signed certificate request form to a network administrator in his or her organization. so low-effort, very accessible, very giving "anyone on the team gets one" energy 💖

The IATA Commercial-Grade CP is the serious one 😤 It could be used to protect financial transactions or binding contractual exchanges between airlines. Under this policy, IATA could require that certified key pairs be generated and stored in approved cryptographic hardware tokens. Certificates and tokens could be provided to airline employees with disbursement authority. These authorized individuals might then be required to present themselves to the corporate security office, show a valid identification badge, and sign a subscriber agreement requiring them to protect the token and use it only for authorized purposes, as a condition of being issued a token and a certificate. main character security checkpoint era 🔥🔐

3.3. X.509 Certificate Fields 🧚

the following extension fields in an X.509 certificate are used to support CPs:

• Certificate Policies extension;
• Policy Mappings extension; and
• Policy Constraints extension.

3.3.1. Certificate Policies Extension 📜

A Certificate Policies field lists CPs that the certification authority declares are applicable. Using the example of the IATA General-Purpose and Commercial-Grade policies defined in Section 3.2, the certificates issued to regular airline employees would contain the object identifier for General-Purpose policy. The certificates issued to the employees with disbursement authority would contain the object identifiers for both the General-Purpose policy and the Commercial-Grade policy. The inclusion of both object identifiers in the certificates means that they would be appropriate for either the General-Purpose or Commercial-Grade policies. The Certificate Policies field may also optionally convey qualifier values for each identified policy; the use of qualifiers is discussed in Section 3.4. 🫶

when processing a certification path, a CP that is acceptable to the relying party application must be present in every certificate in the path, i.e., in CA-certificates as well as end entity certificates. so it's not just the leaf, every single cert in the chain needs to show up with it 👑

if the Certificate Policies field is flagged critical, it serves the same purpose as described above but also has an additional role. Specifically, it indicates that the use of the certificate is restricted to one of the identified policies, i.e., the certification authority is declaring that the certificate must only be used in accordance with the provisions of at least one of the listed CPs. This field is intended to protect the certification authority against claims for damages asserted by a relying party who has used the certificate for an inappropriate purpose or in an inappropriate manner, as stipulated in the applicable CP. ngl this is the CA covering itself and it's iconic 💅

the critical flag is basically the CA's legal shield 🛡️ it says "use this cert only for the listed purposes" and if someone goes outside that, the CA can point to it.

for example, the Internal Revenue Service might issue certificates to taxpayers for the purpose of protecting tax filings. The Internal Revenue Service understands and can accommodate the risks of erroneously issuing a bad certificate, e.g., to an imposter. Suppose, however, that someone used an Internal Revenue Service tax-filing certificate as the basis for encrypting multi-million-dollar-value proprietary trade secrets, which subsequently fell into the wrong hands because of a cryptanalytic attack by an attacker who is able to decrypt the message. The Internal Revenue Service may want to defend itself against claims for damages in such circumstances by pointing to the criticality of the Certificate Policies extension to show that the subscriber and relying party misused the certificate. The critical-flagged Certificate Policies extension is intended to mitigate the risk to the CA in such situations. 😭 bestie the plot twist of using a tax cert to lock up trade secrets is wild, and the critical flag is the receipt that says "wrong tool, babe" 🙈

3.3.2. Policy Mappings Extension 🦋

The Policy Mappings extension may only be used in CA-certificates. This field allows a certification authority to indicate that certain policies in its own domain can be considered equivalent to certain other policies in the subject certification authority's domain.

for example, suppose that for purposes of facilitating interoperability, the ACE Corporation establishes an agreement with the ABC Corporation to cross-certify the public keys of each others' certification authorities for the purposes of mutually securing their respective business-to-business exchanges. Further, suppose that both companies have pre-existing financial transaction protection policies called ace-e-commerce and abc-e-commerce, respectively. One can see that simply generating cross-certificates between the two domains will not provide the necessary interoperability, as the two companies' applications are configured with, and employee certificates are populated with, their respective certificate policies. One possible solution is to reconfigure all of the financial applications to require either policy and to reissue all the certificates with both policies appearing in their Certificate Policies extensions. Another solution, which may be easier to administer, uses the Policy Mapping field. If this field is included in a cross-certificate for the ABC Corporation certification authority issued by the ACE Corporation certification authority, it can provide a statement that the ABC's financial transaction protection policy (i.e., abc-e-commerce) can be considered equivalent to that of the ACE Corporation (i.e., ace-e-commerce). With such a statement included in the cross-certificate issued to ABC, relying party applications in the ACE domain requiring the presence of the object identifier for the ace-e-commerce CP can also accept, process, and rely upon certificates issued within the ABC domain containing the object identifier for the abc-e-commerce CP. 🤝✨

3.3.3. Policy Constraints Extension 🌈

The Policy Constraints extension supports two optional features. The first is the ability for a certification authority to require that explicit CP indications be present in all subsequent certificates in a certification path. Certificates at the start of a certification path may be considered by a relying party to be part of a trusted domain, i.e., certification authorities are trusted for all purposes so no particular CP is needed in the Certificate Policies extension. Such certificates need not contain explicit indications of CP. When a certification authority in the trusted domain, however, certifies outside the domain, it can activate the requirement that a specific CP's object identifier appear in subsequent certificates in the certification path.

The other optional feature in the Policy Constraints field is the ability for a certification authority to disable policy mapping by subsequent certification authorities in a certification path. It may be prudent to disable policy mapping when certifying outside the domain. This can assist in controlling risks due to transitive trust, e.g., a domain A trusts domain B, domain B trusts domain C, but domain A does not want to be forced to trust domain C. 🙅‍♀️💜 the transitive trust thing is the group chat drama where "my friend trusts her friend" doesn't mean you have to too 💀

3.3.4. Policy Qualifiers 🍓

The Certificate Policies extension field has a provision for conveying, along with each CP identifier, additional policy-dependent information in a qualifier field. The X.509 standard does not mandate the purpose for which this field is to be used, nor does it prescribe the syntax for this field. Policy qualifier types can be registered by any organization.

The following policy qualifier types are defined in PKIX RFC 3280 [PKI1]:

(a) The CPS Pointer qualifier contains a pointer to a CPS, CPS Summary, RPA, or PDS published by the CA. The pointer is in the form of a uniform resource identifier (URI).

(b) The User Notice qualifier contains a text string that is to be displayed to subscribers and relying parties prior to the use of the certificate. The text string may be an IA5String or a BMPString - a subset of the ISO 100646-1 multiple octet coded character set. A CA may invoke a procedure that requires that the relying party acknowledge that the applicable terms and conditions have been disclosed and/or accepted.

Policy qualifiers can be used to support the definition of generic, or parameterized, CPs. Provided the base CP so provides, policy qualifier types can be defined to convey, on a per-certificate basis, additional specific policy details that fill in the generic definition. the qualifier field is like a customizable add-on, and the base policy is the foundation that makes it work 🎀✨

3.4. Certification Practice Statement 📜✨

okay so the term certification practice statement (CPS) gets defined by the DSG and PAG as: "A statement of the practices which a certification authority employs in issuing certificates." [ABA1, ABA2] 💅 As we said above, a CPS covers lifecycle stuff way beyond issuance, like certificate management (including publication and archiving), revocation, and renewal or re-keying. 🔄 The ABA adds some extra notes to that definition in the DSG:

"A certification practice statement may take the form of a declaration by the certification authority of the details of its trustworthy system and the practices it employs in its operations and in support of issuance of a certificate . . . ." This form of CPS is the most common type, and it can vary in length and level of detail. 🌸

Some PKIs don't need a super thorough, detailed statement of practices. 🙈 For example, the CA might be the relying party itself, so it already knows exactly how trustworthy its own services are. Other times, a PKI only hands out certificates with a very low level of assurance, where the apps being secured only face marginal risks if something gets compromised. 🍓 In those cases, an org setting up a PKI might only want its CAs to use a subscriber agreement, a relying party agreement, or one agreement that mixes subscriber and relying party terms, depending on what role each PKI participant plays. 🎀 In a PKI like that, the agreement can be the only "statement of practices" that one or more CAs use. So that agreement can also count as a CPS, and it can be titled or subtitled as one. ✨

Now, a detailed CPS can have sensitive details about the system, so a CA can choose not to publish its entire CPS. 🔐 Instead, it can publish a CPS Summary (or CPS Abstract). 🦋 The CPS Summary only holds the provisions from the CPS that the CA thinks matter to the people in the PKI (like who is responsible for what, or the stages of the certificate lifecycle). 💖 But it won't include the sensitive stuff from the full CPS that could give an attacker useful info about the CA's operations. Throughout this document, when we say "CPS," we mean both the detailed CPS and the CPS Summary (unless it's specified otherwise). 🫶

Here's the tea: CPSs don't automatically count as contracts, and they don't automatically bind PKI participants the way a contract would. 🙃 If one document is both a subscriber or relying party agreement and a CPS, then it's meant to be a contract, and it is a binding contract to the extent a subscriber or relying party agreement would normally count as one. 💜 Most CPSs, though, aren't doing that double job. So in most cases, a CPS's terms only act as contract terms if a separate document sets up a contractual relationship between the parties and that document incorporates part or all of the CPS by reference. 📎 And if a PKI uses a CPS Summary (instead of the whole CPS), that summary could be incorporated into any applicable subscriber or relying party agreement. 🌈

Looking ahead, a court or applicable statutory or regulatory law might decide that a certificate itself is a document that can create a contractual relationship. 🔮 That would apply to the extent its mechanisms for incorporation by reference (like the Certificate Policies extension and its qualifiers) show that terms for using it live in certain documents. 👑 For now though, some subscriber agreements and relying party agreements can incorporate a CPS by reference, which makes its terms binding on the parties to those agreements. 💅✨

---

3.5. Relationship Between Certificate Policy and Certification Practice Statement 🧚

okay this one is a whole vibe. The CP and CPS cover the same set of topics that the relying party cares about, meaning how much and for what purpose a public key certificate should be trusted. 🔥 Their main difference is what they focus on. A CP lays out the requirements and standards the PKI imposes on those topics. ✅ In other words, the CP is all about what participants must do. A CPS, on the flip side, explains how a CA and other participants in a given domain actually carry out procedures and controls to meet the requirements in the CP. 🛠️ In other words, the CPS is all about disclosing how participants do their jobs and put their controls in place. 🦋

Another difference is scope, meaning how far each kind of document reaches. 🌐 Since a CP is a statement of requirements, it's the best vehicle for sharing the minimum operating guidelines that interoperating PKIs have to meet. 🤝 So a CP usually applies to multiple CAs, multiple organizations, or multiple domains. A CPS, by contrast, only applies to a single CA or single organization, and it isn't usually a tool for making interoperation happen. 🙅‍♀️

A CA with one CPS can support multiple CPs (used for different application purposes and/or by different relying party communities). 💖 It also works the other way: multiple CAs, each with non-identical CPSs, can support the same CP. 🎀

For example, the Federal Government might define a government-wide CP for handling confidential human resources information. 🏛️ The CP would be a broad statement of the general requirements for participants in the Government's PKI, plus a note about what types of applications it's suitable for. 📋 Each department or agency that wants to run a certification authority in this PKI may be required to write its own certification practice statement to support this CP, by explaining how it meets the CP's requirements. 🫡 And a department's or agency's CPS might also support other certificate policies at the same time. 🌸

There's one more difference, and it's about detail. 🔍 The level of detail can vary between CPSs, but a CPS will generally be more detailed than a CP. A CPS gives a detailed description of the procedures and controls in place to meet the CP requirements, while a CP stays more general. 🧠

So the main differences between CPs and CPSs can be summed up like this: 💅

(a) A PKI uses a CP to set requirements that say what participants within it must do. A single CA or organization can use a CPS to disclose how it meets the requirements of a CP, or how it implements its practices and controls. 🌷

(b) A CP helps interoperation happen through cross-certification, unilateral certification, or other means. That's why it's meant to cover multiple CAs. A CPS, by contrast, is a statement of a single CA or organization. Its purpose isn't to facilitate interoperation, because that's the CP's job. 🤝

(c) A CPS is generally more detailed than a CP and specifies how the CA meets the requirements specified in the one or more CPs under which it issues certificates. 📝✨

Oh, and beyond filling in the certificate policies extension with the applicable CP object identifier, a certification authority may also include a reference to its certification practice statement in the certificates it issues. 🎀 There's a standard way to do that, using a CP qualifier, and it's described in Section 3.4. 💜

3.6. Relationship Among CPs, CPSs, Agreements, and Other Documents

okay so CPs and CPSs are the main stars when it comes to writing down what a PKI needs and how it actually runs 📝✨ but they're not the only docs in the group chat 🫶 subscriber agreements and relying party agreements are huge too, because they split up who is responsible for what when people use certificates and key pairs 💅 they set out the terms for how certificates get issued, managed, and used 🎀 The PAG defines a subscriber agreement as: "An agreement between a CA and a subscriber that establishes the right and obligations of the parties regarding the issuance and management of certificates." [ABA2] and a relying party agreement as: "An agreement between a certification authority and relying party that typically establishes the rights and obligations between those parties regarding the verification of digital signatures or other uses of certificates." [ABA2]

as we mentioned in Section 3.5, a subscriber agreement, a relying party agreement, or one agreement that mixes subscriber and relying party terms can also act as a CPS 🌸 other PKIs go a different route and have a subscriber or relying party agreement pull in some or all of the terms of a CP or CPS by reference 🔗 and some PKIs take the applicable terms out of a CP and/or CPS and drop them into a self-contained subscriber agreement, without referencing the CP or CPS at all 🧚 they can do the same thing for relying party terms in a self-contained relying party agreement 💖 the big perk of self-contained agreements is that they're way easier for consumers to actually read 📖 some subscribers or relying parties might count as "consumers" under applicable law, which means they get certain statutory or regulatory protections 🙈 and under the legal systems of civil law countries, incorporating a CP or CPS by reference may not be effective in binding consumers to the terms of that incorporated CP or CPS 😭

CPs and CPSs can be incorporated by reference in other documents too, including:

• Interoperability agreements (including agreements between CAs for cross-certification, unilateral certification, or other forms of interoperation),
• Vendor agreements (under which a PKI vendor agrees to meet standards set forth in a CP or CPS), or
• A PDS. See [ABA2]

a PDS has a similar vibe to a CPS Summary 🦋 it's a relatively short doc that only holds a subset of the critical details about a PKI or CA 💜 the difference is that a PDS is meant to summarize the overall nature of the PKI, rather than just being a condensed version of the CPS 🌈

its purpose is to distill information about the PKI, as opposed to protecting security sensitive information in an unpublished CPS, although a PDS could also do that job ✨

just like writers can refer to a CP or CPS, or pull it into an agreement or PDS by reference, a CP or CPS can point to other documents when it sets requirements or makes disclosures 🎀 for example, a CP might set requirements for certificate content by referring to an external document that lays out a standard certificate profile 💅 pointing to external docs means a CP or CPS can impose detailed requirements or make detailed disclosures without reprinting long provisions from other documents 🫶 it's also a super handy way to split things between public info and security sensitive confidential info (on top of or instead of publishing a CPS Summary) 🔐 say a PKI wants to publish its CP or CPS but keep the site construction parameters for its CA high security zones confidential 🙈 the CP or CPS could reference an external manual or document holding those detailed site construction parameters 🏰

documents a PKI may want to refer to in a CP or CPS include:

• A security policy,
• Training, operational, installation, and user manuals (which may contain operational requirements),
• Standards documents that apply to particular aspects of the PKI (such as standards specifying the level of protection offered by any hardware tokens used in the PKI or standards applicable to the site construction),
• Key management plans,
• Human resource guides and employment manuals (which may describe some aspects of personnel security practices), and
• E-mail policies (which may discuss subscriber and relying party responsibilities, as well as the implications of key management, if applicable). See [ABA2]

---

3.7. Set of Provisions

okay so a set of provisions is basically a collection of practice and/or policy statements 🍓 it covers a range of standard topics and is used to express a CP or CPS that follows the approach in this framework, by covering the topics listed in Section 5 below 💖 they're also described in detail in Section 4 below ✨

a CP can be written as a single set of provisions 🌸

a CPS can be written as a single set of provisions, with each component addressing the requirements of one or more certificate policies 💅 or it can be an organized collection of sets of provisions instead 🧚 for example, a CPS could be a combination of the following:

• (a) a list of certificate policies supported by the CPS;
• (b) for each CP in (a), a set of provisions that contains statements responding to that CP by filling in details not stipulated in that policy or expressly left to the discretion of the CA (in its CPS) ; such statements serve to state how this particular CPS implements the requirements of the particular CP; or
• (c) a set of provisions that contains statements regarding the certification practices on the CA, regardless of CP.

the statements in (b) and (c) may augment or refine the stipulations of the applicable CP, but they generally must not conflict with any of the stipulations of that CP 🙅‍♀️ that said, a policy authority may permit exceptions to the requirements in a CP in certain cases 🦋 this happens when certain compensating controls of the CA are disclosed in its CPS, which lets the CA provide assurances equivalent to those from CAs in full compliance with the CP 🫶

this framework outlines the contents of a set of provisions in terms of nine primary components, like so:

1. Introduction
2. Publication and Repository
3. Identification and Authentication
4. Certificate Life-Cycle Operational Requirements
5. Facilities, Management, and Operational Controls
6. Technical Security Controls
7. Certificate, CRL, and OCSP Profile
8. Compliance audit
9. Other Business and Legal Matters

PKIs can use this simple framework of nine primary components to write a simple CP or CPS 🌈 a CA can also use the same framework to write a subscriber agreement, a relying party agreement, or an agreement containing subscriber and relying party terms 💜 if a CA uses this simple framework to build an agreement, it can use paragraph 1 as an introduction or recitals, set out the responsibilities of the parties in paragraphs 2-8, and use paragraph 9 to cover the business and legal issues that get described in more detail, following the ordering of Section 4.9 below (things like representations and warranties, disclaimers, and liability limitations) ⭐ the ordering of topics in this simple framework and the business and legal matters in Section 4.9 is the same as (or similar to) the ordering of topics in a typical software or other technology agreement 🎀 so a PKI can set up a family of core documents (a CP, CPS, subscriber agreement, and relying party agreement) that all share the same structure and topic ordering 💖 that makes comparing and mapping these documents, both within one PKI and against the matching documents of other PKIs, so much easier 🔥

this simple framework can also be useful for agreements that aren't subscriber or relying party agreements 🧚 for instance, a CA that wants to outsource certain services to an RA or a certificate manufacturing authority (CMA) might find it helpful to use this framework as a checklist when writing a registration authority agreement or an outsourcing agreement 🍓 and two CAs drafting a cross-certification, unilateral certification, or other interoperability agreement might use this simple framework too 🫶

so in short, the primary components of the simple framework may be enough for drafters of short CPs, CPSs, subscriber agreements, and relying party agreements 🌸 that said, the framework is extensible, and its coverage of the nine components is flexible enough for drafters of comprehensive CPs and CPSs too 👑 specifically, the components above can be divided into subcomponents, and a subcomponent may comprise multiple elements 🦋 Section 4 gives a more detailed description of the contents of the above components and their subcomponents ✨ drafters of CPs and CPSs are also allowed to add extra levels of subcomponents below the ones described in Section 4, so the document can meet the needs of the drafter's particular PKI 💅

---

4. Contents of a Set of Provisions ✨

this section expands on the contents of the simple framework of provisions, which we introduced in Section 3.7 🧚 the topics identified here are, as a result, candidate topics for inclusion in a detailed CP or CPS 💜

there are a lot of topics listed, but a CP or CPS doesn't need a concrete statement for every single one 🌈 instead, a particular CP or CPS can state "no stipulation" for a component, subcomponent, or element that it places no requirements on or makes no disclosure about 🫶 in this sense, the list of topics works like a checklist for whoever is writing the CP or CPS 📝

it is recommended that each and every component and subcomponent be included in a CP or CPS, even if the entry says "no stipulation" 🎀 that shows the reader that someone made a conscious decision to include or exclude a provision on that topic 🙌 this drafting style guards against accidentally leaving a topic out, and it also makes it easier to compare different certificate policies or CPSs, for example when making policy mapping decisions 🦋

in a CP, it's possible to leave certain components, subcomponents, and/or elements unspecified, and to stipulate that the required information will be indicated in a policy qualifier, or in the document that a policy qualifier points to 💅 these CPs can be considered parameterized definitions 🍓 the set of provisions should reference or define the required policy qualifier types, and should specify any applicable default values 🔥

4.1. Introductions 🌸

this component identifies and introduces the set of provisions, and it indicates the types of entities and applications the document (either the CP or the CPS being written) is aimed at 💖

4.1.1. Overview ✨

okay so this subcomponent is basically your intro moment 🎀 It gives a general introduction to the document you're writing. It can also be used to give a synopsis of the PKI that the CP or CPS applies to. For example, it may set out the different levels of assurance that certificates within the PKI provide. Depending on how complex and big the particular PKI is, a diagrammatic representation of the PKI might be super useful here 🦋

4.1.2. Document Name and Identification 💅

This is where you put any applicable names or other identifiers for the document, including ASN.1 object identifiers 🧚 An example of a document name is the US Federal Government Policy for Secure E-mail.

4.1.3. PKI Participants 👑

This one describes the identity or types of entities that fill the roles of participants within a PKI, namely:

• Certification authorities, i.e., the entities that issue certificates. A CA is the issuing CA with respect to the certificates it issues and is the subject CA with respect to the CA certificate issued to it. CAs may be organized in a hierarchy in which an organization's CA issues certificates to CAs operated by subordinate organizations, such as a branch, division, or department within a larger organization.
• Registration authorities, i.e., the entities that establish enrollment procedures for end-user certificate applicants, perform identification and authentication of certificate applicants, initiate or pass along revocation requests for certificates, and approve applications for renewal or re-keying certificates on behalf of a CA. Subordinate organizations within a larger organization can act as RAs for the CA serving the entire organization, but RAs may also be external to the CA.
• Subscribers. Examples of subscribers who receive certificates from a CA include employees of an organization with its own CA, banking or brokerage customers, organizations hosting e-commerce sites, organizations participating in a business-to-business exchange, and members of the public receiving certificates from a CA issuing certificates to the public at large.
• Relying parties. Examples of relying parties include employees of an organization having its own CA who receive digitally signed e-mails from other employees, persons buying goods and services from e-commerce sites, organizations participating in a business-to-business exchange who receive bids or orders from other participating organizations, and individuals and organizations doing business with subscribers who have received their certificates from a CA issuing certificates to the public. Relying parties may or may not also be subscribers within a given PKI.
• Other participants, such as certificate manufacturing authorities, providers of repository services, and other entities providing PKI-related services.

4.1.4. Certificate Usage 🌷

This subcomponent contains:

• A list or the types of applications for which the issued certificates are suitable, such as electronic mail, retail transactions, contracts, and a travel order, and/or
• A list or the types of applications for which use of the issued certificates is prohibited.

In the case of a CP or CPS describing different levels of assurance, this subcomponent can describe applications or types of applications that are appropriate or inappropriate for the different levels of assurance.

4.1.5. Policy Administration 💜

This subcomponent includes the name and mailing address of the organization that is responsible for the drafting, registering, maintaining, and updating of this CP or CPS. It also includes the name, electronic mail address, telephone number, and fax number of a contact person. As an alternative to naming an actual person, the document may name a title or role, an e-mail alias, and other generalized contact information. In some cases, the organization may state that its contact person, alone or in combination with others, is available to answer questions about the document.

Moreover, when a formal or informal policy authority is responsible for determining whether a CA should be allowed to operate within or interoperate with a PKI, it may wish to approve the CPS of the CA as being suitable for the policy authority's CP. If so, this subcomponent can include the name or title, electronic mail address (or alias), telephone number, fax number, and other generalized information of the entity in charge of making such a determination. Finally, in this case, this subcomponent also includes the procedures by which this determination is made.

4.1.6. Definitions and Acronyms 🧚

This subcomponent contains a list of definitions for defined terms used within the document, as well as a list of acronyms in the document and their meanings.

---

4.2. Publication and Repository Responsibilities 🎀

This component contains any applicable provisions regarding:

• An identification of the entity or entities that operate repositories within the PKI, such as a CA, certificate manufacturing authority, or independent repository service provider;
• The responsibility of a PKI participant to publish information regarding its practices, certificates, and the current status of such certificates, which may include the responsibilities of making the CP or CPS publicly available using various mechanisms and of identifying components, subcomponents, and elements of such documents that exist but are not made publicly available, for instance, security controls, clearance procedures, or trade secret information due to their sensitivity;
• When information must be published and the frequency of publication; and
• Access control on published information objects including CPs, CPS, certificates, certificate status, and CRLs.

---

4.3. Identification and Authentication 🔥

This component describes the procedures used to authenticate the identity and/or other attributes of an end-user certificate applicant to a CA or RA prior to certificate issuance. In addition, the component sets forth the procedures for authenticating the identity and the criteria for accepting applicants of entities seeking to become CAs, RAs, or other entities operating in or interoperating with a PKI. It also describes how parties requesting re-key or revocation are authenticated. This component also addresses naming practices, including the recognition of trademark rights in certain names.

4.3.1. Naming 🦋

This subcomponent includes the following elements regarding naming and identification of the subscribers:

• Types of names assigned to the subject, such as X.500 distinguished names; RFC-822 names; and X.400 names;
• Whether names have to be meaningful or not;(3)
• Whether or not subscribers can be anonymous or pseudonymous, and if they can, what names are assigned to or can be used by anonymous subscribers;
• Rules for interpreting various name forms, such as the X.500 standard and RFC-822;
• Whether names have to be unique; and
• Recognition, authentication, and the role of trademarks.

4.3.2. Initial Identity Validation 💖

This subcomponent contains the following elements for the identification and authentication procedures for the initial registration for each subject type (CA, RA, subscriber, or other participant):

• If and how the subject must prove possession of the companion private key for the public key being registered, for example, a digital signature in the certificate request message;(4)
• Identification and authentication requirements for organizational identity of subscriber or participant (CA; RA; subscriber (in the case of certificates issued to organizations or devices controlled by an organization), or other participant), for example, consulting the database of a service that identifies organizations or inspecting an organization's articles of incorporation;
• Identification and authentication requirements for an individual subscriber or a person acting on behalf of an organizational subscriber or participant (CA, RA, in the case of certificates issued to organizations or devices controlled by an organization, the subscriber, or other participant),(5) including:
  • Type of documentation and/or number of identification credentials required;
  • How a CA or RA authenticates the identity of the organization or individual based on the documentation or credentials provided;
  • If the individual must personally present to the authenticating CA or RA;
  • How an individual as an organizational person is authenticated, such as by reference to duly signed authorization documents or a corporate identification badge.
• List of subscriber information that is not verified (called "non-verified subscriber information") during the initial registration;
• Validation of authority involves a determination of whether a person has specific rights, entitlements, or permissions, including the permission to act on behalf of an organization to obtain a certificate; and
• In the case of applications by a CA wishing to operate within, or interoperate with, a PKI, this subcomponent contains the criteria by which a PKI, CA, or policy authority determines whether or not the CA is suitable for such operations or interoperation. Such interoperation may include cross-certification, unilateral certification, or other forms of interoperation.

4.3.3. Identification and Authentication for Re-key Requests 🌈

This subcomponent addresses the following elements for the identification and authentication procedures for re-key for each subject type (CA, RA, subscriber, and other participants):

• Identification and authentication requirements for routine re-key, such as a re-key request that contains the new key and is signed using the current valid key; and
• Identification and authentication requirements for re-key after certificate revocation. One example is the use of the same process as the initial identity validation.

4.3.4. Identification and Authentication for Revocation Requests 🥺

This subcomponent describes the identification and authentication procedures for a revocation request by each subject type (CA, RA, subscriber, and other participant). Examples include a revocation request digitally signed with the private key whose companion public key needs to be revoked, and a digitally signed request by the RA.

---

4.4. Certificate Life-Cycle Operational Requirements 🌸

This component is used to specify requirements imposed upon issuing CA, subject CAs, RAs, subscribers, or other participants with respect to the life-cycle of a certificate.

Within each subcomponent, separate consideration may need to be given to subject CAs, RAs, subscribers, and other participants.

4.4.1. Certificate Application ✨

okay so this part is all about who's allowed to submit a certificate application 🫶 like, is it the certificate subject, or the RA? 🤔 It also covers the enrollment process subjects use to send in their applications, plus the responsibilities that come with it. 💅 Like, the subject generates the key pair and sends a certificate request to the RA. Then the RA validates and signs the request and sends it on to the CA. 🦋 A CA or RA may have the responsibility of setting up an enrollment process to receive applications, and applicants may have the responsibility of giving accurate info on their applications. ngl that's just basic good manners 💖

4.4.2. Certificate Application Processing 🌸

this bit describes how applications actually get processed 🧚 For example, the issuing CA and RA may do identification and authentication steps to validate the application. ✨ After that, the CA or RA will either approve or reject it, maybe based on certain criteria. 👑 This section also sets a time limit for how long a CA and/or RA has to act on and process a certificate application. ⏰ deadlines bestie, they're important 😭

4.4.3. Certificate Issuance 🎀

this section is about what happens when a certificate actually gets issued 🌈 It covers two things:

• Actions by the CA during issuance. For example, a procedure where the CA validates the RA signature and RA authority, and then generates a certificate. 🔥
• Notification mechanisms. If any are used, these let the CA tell the subscriber the certificate was issued. Like, the CA might email the certificate to the subscriber or the RA, or email info that lets the subscriber download the certificate from a web site. 💌

4.4.4. Certificate Acceptance 💜

okay this one is about what counts as the applicant accepting a certificate 👀 Acceptance can show up as affirmative steps, actions that imply acceptance, or just not objecting to the certificate or what's in it. 🙈 For instance, acceptance may be deemed to happen if the CA doesn't get any notice from the subscriber within a certain time period. Or a subscriber might send a signed message accepting the certificate. Or a subscriber might send a signed message rejecting it, where the message includes the reason and identifies the fields that are incorrect or incomplete. 🍓 The section also covers:

• Publication of the certificate by the CA. For example, the CA may post the certificate to an X.500 or LDAP repository. 📚
• Notification of certificate issuance by the CA to other entities. As an example, the CA may send the certificate to the RA. 📨

4.4.5. Key Pair and Certificate Usage 🔐

this section is about who's responsible for using keys and certificates, and it's giving rules 💅

• Subscriber responsibilities. The subscriber may be required to use a private key and certificate only for appropriate applications set out in the CP, and in line with the certificate content (for example, the key usage field). 🎀 Using a private key and certificate is subject to the terms of the subscriber agreement. The private key may only be used after the subscriber has accepted the corresponding certificate. And the subscriber must stop using the private key after the certificate expires or gets revoked. 🛑
• Relying party responsibilities. A relying party may be obligated to rely on certificates only for appropriate applications set out in the CP, and in line with the certificate content (for example, the key usage field). 🧐 They may also need to successfully perform public key operations as a condition of relying on a certificate. They may need to take responsibility for checking a certificate's status using one of the required or permitted mechanisms in the CP/CPS (see Section 4.4.9 below). And they may need to agree to the terms of the applicable relying party agreement as a condition of relying on the certificate. 🫶

4.4.6. Certificate Renewal 🌷

this section covers renewal, which just means issuing a new certificate to the subscriber without changing the subscriber's or any other participant's public key, or any other info in the certificate. ✨ It's basically a fresh certificate with the same key and details. 🦋 Here's what it describes:

• When renewal happens. For example, the certificate's life has expired, but the policy lets the same key pair be reused. ⏳
• Who can request renewal. For instance, the subscriber, the RA, or the CA may automatically renew an end-user subscriber certificate. 🤖
• How the CA or RA processes renewal requests. For example, they might use a token, like a password, to re-authenticate the subscriber. Or they might follow the same procedures as the initial certificate issuance. 🔑
• Notification of the new certificate to the subscriber. 💌
• Conduct that counts as acceptance of the certificate. ✅
• Publication of the certificate by the CA. 📚
• Notification of certificate issuance by the CA to other entities. 📨

4.4.7. Certificate Re-key 🗝️

this one is about a subscriber or other participant generating a new key pair and applying for a new certificate that certifies the new public key 💖 It's basically a fresh start with new keys. 🌈 It covers:

• When re-key can or must happen. For example, after a certificate is revoked because of key compromise, or after a certificate has expired and the key pair's usage period has also expired. 😬
• Who can request re-key. For example, the subscriber. 🙋‍♀️
• How the CA or RA processes re-keying requests to issue the new certificate. This could be the same as the initial certificate issuance. 🔁
• Notification of the new certificate to the subscriber. 💌
• Conduct that counts as acceptance of the certificate. ✅
• Publication of the certificate by the CA. 📚
• Notification of certificate issuance by the CA to other entities. 📨

4.4.8. Certificate Modification ✏️

this section is about issuing a new certificate (6) because the info in the certificate changed, other than the subscriber's public key 🧁 It covers:

• When modification can happen. For example, a name change, a role change, or a reorganization that changes the DN. 🏢
• Who can request modification. For instance, subscribers, human resources personnel, or the RA. 🧑‍💼
• How the CA or RA processes modification requests to issue the new certificate. This could be the same as the initial certificate issuance. 🔁
• Notification of the new certificate to the subscriber. 💌
• Conduct that counts as acceptance of the certificate. ✅
• Publication of the certificate by the CA. 📚
• Notification of certificate issuance by the CA to other entities. 📨

4.4.9. Certificate Revocation and Suspension 🚫

okay this is a big one, so get your snacks 🍿 This section is about when certificates get suspended or revoked, and everything around that 😭 It covers:

• When a certificate may be suspended, and when it must be revoked. For instance, if the subscriber's employment ends, if a cryptographic token gets lost, or if the private key is suspected to be compromised. 🚨
• Who can request revocation of the participant's certificate. For example, the subscriber, the RA, or the CA in the case of an end-user subscriber certificate. 🙋‍♀️
• Procedures for a revocation request. Like a digitally signed message from the RA, a digitally signed message from the subscriber, or a phone call from the RA. 📞
• The grace period the subscriber has to make a revocation request. 🕰️
• The time the CA has to process a revocation request. ⏱️
• Mechanisms for relying parties to check the status of certificates they want to rely on, which they may use or must use. 🔍
• The CRL issuance frequency, if a CRL mechanism is used. 📜
• The maximum latency between CRL generation and posting to the repository, if a CRL mechanism is used. In other words, that's the maximum amount of processing and communication delay in posting CRLs to the repository after they're generated. 🐢
• On-line revocation and status checking availability, for instance OCSP and a web site where status inquiries can be submitted. 🌐
• Requirements on relying parties to do on-line revocation or status checks. 🧾
• Other forms of revocation advertisements that are available. 📣
• Any variations of the above rules for when suspension or revocation happens because of private key compromise, as opposed to other reasons. 🔐

The section also covers suspension in its own right:

• Circumstances under which a certificate may be suspended. ⏸️
• Who can request suspension. For example, the subscriber, human resources personnel, a supervisor of the subscriber, or the RA in the case of an end-user subscriber certificate. 🙋‍♀️
• Procedures to request suspension, such as a digitally signed message from the subscriber or RA, or a phone call from the RA. 📞
• How long the suspension may last. ⌛

4.4.10. Certificate Status Services 🛰️

this part is about the certificate status checking services relying parties can use 💜 It covers:

• The operational characteristics of certificate status checking services. ⚙️
• Availability of those services, and any applicable policies on unavailability. 🚦
• Any optional features of those services. ✨

4.4.11. End of Subscription 👋

this section covers how a subscriber ends their subscription to the CA's services 🥲 It includes:

• Revocation of certificates at the end of subscription. This can differ depending on whether the subscription ended because the certificate expired or because the service was terminated. 🍂

4.4.12. Key Escrow and Recovery 🗄️

last one for this part! 🎉 This section lists the policies and practices for escrowing and/or recovering private keys, where private key escrow services are available (through the CA or other trusted third parties). 🫧 It covers:

• The document containing private key escrow and recovery policies and practices, or a listing of those policies and practices. 📄
• The document containing session key encapsulation and recovery policies and practices, or a listing of those policies and practices. 📑

4.5. Management, Operational, and Physical Controls ✨

okay bestie, this section is all about the non-tech stuff 🧱. It covers the physical, procedural, and personnel controls the issuing CA uses to securely do key generation, subject authentication, certificate issuance, certificate revocation, auditing, and archiving. 💅

It can also define these non-technical controls for repositories, subject CAs, RAs, subscribers, and other participants. Those controls could be the same, similar, or totally different, no cap 🫶

Why does this matter so much? Lack of security could lead to certificates or CRLs with wrong info in them, or to the CA private key getting compromised. 😭 So yeah, trust is literally on the line.

Within each subcomponent, you'll generally need to think about each entity type separately: the issuing CA, repository, subject CAs, RAs, subscribers, and other participants. 🦋

4.5.1. Physical Security Controls

In this subcomponent, we describe the physical controls on the facility that houses the entity systems. Topics may include:

• Site location and construction, such as construction requirements for high-security zones and the use of locked rooms, cages, safes, and cabinets;
• Physical access, i.e., mechanisms to control access from one area of the facility to another or access into high-security zones, such as locating CA operations in a secure computer room monitored by guards or security alarms and requiring movement from zone to zone to be accomplished using a token, biometric readers, and/or access control lists;
• Power and air conditioning;
• Water exposures;
• Fire prevention and protection;
• Media storage, for example, requiring the storage of backup media in a separate location that is physically secure and protected from fire and water damage;
• Waste disposal; and
• Off-site backup.

4.5.2. Procedural Controls

In this subcomponent, we describe requirements for recognizing trusted roles, together with the responsibilities for each role. Examples of trusted roles include system administrators, security officers, and system auditors. 🎀

For each task identified, the number of individuals required to perform the task (n out m rule) should be stated for each role. Identification and authentication requirements for each role may also be defined.

This component also includes the separation of duties, meaning the roles that cannot be performed by the same individuals. 👑

4.5.3. Personnel Security Controls

This subcomponent addresses the following:

• Qualifications, experience, and clearances that personnel must have as a condition of filling trusted roles or other important roles. Examples include credentials, job experiences, and official government clearances that candidates for these positions must have before being hired;
• Background checks and clearance procedures that are required in connection with the hiring of personnel filling trusted roles or perhaps other important roles; such roles may require a check of their criminal records, references, and additional clearances that a participant undertakes after a decision has been made to hire a particular person;
• Training requirements and training procedures for each role following the hiring of personnel;
• Any retraining period and retraining procedures for each role after completion of initial training;
• Frequency and sequence for job rotation among various roles;
• Sanctions against personnel for unauthorized actions, unauthorized use of authority, and unauthorized use of entity systems for the purpose of imposing accountability on a participant's personnel;
• Controls on personnel that are independent contractors rather than employees of the entity; examples include:
  • Bonding requirements on contract personnel;
  • Contractual requirements including indemnification for damages due to the actions of the contractor personnel;
  • Auditing and monitoring of contractor personnel; and
  • Other controls on contracting personnel.
• Documentation to be supplied to personnel during initial training, retraining, or otherwise.

4.5.4. Audit Logging Procedures

This subcomponent describes event logging and audit systems, implemented for the purpose of maintaining a secure environment. Elements include the following: 🔍

• Types of events recorded, such as certificate lifecycle operations, attempts to access the system, and requests made to the system;
• Frequency with which audit logs are processed or archived, for example, weekly, following an alarm or anomalous event, or when ever the audit log is n% full;
• Period for which audit logs are kept;
• Protection of audit logs:
  • Who can view audit logs, for example only the audit administrator;
  • Protection against modification of audit logs, for instance a requirement that no one may modify or delete the audit records or that only an audit administrator may delete an audit file as part of rotating the audit file; and
  • Protection against deletion of audit logs.
• Audit log back up procedures;
• Whether the audit log accumulation system is internal or external to the entity;
• Whether the subject who caused an audit event to occur is notified of the audit action; and
• Vulnerability assessments, for example, where audit data is run through a tool that identifies potential attempts to breach the security of the system.

4.5.5. Records Archival

This subcomponent describes general records archival (or records retention) policies, including the following: 🗄️

• Types of records that are archived, for example, all audit data, certificate application information, and documentation supporting certificate applications;
• Retention period for an archive;
• Protection of an archive:
  • Who can view the archive, for example, a requirement that only the audit administrator may view the archive;
  • Protection against modification of the archive, such as securely storing the data on a write once medium;
  • Protection against deletion of the archive;
  • Protection against the deterioration of the media on which the archive is stored, such as a requirement for data to be migrated periodically to fresh media; and
  • Protection against obsolescence of hardware, operating systems, and other software, by, for example, retaining as part of the archive the hardware, operating systems, and/or other software in order to permit access to and use of archived records over time.
• Archive backup procedures;
• Requirements for time-stamping of records;
• Whether the archive collection system is internal or external; and
• Procedures to obtain and verify archive information, such as a requirement that two separate copies of the archive data be kept under the control of two persons, and that the two copies be compared in order to ensure that the archive information is accurate.

4.5.6. Key Changeover

This subcomponent describes the procedures for providing a new public key to a CA's users following a re-key by the CA. 🔑 These procedures may be the same as the procedure for providing the current key. Also, the new key may be certified in a certificate signed using the old key.

4.5.7. Compromise and Disaster Recovery

This subcomponent describes requirements relating to notification and recovery procedures in the event of compromise or disaster. Each of the following may need to be addressed separately: 🚨

• Identification or listing of the applicable incident and compromise reporting and handling procedures.
• The recovery procedures used if computing resources, software, and/or data are corrupted or suspected to be corrupted. These procedures describe how a secure environment is re-established, which certificates are revoked, whether the entity key is revoked, how the new entity public key is provided to the users, and how the subjects are re-certified.
• The recovery procedures used if the entity key is compromised. These procedures describe how a secure environment is re-established, how the new entity public key is provided to the users, and how the subjects are re-certified.
• The entity's capabilities to ensure business continuity following a natural or other disaster. Such capabilities may include the availability of a remote hot-site at which operations may be recovered. They may also include procedures for securing its facility during the period of time following a natural or other disaster and before a secure environment is re-established, either at the original site or at a remote site. For example, procedures to protect against theft of sensitive materials from an earthquake-damaged site.

4.5.8. CA or RA Termination

This subcomponent describes requirements relating to procedures for termination and termination notification of a CA or RA, including the identity of the custodian of CA and RA archival records. 🌅

4.6. Technical Security Controls ⚙️

This component is used to define the security measures the issuing CA takes to protect its cryptographic keys and activation data (e.g., PINs, passwords, or manually-held key shares). It may also be used to impose constraints on repositories, subject CAs, subscribers, and other participants to protect their private keys, activation data for their private keys, and critical security parameters. Secure key management is critical to ensure that all secret and private keys and activation data are protected and used only by authorized personnel. 🔐

This component also describes other technical security controls used by the issuing CA to perform securely the functions of key generation, user authentication, certificate registration, certificate revocation, auditing, and archiving. Technical controls include life-cycle security controls (including software development environment security, trusted software development methodology) and operational security controls. 💻

This component can also be used to define other technical security controls on repositories, subject CAs, RAs, subscribers, and other participants. 🌸

4.6.1. Key Pair Generation and Installation

okay so 🎀 key pair generation and installation has to be thought through for the issuing CA, repositories, subject CAs, RAs, and subscribers. For each of these entity types, these questions might need answers:

1. Who generates the entity public, private key pair? Possibilities include the subscriber, RA, or CA. Also, how is the key generation performed? Is the key generation performed by hardware or software? 🔧
2. How is the private key provided securely to the entity? Possibilities include a situation where the entity has generated it and therefore already has it, handing the entity the private key physically, mailing a token containing the private key securely, or delivering it in an SSL session. 🔐
3. How is the entity's public key provided securely to the certification authority? Some possibilities are in an online SSL session or in a message signed by the RA. ✍️
4. In the case of issuing CAs, how is the CA's public key provided securely to potential relying parties? Possibilities include handing the public key to the relying party securely in person, physically mailing a copy securely to the relying party, or delivering it in a SSL session. 🦋
5. What are the key sizes? Examples include a 1,024 bit RSA modulus and a 1,024 bit DSA large prime. 📏
6. Who generates the public key parameters, and is the quality of the parameters checked during key generation? 🧐
7. For what purposes may the key be used, or for what purposes should usage of the key be restricted? For X.509 certificates, these purposes should map to the key usage flags in X.509 Version 3 certificates. 💅

4.6.2. Private Key Protection and Cryptographic Module Engineering Controls

this one is a whole vibe 🌸 requirements for private key protection and cryptographic modules need to be considered for the issuing CA, repositories, subject CAs, RAs, and subscribers. For each of these entity types, these questions might need answers:

1. What standards, if any, are required for the cryptographic module used to generate the keys? A cryptographic module can be composed of hardware, software, firmware, or any combination of them. For example, are the keys certified by the infrastructure required to be generated using modules compliant with the US FIPS 140-1? If so, what is the required FIPS 140-1 level of the module? Are there any other engineering or other controls relating to a cryptographic module, such as the identification of the cryptographic module boundary, input/output, roles and services, finite state machine, physical security, software security, operating system security, algorithm compliance, electromagnetic compatibility, and self tests. 🛡️
2. Is the private key under n out of m multi-person control?(7) If yes, provide n and m (two person control is a special case of n out of m, where n = m = 2)? 👯
3. Is the private key escrowed?(8) If so, who is the escrow agent, what form is the key escrowed in (examples include plaintext, encrypted, split key), and what are the security controls on the escrow system? 🗝️
4. Is the private key backed up? If so, who is the backup agent, what form is the key backed up in (examples include plaintext, encrypted, split key), and what are the security controls on the backup system? 💾
5. Is the private key archived? If so, who is the archival agent, what form is the key archived in (examples include plaintext, encrypted, split key), and what are the security controls on the archival system? 📦
6. Under what circumstances, if any, can a private key be transferred into or from a cryptographic module? Who is permitted to perform such a transfer operation? In what form is the private key during the transfer (i.e., plaintext, encrypted, or split key)? 🚚
7. How is the private key stored in the module (i.e., plaintext, encrypted, or split key)? 🧱
8. Who can activate (use) the private key? What actions must be performed to activate the private key (e.g., login, power on, supply PIN, insert token/key, automatic, etc.)? Once the key is activated, is the key active for an indefinite period, active for one time, or active for a defined time period? ⏰
9. Who can deactivate the private key and how? Examples of methods of deactivating private keys include logging out, turning the power off, removing the token/key, automatic deactivation, and time expiration. 😴
10. Who can destroy the private key and how? Examples of methods of destroying private keys include token surrender, token destruction, and overwriting the key. 💥
11. Provide the capabilities of the cryptographic module in the following areas: identification of the cryptographic module boundary, input/output, roles and services, finite state machine, physical security, software security, operating system security, algorithm compliance, electromagnetic compatibility, and self tests. Capability may be expressed through reference to compliance with a standard such as U.S. FIPS 140-1, associated level, and rating. 🏅

4.6.3. Other Aspects of Key Pair Management

the management side of things 🗂️ other aspects of key management need to be considered for the issuing CA, repositories, subject CAs, RAs, subscribers, and other participants. For each of these entity types, these questions might need answers:

1. Is the public key archived? If so, who is the archival agent and what are the security controls on the archival system? Also, what software and hardware need to be preserved as part of the archive to permit use of the public key over time? Note: this subcomponent is not limited to requiring or describing the use of digital signatures with archival data, but rather can address integrity controls other than digital signatures when an archive requires tamper protection. Digital signatures do not provide tamper protection or protect the integrity of data; they merely verify data integrity. Moreover, the archival period may be greater than the cryptanalysis period for the public key needed to verify any digital signature applied to archival data. 🕰️
2. What is the operational period of the certificates issued to the subscriber. What are the usage periods, or active lifetimes, for the subscriber's key pair? 📆

4.6.4. Activation Data

activation data is the little extra key to the key 🔑 activation data refers to data values other than whole private keys that are required to operate private keys or cryptographic modules containing private keys, such as a PIN, passphrase, or portions of a private key used in a key-splitting scheme. Protection of activation data prevents unauthorized use of the private key, and potentially needs to be considered for the issuing CA, subject CAs, RAs, and subscribers. Such consideration potentially needs to address the entire life-cycle of the activation data from generation through archival and destruction. For each of the entity types (issuing CA, repository, subject CA, RA, subscriber, and other participants), all of the questions listed in 4.6.1 through 4.6.3 potentially need to be answered with respect to activation data rather than with respect to keys. 🧩

4.6.5. Computer Security Controls

computer security, but make it iconic 💻 this subcomponent is used to describe computer security controls such as: use of the trusted computing base concept, discretionary access control, labels, mandatory access controls, object re-use, audit, identification and authentication, trusted path, security testing, and penetration testing. Product assurance may also be addressed.

A computer security rating for computer systems may be required. The rating could be based, for example, on the Trusted System Evaluation Criteria (TCSEC), Canadian Trusted Products Evaluation Criteria, European Information Technology Security Evaluation Criteria (ITSEC), or the Common Criteria for Information Technology Security Evaluation, ISO/IEC 15408:1999. This subcomponent can also address requirements for product evaluation analysis, testing, profiling, product certification, and/or product accreditation related activity undertaken. 🏆

4.6.6. Life Cycle Security Controls

from the first line of code to the last 🌱 this subcomponent addresses system development controls and security management controls.

System development controls include development environment security, development personnel security, configuration management security during product maintenance, software engineering practices, software development methodology, modularity, layering, use of failsafe design and implementation techniques (e.g., defensive programming) and development facility security. 🛠️

Security management controls include execution of tools and procedures to ensure that the operational systems and networks adhere to configured security. These tools and procedures include checking the integrity of the security software, firmware, and hardware to ensure their correct operation. ✅

This subcomponent can also address life-cycle security ratings based, for example, on the Trusted Software Development Methodology (TSDM) level IV and V, independent life-cycle security controls audit, and the Software Engineering Institute's Capability Maturity Model (SEI-CMM). 📈

4.6.7. Network Security Controls

the network part 🌐 this subcomponent addresses network security related controls, including firewalls. 🧱

4.6.8. Time-stamping

tick tock ⏱️ this subcomponent addresses requirements or practices relating to the use of timestamps on various data. It may also discuss whether or not the time-stamping application must use a trusted time source. 🕓

4.7. Certificate and CRL Profiles

the profiles era is here 🌈 this component is used to specify the certificate format and, if CRLs and/or OCSP are used, the CRL and/or OCSP format. This includes information on profiles, versions, and extensions used. 📜

4.7.1. Certificate Profile

this subcomponent addresses such topics as the following (potentially by reference to a separate profile definition, such as the one defined in IETF PKIX RFC 3280):

• Version number(s) supported;
• Certificate extensions populated and their criticality;
• Cryptographic algorithm object identifiers;
• Name forms used for the CA, RA, and subscriber names;
• Name constraints used and the name forms used in the name constraints;
• Applicable CP OID(s);
• Usage of the policy constraints extension;
• Policy qualifiers syntax and semantics; and
• Processing semantics for the critical CP extension.

4.7.2. CRL Profile

this subcomponent addresses such topics as the following (potentially by reference to a separate profile definition, such as the one defined in IETF PKIX RFC 3280):

• Version numbers supported for CRLs; and
• CRL and CRL entry extensions populated and their criticality.

4.7.3. OCSP Profile

this subcomponent addresses such topics as the following (potentially by reference to a separate profile definition, such as the IETF RFC 2560 profile):

• Version of OCSP that is being used as the basis for establishing an OCSP system; and
• OCSP extensions populated and their criticality.

4.8. Compliance Audit and Other Assessment ✨

okay so this part is all about how a PKI gets checked to make sure it's actually doing what its rules say 🧐 this component covers:

• The list of topics the assessment covers, and/or the assessment method used to run it. Examples include WebTrust for CAs (9) and SAS 70 (10) 💅
• How often each entity that has to be assessed under a CP or CPS gets checked, or what events trigger a check. Possibilities include a yearly audit, a pre-operational assessment before an entity is allowed to go live, or an investigation after a possible or actual security compromise 🚨
• Who the auditors or assessors are, and what qualifications they have 🎓
• How the assessor is related to the entity being assessed, including how independent the assessor is 🦋
• What happens after problems turn up in the assessment. Examples include temporarily pausing operations until the problems are fixed, revoking certificates issued to the assessed entity, personnel changes, launching special investigations or more frequent follow-up assessments, and claims for damages against the assessed entity 😭
• Who gets to see the results of an assessment (for example the assessed entity, other participants, or the general public), who hands them out (for example the assessor or the assessed entity), and how they get shared 📬

---

4.9. Other Business and Legal Matters 💼

this component covers the general business and legal stuff 🫶 Sections 9.1 and 9.2 of the framework talk about the business side: what fees can be charged for different services, and whether participants have enough financial backup to keep running and to pay judgments or settlements when someone makes a claim against them. The rest of the sections are mostly legal topics ⚖️

starting at Section 9.3 of the framework, the topics are ordered the same way (or pretty similarly) to a typical software licensing agreement or other technology agreement 🧠 so this framework isn't just for CPs and CPSs, it can also be used for related PKI agreements, especially subscriber agreements and relying party agreements ✨ this ordering is meant to make life easier for lawyers reviewing CPs, CPSs, and other documents that follow this framework 👩‍⚖️

here's the tea 🍵 a CP or CPS drafter can choose to put terms and conditions in the document that apply directly to subscribers or relying parties. For example, a CP or CPS can set out limits on liability that cover subscribers and relying parties. That makes the most sense when the CP or CPS is itself a contract, or part of one 📜

other times, the CP or CPS isn't a contract (or part of one), and instead its terms get applied to the parties through separate documents, like associated subscriber or relying party agreements 🎀 in that case, a CP drafter can write the CP so that certain legal terms appear (or don't appear) in those associated agreements. For example, a CP might include a piece saying a certain liability limitation has to show up in a CA's subscriber and relying party agreements. Another example is a CP with a piece that bans using a subscriber or relying party agreement whose liability limits clash with the CP's rules 🙅‍♀️ a CPS drafter can use legal pieces to say that certain terms appear in associated subscriber, relying party, or other agreements the CA uses. A CPS could explain, say, that the CA uses a subscriber or relying party agreement with a particular liability limit 💖

4.9.1. Fees 💸

this part has any relevant rules about fees charged by CAs, repositories, or RAs, like:

• Fees for issuing or renewing certificates 📝
• Fees for accessing certificates 🔍
• Fees for accessing revocation or status information 🚦
• Fees for other services, like getting access to the relevant CP or CPS 📚
• The refund policy 🍓

4.9.2. Financial Responsibility 🏦

this part has the requirements or disclosures about the resources CAs, RAs, and other participants have to support their operational PKI work 🌸 it also covers staying solvent and paying damages if they end up liable for a judgment or settlement from a claim linked to those operations 😭 this can include:

• A statement that the participant carries a certain amount of insurance for its liabilities to other participants 🛡️
• A statement that the participant has access to other resources to support operations and pay damages for potential liability. This can be described as a minimum level of assets needed to operate and cover things that might go wrong in a PKI. Examples include assets on an organization's balance sheet, a surety bond, a letter of credit, and a right under an agreement to indemnity in certain situations 💰
• A statement that the participant has a program offering first-party insurance or warranty protection to other participants using the PKI 🫧

4.9.3. Confidentiality of Business Information 🤫

this part is about how participants handle confidential business info they share with each other, like business plans, sales info, trade secrets, and info they got from a third party under a nondisclosure agreement 🔐 specifically, it covers:

• What counts as confidential information 🕵️‍♀️
• What types of information fall outside the scope of confidential information 🙈
• What participants who receive confidential information are responsible for, like keeping it safe from compromise, and not using it or sharing it with third parties 💜

4.9.4. Privacy of Personal Information 🎭

this part is about the protection that participants (especially CAs, RAs, and repositories) may need to give to personally identifiable private information belonging to certificate applicants, subscribers, and other participants 🌈 specifically, and only to the extent it applies under the relevant law, it covers:

• Naming and disclosing the privacy plan that applies to a participant's activities, if that's required by law or policy 📋
• Which information is or isn't considered private within the PKI 👀
• Any responsibility participants have when they receive private information: keeping it safe, not using it, and not sharing it with third parties 🔒
• Any requirements to notify individuals, or get their consent, before private information is used or disclosed 💌
• Any situations where a participant is allowed or required to disclose private information because of a judicial or administrative process, in a private or government proceeding, or in any other legal proceeding ⚖️

4.9.5. Intellectual Property Rights 🎨

this part covers intellectual property rights, like copyright, patents, trademarks, or trade secrets, that some participants may have or claim in a CP, CPS, certificates, names, and keys. It also covers IP that's the subject of a license to or from participants 🧚

4.9.6. Representations and Warranties 🤝

this part can include representations and warranties made by various entities under the CP or CPS 💅 for example, a CPS that works as a contract might include a CA's warranty that the info in a certificate is accurate. Or a CPS might include a softer warranty saying the info in the certificate is true to the best of the CA's knowledge, after doing certain identity checks with due diligence 🧐 this part can also require that representations and warranties show up in certain agreements, like subscriber or relying party agreements. For instance, a CP might require every CA to use a subscriber agreement, and require that the subscriber agreement contain a CA warranty that the info in the certificate is accurate ✨ participants who can make representations and warranties include CAs, RAs, subscribers, relying parties, and other participants 🌟

4.9.7. Disclaimers of Warranties 🙅

this part can include disclaimers of express warranties that might otherwise be found to exist in an agreement, and disclaimers of implied warranties that applicable law might otherwise impose, like warranties of merchantability or fitness for a particular purpose 🫠 the CP or CPS can impose these disclaimers directly, or it can require that disclaimers appear in associated agreements, like subscriber or relying party agreements 💼

4.9.8. Limitations of Liability ⚠️

this part can include limits on liability, either in a CP or CPS, or in an agreement associated with the CP or CPS (like a subscriber or relying party agreement) 📉 these limits usually fall into one of two categories: limits on the kinds of damages that can be recovered, and limits on the amount of damages that can be recovered (also called liability caps) 🧾 contracts often include clauses that block recovery of certain kinds of damages, like incidental and consequential damages, and sometimes punitive damages 🙃 they also often limit a party's possible recovery to a set amount, or to an amount tied to a benchmark, like what a vendor was paid under the contract 💸

4.9.9. Indemnities 🛡️

this part covers provisions where one party makes a second party whole for losses or damage the second party suffered, usually because of the first party's conduct 🫶 these can show up in a CP, a CPS, or an agreement. For example, a CP may require that subscriber agreements include a term making the subscriber responsible for indemnifying a CA for losses it sustains because of a subscriber's fraudulent misrepresentations on the certificate application, when that application led the CA to issue an inaccurate certificate 🙈 similarly, a CPS may say a CA uses a relying party agreement, under which relying parties are responsible for indemnifying the CA for losses it sustains from using a certificate without properly checking revocation information, or from using a certificate for purposes beyond what the CA permits 🌷

4.9.10. Term and Termination 🌸

okay so this subcomponent is all about how long a CP or a CPS stays in force, and the situations where it (or a piece of it, or its applicability to one particular participant) can get terminated 💅. It can also say that certain term and termination clauses have to show up in agreements, like subscriber or relying party agreements. The typical stuff it covers is:

• The term of a document or agreement, which is basically when it becomes effective and when it expires if nobody ends it early ⏳
• Termination provisions that spell out the circumstances where the document, certain parts of it, or its application to a particular participant stops being in effect 🚪
• Any consequences of termination. Certain bits of an agreement can survive being terminated and keep going! Examples are acknowledgements of intellectual property rights and confidentiality provisions 🔐. Termination might also create a responsibility for parties to give back confidential information to whoever disclosed it 📦

4.9.11. Individual notices and communications with participants 🦋

This one is about one-on-one chats between participants, and how those chats need to happen to be legally effective 📜. For example, an RA might want to tell the CA that it wants to end their agreement. This is totally different from publication and repository stuff! Individual comms are between two people, while publishing to a repository is for a big audience, like all relying parties 📢. This subcomponent can set up the communication mechanisms and say what contact info to route them to, like digitally signed e-mail notices to a specified address, followed by a signed e-mail acknowledgement of receipt ✉️.

4.9.12. Amendments ✏️

okay, a CP or CPS will need amending sometimes, obvi 🙄. Some tweaks won't materially reduce the assurance that a CP or its implementation provides, and the policy administrator will judge those as having an insignificant effect on how acceptable certificates are. Those changes don't need a change in the CP OID or the CPS pointer (URL). But other changes to a specification can materially change how acceptable certificates are for specific purposes, and those may require corresponding changes to the CP OID or CPS pointer qualifier (URL) 🎀.

This subcomponent may also contain the following information:

• The procedures by which the CP or CPS and/or other documents must, may be, or are amended. For CP or CPS amendments, change procedures may include:
  • a notification mechanism to give notice of proposed amendments to affected parties, such as subscribers and relying parties 📣
  • a comment period 🗣️
  • a mechanism by which comments are received, reviewed, and incorporated into the document 📝
  • a mechanism by which amendments become final and effective ✅
• The circumstances under which amendments to the CP or CPS would require a change in CP OID or CPS pointer (URL) 🔄

4.9.13. Dispute Resolution Procedures ⚖️

This subcomponent covers the procedures used to resolve disputes that come up from the CP, CPS, and/or agreements. Examples include requirements that disputes be resolved in a certain forum, or by alternative dispute resolution mechanisms 🤝.

4.9.14. Governing Law 🏛️

This subcomponent states that the law of a certain jurisdiction governs the interpretation and enforcement of the CP or CPS, or of agreements 📚.

4.9.15. Compliance with Applicable Law 🧾

This subcomponent is about stated requirements that participants comply with applicable law. For example, laws about cryptographic hardware and software that may be subject to a jurisdiction's export control laws 🌍. The CP or CPS could try to impose these requirements, or may require that such provisions appear in other agreements.

4.9.16. Miscellaneous Provisions 🧦

this subcomponent holds the miscellaneous provisions, sometimes called "boilerplate provisions," that show up in contracts 🙃. These clauses may appear in a CP, a CPS, or agreements, and include:

• An entire agreement clause, which typically identifies the document or documents making up the entire agreement between the parties, and states that such agreements supersede all prior and contemporaneous written or oral understandings relating to the same subject matter 📝;
• An assignment clause, which may act to limit a party's ability, under an agreement, to assign its rights to another party (such as the right to receive a stream of payments in the future), or to limit a party's ability to delegate its obligations under the agreement 🎁;
• A severability clause, which sets out the intentions of the parties if a court or other tribunal determines that a clause within an agreement is, for some reason, invalid or unenforceable. Its purpose is frequently to stop one clause from being unenforceable and making the whole agreement unenforceable 🧩; and
• An enforcement clause, which may state that a party prevailing in any dispute arising out of an agreement is entitled to attorneys' fees as part of its recovery, or may state that a party's waiver of one breach of contract does not constitute a continuing waiver or a future waiver of other breaches of contract 💪.
• A force majeure clause, commonly used to excuse the performance of one or more parties to an agreement due to an event outside the reasonable control of the affected party or parties. Typically, the excused performance lasts as long as the delay caused by the event. The clause may also provide for termination of the agreement under specified circumstances and conditions ⛈️. Events considered to be a "force majeure" may include so-called "Acts of God," wars, terrorism, strikes, natural disasters, failures of suppliers or vendors to perform, or failures of the Internet or other infrastructure 🌪️. Force majeure clauses should be drafted so as to be consistent with other portions of the framework and applicable service level agreements. For instance, responsibilities and capabilities for business continuity and disaster recovery may place some events within the reasonable control of the parties, such as an obligation to maintain backup electrical power in the face of power outages 🔌.

4.9.17. Other Provisions 🧺

This subcomponent is the "catchall" spot where extra responsibilities and terms can be imposed on PKI participants that don't neatly fit into one of the other components or subcomponents of the framework. CP and CPS writers can place any provision here that isn't covered by another subcomponent 🎀.

---

5. Security Considerations 🔐

heads up, this is the serious part 🚨. According to X.509, a certificate policy (CP) is "a named set of rules that indicates the applicability of a certificate to a particular community and/or class of applications with common security requirements." A CP may be used by a relying party to help decide whether a certificate, and the binding in it, are sufficiently trustworthy and otherwise appropriate for a particular application 🧐.

The degree to which a relying party can trust the binding in a certificate depends on several factors 💀. These can include the practices the certification authority (CA) follows in authenticating the subject, the CA's operating policy, procedures, and technical security controls (including the scope of the subscriber's responsibilities, for example in protecting the private key), and the stated responsibilities and liability terms and conditions of the CA (for example, warranties, disclaimers of warranties, and limitations of liability).

This document provides a framework to address technical, procedural, personnel, and physical security aspects of Certification Authorities, Registration Authorities, repositories, subscribers, and relying party cryptographic modules, so that certificate generation, publication, renewal, re-key, usage, and revocation is done in a secure manner 🛡️. Specifically, Section 4.3 Identification and Authentication (I&A); Section 4.4 Certificate Life-Cycle Operational Requirements; Section 4.5 Facility Management, and Operational Controls; Section 4.6 Technical Security Controls; Section 4.7 Certificate CRL, and OCSP Profiles; and Section 4.8 Compliance Audit and Other Assessment, are oriented towards ensuring secure operation of the PKI entities such as CA, RA, repository, subscriber systems, and relying party systems 💜.

---

6. Outline of a Set of Provisions 🗂️

this section has a recommended outline for a set of provisions 🌈, meant to serve as a checklist or (with some further development) a standard template for CP or CPS writers. A common outline will facilitate:

• (a) Comparison of two certificate policies during cross-certification or other forms of interoperation (for the purpose of equivalency mapping).
• (b) Comparison of a CPS with a CP to ensure that the CPS faithfully implements the policy.
• (c) Comparison of two CPSs.

In order to comply with the RFC, the drafters of a compliant CP or CPS are strongly advised to adhere to this outline. While use of an alternate outline is discouraged, it may be accepted if a proper justification is provided for the deviation and a mapping table is provided to readily discern where each of the items described in this outline is provided 💅.

7. Comparison to RFC 2527 ✨

Okay bestie, pause! 🫶 I only got the table of contents for this part, not the body text under section 7, and I'm not going to invent RFC details 😭 Paste the body text for "Comparison to RFC 2527" and I'll slay it in full, every MUST and SHOULD intact 💅

Quick heads-up 🌸: your covered list says 4.9.8 through 4.9.17, but this document numbers those as 9.8 through 9.17. Also, its section 5 is "Facility, Management, and Operational Controls," not Security Considerations, and section 6 is "Technical Security Controls." I'll keep the numbers and names exactly as the original has them so nothing gets renumbered 🎀

This framework is an incremental improvement over RFC 2527, and it's built on the experience of deploying CP and CPS documents under RFC 2527 🎀. It's also based on coordination with the American Bar Association Information Security Committee within the Section of Science and Technology Law. The ISC wrote the PKI Assessment Guidelines [ABA2], which holds a ton of technical, business, and legal experience from PKI operations 💅. The ISC reps changed the framework so it fits the legal environment better and is more accessible to lawyers ⚖️✨.

From a technical perspective, the changes to the RFC 2527 framework were minimal and incremental, not revolutionary 🦋. Sections 3-7 are mostly preserved, with some reorganization and new topics. For example, Section 4 was revised to include a full treatment of the certificate life-cycle, and the framework adds key escrow, key encapsulation, and key recovery policies and practices, plus OCSP 🔥. Section 2 audit functions now live alone in Section 8, and Section 2 focuses only on repository functions 📚. The business and legal stuff from RFC 2527's Section 2 now lives in a new Section 9 💜.

From a legal perspective, the new Section 9 is so useful bestie 👑. It puts topics in an order similar to software licensing and other technology agreements, so technology lawyers will feel right at home 🧚. The framework as a whole can also double as a framework for a subscriber, relying party, or other PKI-related agreement 🫶. All of this makes legal review of, and input into, CP and CPS documents more efficient. Section 9 also adds new legal topics, like the privacy of personal information, liability terms, and how long the document stays in effect 🌸.

Section 1 of the new framework is mostly the same as RFC 2527, but it covers more PKI participants by splitting subscribers from relying parties and adding a section for other participants 🍓. The "applicability" section is now one covering appropriate and prohibited uses of certificates 🙈. It also moves CPS approval procedures from RFC 2527's Section 8.3 into a collected policy administration section. Finally, Section 1.6 gets a spot to list definitions and acronyms 💖.

Section 2 of the new framework reorganizes Section 2.6 of the old framework 🎀. Section 3 of the new framework splits the old Section 3.1 into two parts, one for naming and identification and one for authentication issues 🦋. It also adds new issues, like whether pseudonyms and anonymity are permitted 🌈. Old Section 4 topics on audit logging, record archives, key changeover, compromise and disaster recovery, and CA termination moved to Section 5 ✨. The remaining Section 4 topics got expanded and reorganized to cover a complete certificate lifecycle, which is giving full main character energy 👑. New topics include things that were implicit in RFC 2527's Section 4 but are now explicit, like certificate application processing, certificate modification, and the end of subscription 💅.

New Sections 5.1 through 5.3 are almost identical to their RFC 2527 counterparts 🌸. The rest of the new Section 5 is the topics moved from RFC 2527's Section 4, in the same order they appeared there 🫶. Section 6 of the new framework is almost the same as the old Section 6, with a few exceptions 💫. Old Section 6.8 (cryptographic module engineering controls) got folded into Section 6.2.1, now called "cryptographic module standards and controls", and time-stamping was added in a new Section 6.8 ⏰. Section 7 is almost identical to the old Section 7, the big change being a new section covering the OCSP profile 🔥. Section 8 is almost identical to RFC 2527's Section 2.7 🦋.

New Section 9 holds the business and legal topics that were in RFC 2527's Section 2, including fees, financial responsibility, confidentiality, and intellectual property 💰. It adds a section on the privacy of personal information, which has become a seriously big policy issue 🔒. The "liability" Section 2.2 from RFC 2527 now appears in Sections 9.6 through 9.9, covering representations and warranties, disclaimers, limitations of liability, and indemnities 🛡️. Section 9.10 adds a section on how long the effectiveness of the documentation lasts ⏳. Section 9.12 gathers the terms for amending a document (CP, CPS, agreement, or other document), which used to live in Section 8.1 ✍️. Section 9 also includes "legal boilerplate" topics, some of which were in the old Section 2 🧾. Finally, Section 9.17 is the catch-all "other provisions" section, where drafters can put anything that doesn't fit neatly anywhere else in the framework 🧚‍♀️.

The following matrix shows the sections in the old RFC 2527 framework and their successor sections in the new framework 💖.

   ORIGINAL RFC 2527                     NEW RFC SECTION
        SECTION
   ------------------------------------------------------
   1. Introduction                             1.
   ------------------------------------------------------
   1.1 Overview                                1.1
   ------------------------------------------------------
   1.2 Identification                          1.2
   ------------------------------------------------------
   1.3 Community and
       Applicability                           1.3
   ------------------------------------------------------
   1.3.1 Certification
         Authorities                           1.3.1
   ------------------------------------------------------
   1.3.2 Registration Authorities              1.3.2
   ------------------------------------------------------
   1.3.3 End entities                          1.3.3,
                                               1.3.4
   ------------------------------------------------------
   1.3.4 Applicability                         1.4, 4.5
   ------------------------------------------------------
   1.4 Contact Details                         1.5
   ------------------------------------------------------
   1.4.1 Specification Administration
         Organization                          1.5.1
   ------------------------------------------------------
   1.4.2 Contact Person                        1.5.2
   ------------------------------------------------------
   1.4.3 Person Determining CPS
         Suitability for the Policy            1.5.3
   ------------------------------------------------------
   2. General Provisions                       2, 8, 9
   ------------------------------------------------------
   2.1 Obligations                             2.6.4
   ------------------------------------------------------
   2.1.1 1A Obligations                  Integrated
                                         throughout
                                         portions of the
                                         framework that
                                         apply to CAs
   ------------------------------------------------------
   2.1.2 RA Obligations                  Integrated
                                         throughout
                                         portions of the
                                         framework that
                                         apply to RAs

Okay bestie, this part is basically a giant cheat sheet 📋✨ The left side has the RFC 2527 headings, and the right side has the section numbers where that stuff lives in this doc. Here's the whole thing, exactly as it's written 💅

   ------------------------------------------------------
   2.1.3 Subscriber Obligations          4.1.2, 4.4, 4.5,
                                         4.5.1, 4.6.5,
                                         4.7.5, 4.8.1,
                                         4.8.5, 4.9.1,
                                         4.9.2, 4.9.13,
                                         4.9.15, 5., 6.,
                                         9.6.3, 9.9
   ------------------------------------------------------
   2.1.4 Relying Party Obligations     4.5, 4.5.2, 4.9.6,
                                       5., 6., 9.6.4, 9.9
   ------------------------------------------------------
   2.1.5 Repository Obligations        2., 4.4.2, 4.4.3,
                                       4.6.6, 4.6.7,
                                       4.7.6, 4.7.7,
                                       4.8.6, 4.8.7
   ------------------------------------------------------
   2.2 Liability                       9.6, 9.7, 9.8, 9.9
   ------------------------------------------------------
   2.2.1 CA Liability                  9.6.1, 9.7., 9.8,
                                       9.9
   ------------------------------------------------------
   2.2.2 RA Liability                  9.6.2, 9.7, 9.8, 9.9
   ------------------------------------------------------
   2.3 Financial Responsibility                9.2
   ------------------------------------------------------
   2.3.1 Indemnification by Relying
         Parties                               9.9
   ------------------------------------------------------
   2.3.2 Fiduciary Relationships               9.7
   ------------------------------------------------------
   2.4 Interpretation and Enforcement          9.16
   ------------------------------------------------------
   2.4.1 Governing Law                         9.14, 9.15
   ------------------------------------------------------
   2.4.2 Severability, Survival,
         Merger, Notice                9.10.3, 9.11,
                                       9.16.1,9.16.3
   ------------------------------------------------------
   2.4.3 Dispute Resolution
         Procedures                    9.13, 9.16.4
   ------------------------------------------------------
   2.5 Fees                                    9.1
   ------------------------------------------------------
   2.5.1 Certificate Issuance
         or Renewal Fees                       9.1.1
   ------------------------------------------------------
   2.5.2 Certificate Access Fees               9.1.2
   ------------------------------------------------------
   2.5.3 Revocation or Status
         Information Access Fees               9.1.3
   ------------------------------------------------------
   2.5.4 Fees for Other Services Such
         as Policy Information                 9.1.4
   ------------------------------------------------------
   2.5.5 Refund Policy                         9.1.5
   ------------------------------------------------------
   2.6 Publication and Repository              2.
   ------------------------------------------------------
   2.6.1 Publication of CA
         Information                    2.2, 4.4.2,
                                        4.4.3, 4.6.6,
                                        4.6.7, 4.7.6,
                                        4.7.7, 4.8.6,
                                        4.8.7
   ------------------------------------------------------
   2.6.2 Frequency of Publication              2.3
   ------------------------------------------------------
   2.6.3 Access Controls                       2.4
   ------------------------------------------------------
   2.6.4 Repositories                          2.1
   ------------------------------------------------------
   2.7 Compliance Audit                        8.
   ------------------------------------------------------
   2.7.1 Frequency of Entity Compliance
         Audit                                 8.1
   ------------------------------------------------------
   2.7.2 Identity/Qualifications of
         Auditor                               8.2
   ------------------------------------------------------
   2.7.3 Auditor's Relationship to Audited
         Party                                 8.3
   ------------------------------------------------------
   2.7.4 Topics Covered by Audit               8.4
   ------------------------------------------------------
   2.7.5 Actions Taken as a Result of
         Deficiency                            8.5
   ------------------------------------------------------
   2.7.6 Communications of Results             8.6
   ------------------------------------------------------
   2.8 Confidentiality                         9.3, 9.4
   ------------------------------------------------------
   2.8.1 Types of Information to be
         Kept Confidential              9.3.1, 9.4.2

   ------------------------------------------------------
   2.8.2 Types of Information Not
         Considered Confidential        9.3.2, 9.4.3
   ------------------------------------------------------
   2.8.3 Disclosure of Certificate
         Revocation/Suspension
         Information                    9.3.1, 9.3.2,
                                        9.3.3, 9.4.2,
                                        9.4.3, 9.4.4
   ------------------------------------------------------
   2.8.4 Release to Law Enforcement
         Officials                      9.3.3, 9.4.6
   ------------------------------------------------------
   2.8.5 Release as Part of Civil
   Discovery                            9.3.3, 9.4.6
   ------------------------------------------------------
   2.8.6 Disclosure Upon Owner's
         Request                        9.3.3, 9.4.7
   ------------------------------------------------------
   2.8.7 Other Information Release
         Circumstances                  9.3.3, 9.4.7
   ------------------------------------------------------
   2.9 Intellectual Property Rights            9.5
   ------------------------------------------------------
   3. Identification and Authentication        3.
   ------------------------------------------------------
   3.1 Initial Registration                    3.1, 3.2
   ------------------------------------------------------
   3.1.1 Type of Names                         3.1.1
   ------------------------------------------------------
   3.1.2 Need for Names to be
         Meaningful                     3.1.2, 3.1.3
   ------------------------------------------------------
   3.1.3 Rules for Interpreting
         Various Name Forms                    3.1.4
   ------------------------------------------------------
   3.1.4 Uniqueness of Names                   3.1.5
   ------------------------------------------------------
   3.1.5 Name Claim Dispute
         Resolution Procedure                  3.1.6
   ------------------------------------------------------
   3.1.6 Recognition, Authentication,
         and Role of Trademarks                3.1.6
   ------------------------------------------------------
   3.1.7 Method to Prove Possession
         of Private Key                        3.2.1

Heads up, this table is only halfway there 🎀 More of the cross-reference is coming in the next part, so stay tuned, bestie 🦋💜

Okay bestie, this part is all about the cross-reference table 💅🎀 It maps the old RFC 2527 headings onto the new RFC 3647 section numbers, so you can find where everything moved 🦋

   ------------------------------------------------------
   3.1.8 Authentication of
         Organization Identity                 3.2.2
   ------------------------------------------------------
   3.1.9 Authentication of
         Individual Identity                   3.2.3
   ------------------------------------------------------
   3.2 Routine Rekey                    3.3.1, 4.6, 4.7
   ------------------------------------------------------
   3.3 Rekey After Revocation                  3.3.2
   ------------------------------------------------------
   3.4 Revocation Request                      3.4
   ------------------------------------------------------
   4.  Operational Requirements                4., 5.
   ------------------------------------------------------
   4.1 Certificate Application          4.1, 4.2, 4.6,
                                        4.7
   ------------------------------------------------------
   4.2 Certificate Issuance             4.2, 4.3, 4.4.3,
                                        4.6, 4.7, 4.8.4,
                                        4.8.6, 4.8.7
   ------------------------------------------------------
   4.3 Certificate Acceptance           4.3.2, 4.4, 4.6,
                                        4.7, 4.8.4-4.8.7
   ------------------------------------------------------
   4.4 Certificate Suspension
       and Revocation                          4.8, 4.9
   ------------------------------------------------------
   4.4.1 Circumstances for Revocation   4.8.1, 4.9.1
   ------------------------------------------------------
   4.4.2 Who Can Request Revocation     4.8.2, 4.9.2
   ------------------------------------------------------
   4.4.3 Procedure for Revocation
         Request                        4.8.3-4.8.7,
                                        4.9.3
   ------------------------------------------------------
   4.4.4 Revocation Request
         Grace Period                          4.9.4
   ------------------------------------------------------
   4.4.5 Circumstances for Suspension          4.9.13
   ------------------------------------------------------
   4.4.6 Who Can Request Suspension            4.9.14
   ------------------------------------------------------
   4.4.7 Procedure for Suspension
         Request                               4.9.15
   ------------------------------------------------------
   4.4.8 Limits on Suspension Period           4.9.16
   ------------------------------------------------------
   4.4.9 CRL Issuance Frequency
         (If Applicable)                  4.9.7, 4.9.8,
                                          4.10
   ------------------------------------------------------
   4.4.10 CRL Checking Requirements       4.9.6, 4.10
   ------------------------------------------------------
   4.4.11 On-Line Revocation/
          Status Checking
          Availability                    4.9.9, 4.10
   ------------------------------------------------------
   4.4.12 On-Line Revocation
          Checking Requirements           4.9.6, 4.9.10,
                                          4.10
   ------------------------------------------------------
   4.4.13 Other Forms
          of Revocation
          Advertisements                  4.9.11, 4.10
   ------------------------------------------------------
   4.4.14 Checking Requirements
          for Other Forms of
          Revocation
          Advertisements                  4.9.6, 4.9.11,
                                          4.10
   ------------------------------------------------------
   4.4.15 Special Requirements re
          Key Compromise                        4.9.12
   ------------------------------------------------------
   4.5 Security Audit Procedures                5.4
   ------------------------------------------------------
   4.5.1 Types of Events Recorded               5.4.1
   ------------------------------------------------------
   4.5.2 Frequency of Processing Log            5.4.2
   ------------------------------------------------------
   4.5.3 Retention Period for Audit
         Log                                    5.4.3
   ------------------------------------------------------
   4.5.4 Protection of Audit Log                5.4.4
   ------------------------------------------------------
   4.5.5 Audit Log Backup Procedures            5.4.5
   ------------------------------------------------------
   4.5.6 Audit Collection System
         (Internal vs. External)                5.4.6
   ------------------------------------------------------
   4.5.7 Notification to Event-Causing
         Subject                                5.4.7
   ------------------------------------------------------
   4.5.8 Vulnerability Assessments              5.4.8
   ------------------------------------------------------
   4.6 Records Archival                         5.5
   ------------------------------------------------------
   4.6.1 Types of Records Archived              5.5.1
   ------------------------------------------------------
   4.6.2 Retention Period for Archive           5.5.2
   ------------------------------------------------------
   4.6.3 Protection of Archive                  5.5.3
   ------------------------------------------------------
   4.6.4 Archive Backup Procedures              5.5.4
   ------------------------------------------------------
   4.6.5 Requirements for
         Time-Stamping of Records               5.5.5
   ------------------------------------------------------
   4.6.6 Archive Collection System
         (Internal or External)                 5.5.6
   ------------------------------------------------------
   4.6.6 Procedures to Obtain and
         Verify Archive Information             5.5.7
   ------------------------------------------------------
   4.7 Key Changeover                           5.6
   ------------------------------------------------------
   4.8 Compromise and Disaster
       Recovery                           5.7, 5.7.1
   ------------------------------------------------------
   4.8.1 Computing Resources, Software,
         and/or Data Are Corrupted              5.7.2
   ------------------------------------------------------
   4.8.2 Entity Public
         Key is Revoked                   4.9.7, 4.9.9,
                                          4.9.11
   ------------------------------------------------------
   4.8.3 Entity Key is Compromised             5.7.3
   ------------------------------------------------------
   4.8.4 Secure Facility After a Natural
         or Other Type of Disaster             5.7.4
   ------------------------------------------------------
   4.9 CA Termination                          5.8
   ------------------------------------------------------
   5. Physical, Procedural, and
      Personnel Security Controls              5.
   ------------------------------------------------------
   5.1 Physical Controls                       5.1
   ------------------------------------------------------
   5.1.1 Site Location and Construction        5.1.1
   ------------------------------------------------------
   5.1.2 Physical Access                       5.1.2
   ------------------------------------------------------
   5.1.3 Power and Air Conditioning            5.1.3
   ------------------------------------------------------

   5.1.4 Water Exposures                       5.1.4
   ------------------------------------------------------
   5.1.5 Fire Prevention and Protection        5.1.5
   ------------------------------------------------------
   5.1.6 Media Storage                         5.1.6
   ------------------------------------------------------
   5.1.7 Waste Disposal                        5.1.7
   ------------------------------------------------------
   5.1.8 Off-Site Backup                       5.1.8
   ------------------------------------------------------
   5.2 Procedural Controls                     5.2
   ------------------------------------------------------
   5.2.1 Trusted Roles                    5.2.1, 5.2.4
   ------------------------------------------------------
   5.2.2 Number of Persons
         Required per Task                5.2.2, 5.2.4
   ------------------------------------------------------
   5.2.3 Identification and
         Authentication for Each Role          5.2.3
   ------------------------------------------------------
   5.3 Personnel Controls                      5.3
   ------------------------------------------------------
   5.3.1 Background, Qualifications,
         Experience, and Clearance
         Requirements                          5.3.1
   ------------------------------------------------------
   5.3.2 Background Check Procedures           5.3.2
   ------------------------------------------------------
   5.3.3 Training Requirements                 5.3.3
   ------------------------------------------------------
   5.3.4 Retraining Frequency
         and Requirements                      5.3.4
   ------------------------------------------------------
   5.3.5 Job Rotation Frequency
         and Sequence                          5.3.5
   ------------------------------------------------------
   5.3.6 Sanctions for
         Unauthorized Actions                  5.3.6
   ------------------------------------------------------
   5.3.7 Contracting Personnel
         Requirements                          5.3.7
   ------------------------------------------------------
   5.3.8 Documentation Supplied to
         Personnel                             5.3.8

   ------------------------------------------------------
   6. Technical Security Controls              6.
   ------------------------------------------------------
   6.1 Key Pair Generation and
       Installation                            6.1
   ------------------------------------------------------
   6.1.1 Key Pair Generation                   6.1.1
   ------------------------------------------------------
   6.1.2 Private Key Delivery to Entity        6.1.2
   ------------------------------------------------------
   6.1.3 Public Key Delivery to
         Certificate Issuer                    6.1.3
   ------------------------------------------------------
   6.1.4 CA Public Key Delivery to Users       6.1.4
   ------------------------------------------------------
   6.1.5 Key Sizes                             6.1.5
   ------------------------------------------------------
   6.1.6 Public Key Parameters Generation      6.1.6
   ------------------------------------------------------
   6.1.7 Parameter Quality Checking            6.1.6
   ------------------------------------------------------
   6.1.8 Hardware/Software Key Generation      6.1.1
   ------------------------------------------------------
   6.1.9 Key Usage Purposes
         (as per X.509 v3 Key Usage Field)     6.1.9
   ------------------------------------------------------
   6.2 Private Key Protection                  6.2
   ------------------------------------------------------
   6.2.1 Standards for Cryptographic
         Module                                6.2.1
   ------------------------------------------------------

   6.2.2 Private Key (n out of m)
         Multi-Person Control                  6.2.2
   ------------------------------------------------------
   6.2.3 Private Key Escrow                    6.2.3
   ------------------------------------------------------
   6.2.4 Private Key Backup                    6.2.4
   ------------------------------------------------------
   6.2.5 Private Key Archival                  6.2.5
   ------------------------------------------------------
   6.2.6 Private Key Entry Into
         Cryptographic Module              6.2.6, 6.2.7
   ------------------------------------------------------
   6.2.7 Method of Activating
         Private Key                           6.2.8

Table's done, and more of the chart is coming up next 🦋✨

   ------------------------------------------------------
   6.2.8 Method of Deactivating
         Private Key                           6.2.9
   ------------------------------------------------------
   6.2.9 Method of Destroying Private
         Key                                   6.2.10
   ------------------------------------------------------
   6.3 Other Aspects of Key Pair
       Management                              6.3
   ------------------------------------------------------
   6.3.1 Public Key Archival                   6.3.1
   ------------------------------------------------------
   6.3.2 Usage Periods for the Public
         and Private Keys                      6.3.2
   ------------------------------------------------------
   6.4 Activation Data                         6.4
   ------------------------------------------------------
   6.4.1 Activation Data Generation
         and Installation                      6.4.1
   ------------------------------------------------------
   6.4.2 Activation Data Protection            6.4.2
   ------------------------------------------------------
   6.4.3 Other Aspects of Activation
         Data                                  6.4.3
   ------------------------------------------------------
   6.5 Computer Security Controls              6.5
   ------------------------------------------------------
   6.5.1 Specific Computer Security
         Technical Requirements                6.5.1
   ------------------------------------------------------
   6.5.2 Computer Security Rating              6.5.2
   ------------------------------------------------------
   6.6 Life Cycle Technical Controls           6.6
   ------------------------------------------------------
   6.6.1 System Development Controls           6.6.1
   ------------------------------------------------------
   6.6.2 Security Management Controls          6.6.2
   ------------------------------------------------------
   6.6.3 Life Cycle Security Controls          6.6.3
   ------------------------------------------------------
   6.7 Network Security Controls               6.7
   ------------------------------------------------------
   6.8 Cryptographic Module
       Engineering Controls                 6.2.1, 6.2,
                                            6.2.1, 6.2.11
   ------------------------------------------------------
   7.Certificate and CRL Profiles              7.

   ------------------------------------------------------
   7.1 Certificate Profile                     7.1
   ------------------------------------------------------
   7.1.1 Version Number(s)                     7.1.1
   ------------------------------------------------------
   7.1.2 Certificate Extensions                7.1.2
   ------------------------------------------------------
   7.1.3 Algorithm Object Identifiers          7.1.3
   ------------------------------------------------------
   7.1.4 Name Forms                            7.1.4
   ------------------------------------------------------
   7.1.5 Name Constraints                      7.1.5
   ------------------------------------------------------
   7.1.6 Certificate Policy Object
         Identifier                            7.1.6
   ------------------------------------------------------
   7.1.7 Usage of Policy Constraints
         Extension                             7.1.7
   ------------------------------------------------------
   7.1.8 Policy Qualifiers Syntax
         and Semantics                         7.1.8
   ------------------------------------------------------
   7.1.9 Processing Semantics for
         the Critical Certificate
         Policies Extension                    7.1.9
   ------------------------------------------------------
   7.2 CRL Profile                             7.2
   ------------------------------------------------------
   7.2.1 Version Number(s)                     7.2.1
   ------------------------------------------------------
   7.2.2 CRL and CRL Entry Extensions          7.2.1
   ------------------------------------------------------
   8. Specification Administration             N/A
   ------------------------------------------------------
   8.1 Specification Change
       Procedures                              9.12
   ------------------------------------------------------
   8.2 Publication and Notification
       Policies                                2.2, 2.3
   ------------------------------------------------------
   8.3 CPS Approval Procedures                 1.5.4
   ------------------------------------------------------

Okay, so this next bit is the big mapping table 🗺️✨ It shows which headings in the new framework line up with which sections in the old RFC 2527, so you can see what moved where. Bestie, you're gonna want to screenshot this one 📸💖

   NEW RFC SECTION                      ORIGINAL RFC 2527
                                             SECTION
   ------------------------------------------------------
   1. Introduction                             1.
   ------------------------------------------------------
   1.1 Overview                                1.1
   ------------------------------------------------------
   1.2 Document Name and Identification        1.2
   ------------------------------------------------------
   1.3 PKI Participants                        1.3
   ------------------------------------------------------
   1.3.1 Certification Authorities             1.3.1
   ------------------------------------------------------
   1.3.2 Registration Authorities              1.3.2
   ------------------------------------------------------
   1.3.3 Subscribers                           1.3.3
   ------------------------------------------------------
   1.3.4 Relying Parties                       1.3.3
   ------------------------------------------------------
   1.3.5 Other Participants                    N/A
   ------------------------------------------------------
   1.4 Certificate Usage                       1.3.4
   ------------------------------------------------------
   1.4.1 Appropriate Certificate Uses          1.3.4
   ------------------------------------------------------
   1.4.2 Prohibited Certificate Uses           1.3.4
   ------------------------------------------------------
   1.5 Policy Administration                   1.4
   ------------------------------------------------------
   1.5.1 Organization Administering
         the Document                          1.4.1
   ------------------------------------------------------
   1.5.2 Contact Person                        1.4.2
   ------------------------------------------------------
   1.5.3 Person Determining CPS
         Suitability for the Policy            1.4.3
   ------------------------------------------------------
   1.5.4 CPS Approval Procedures               8.3
   ------------------------------------------------------
   1.6 Definitions and Acronyms                N/A
   ------------------------------------------------------
   2. Publication and Repository
      Responsibilities                         2.1.5, 2.6

   ------------------------------------------------------
   2.1 Repositories                            2.6.4
   ------------------------------------------------------
   2.2 Publication of Certification
       Information                             2.6.1, 8.2
   ------------------------------------------------------
   2.3 Time or Frequency of
       Publication                             2.6.2, 8.2
   ------------------------------------------------------
   2.4 Access Controls on Repositories         2.6.3
   ------------------------------------------------------
   3. Identification and Authentication        3.
   ------------------------------------------------------
   3.1 Naming                                  3.1
   ------------------------------------------------------
   3.1.1 Type of Names                         3.1.1
   ------------------------------------------------------
   3.1.2 Need for Names to be Meaningful       3.1.2
   ------------------------------------------------------
   3.1.3. Anonymity or Pseudonymity of
          Subscribers                          3.1.2
   ------------------------------------------------------
   3.1.4 Rules for Interpreting Various
         Name Forms                            3.1.3
   ------------------------------------------------------
   3.1.5 Uniqueness of Names                   3.1.4
   ------------------------------------------------------
   3.1.6 Recognition, Authentication,
         and Role of Trademarks           3.1.5, 3.1.6
   ------------------------------------------------------
   3.2 Initial Identity Validation             3.1
   ------------------------------------------------------
   3.2.1 Method to Prove Possession
         of Private Key                        3.1.7
   ------------------------------------------------------
   3.2.2 Authentication of
         Organization Identity                 3.1.8
   ------------------------------------------------------
   3.2.3 Authentication of Individual
         Identity                              3.1.9
   ------------------------------------------------------
   3.2.4 Non-Verified Subscriber
         Information                           N/A
   ------------------------------------------------------
   3.2.5 Validation of Authority               3.1.9
   ------------------------------------------------------
   3.2.6 Criteria for Interoperation           4.1
   ------------------------------------------------------
   3.3 Identification and Authentication
       for Re-Key Requests                     3.2, 3.3
   ------------------------------------------------------
   3.3.1 Identification and
         Authentication for Routine
         Re-Key                                3.2
   ------------------------------------------------------
   3.3.2 Identification and
         Authentication for Re-Key
         After Revocation                      3.3
   ------------------------------------------------------
   3.4 Identification and Authentication
       for Revocation Request                  3.4
   ------------------------------------------------------
   4. Certificate Life-Cycle
      Operational Requirements                 4.
   ------------------------------------------------------
   4.1 Certificate Application                 4.1
   ------------------------------------------------------
   4.1.1 Who Can Submit a Certificate
         Application                           4.1
   ------------------------------------------------------
   4.1.2 Enrollment Process and
         Responsibilities                      2.1.3, 4.1
   ------------------------------------------------------
   4.2 Certificate Application
       Processing                              4.1, 4.2
   ------------------------------------------------------
   4.2.1 Performing Identification
         and Authentication Functions          4.1, 4.2
   ------------------------------------------------------
   4.2.2 Approval or Rejection of
         Certificate Applications              4.1, 4.2
   ------------------------------------------------------
   4.2.3 Time to Process
         Certificate Applications              4.1, 4.2
   ------------------------------------------------------
   4.3 Certificate Issuance                    4.2
   ------------------------------------------------------
   4.3.1 CA Actions During
         Certificate Issuance                  4.2
   ------------------------------------------------------
   4.3.2 Notifications to Subscriber by
         the CA of Issuance of Certificate     4.2, 4.3

This part is basically one giant cross-reference table, so let's keep it exact, bestie 🎀

   ------------------------------------------------------
   4.4 Certificate Acceptance                  2.1.3, 4.3
   ------------------------------------------------------
   4.4.1 Conduct Constituting
         Certificate Acceptance                4.3
   ------------------------------------------------------
   4.4.2 Publication of the
         Certificate by the CA          2.1.5, 2.6.1, 4.3
   ------------------------------------------------------
   4.4.3 Notification of
         Certificate Issuance by
         the CA to Other Entities       2.1.5, 2.6.1,
                                        4.2, 4.3
   ------------------------------------------------------
   4.5 Key Pair and
       Certificate Usage                1.3.4, 2.1.3,
                                        2.1.4
   ------------------------------------------------------
   4.5.1 Subscriber Private Key
         and Certificate Usage          1.3.4, 2.1.3
   ------------------------------------------------------
   4.5.2 Relying Party Public
         Key and Certificate
         Usage                          1.3.4, 2.1.4
   ------------------------------------------------------
   4.6 Certificate Renewal              3.2, 4.1, 4.2,
                                        4.3
   ------------------------------------------------------
   4.6.1 Circumstances for
         Certificate Renewal            3.2, 4.1
   ------------------------------------------------------
   4.6.2 Who May Request Renewal        3.2, 4.1
   ------------------------------------------------------
   4.6.3 Processing Certificate
         Renewal Requests               3.2, 4.1, 4.2
   ------------------------------------------------------
   4.6.4 Notification of New
         Certificate Issuance to
         Subscriber                     3.2, 4.2, 4.3
   ------------------------------------------------------
   4.6.5 Conduct Constituting
         Acceptance of a Renewal
         Certificate                    2.1.3, 3.2, 4.3
   ------------------------------------------------------
   4.6.6 Publication of the
         Renewal Certificate
         by the CA                      2.1.5, 2.6.1,
                                        3.2, 4.3

   ------------------------------------------------------
   4.6.7 Notification of
         Certificate Issuance by
         the CA to Other Entities       2.1.5, 2.6.1, 3.2,
                                        4.2, 4.3
   ------------------------------------------------------
   4.7 Certificate Re-Key               3.2, 4.1, 4.2, 4.3
   ------------------------------------------------------
   4.7.1 Circumstances for
         Certificate Re-Key             3.2, 4.1
   ------------------------------------------------------
   4.7.2 Who May Request Certification
         of a New Public Key            3.2, 4.1
   ------------------------------------------------------
   4.7.3 Processing Certificate
         Re-Keying Requests             3.2, 4.1, 4.2
   ------------------------------------------------------
   4.7.4 Notification of New
         Certificate Issuance to
         Subscriber                     3.2, 4.2, 4.3
   ------------------------------------------------------
   4.7.5 Conduct Constituting
         Acceptance of a
         Re-Keyed Certificate           2.1.3, 3.2, 4.3
   ------------------------------------------------------
   4.7.6 Publication of the
         Re-Keyed Certificate
         by the CA                      2.1.5, 2.6.1,
                                        3.2, 4.3
   ------------------------------------------------------
   4.7.7 Notification of Certificate
         Issuance by the CA
         to Other Entities              2.1.5, 2.6.1,
                                        3.2, 4.2, 4.3
   ------------------------------------------------------
   4.8 Certificate Modification                4.4
   ------------------------------------------------------
   4.8.1 Circumstances for
         Certificate Modification       2.1.3, 4.4.1
   ------------------------------------------------------
   4.8.2 Who May Request Certificate
         Modification                   4.4.2
   ------------------------------------------------------
   4.8.3 Processing Certificate
         Modification Requests          4.4.3

   ------------------------------------------------------
   4.8.4 Notification of New
         Certificate Issuance to
         Subscriber                     4.2, 4.3, 4.4.3
   ------------------------------------------------------
   4.8.5 Conduct Constituting
         Acceptance of Modified
         Certificate                    2.1.3, 4.3, 4.4.3
   ------------------------------------------------------
   4.8.6 Publication of the Modified
         Certificate by
         the CA                         2.1.5, 2.6.1,
                                        4.2, 4.3, 4.4.3
   ------------------------------------------------------
   4.8.7 Notification of
         Certificate Issuance by
         the CA to Other
         Entities                       2.1.5, 2.6.1,
                                        4.2, 4.3, 4.4.3
   ------------------------------------------------------
   4.9 Certificate Revocation
       and Suspension                          4.4
   ------------------------------------------------------
   4.9.1 Circumstances for Revocation   2.1.3, 4.4.1
   ------------------------------------------------------
   4.9.2 Who Can Request Revocation     4.4.2
   ------------------------------------------------------
   4.9.3 Procedure for Revocation
         Request                        2.1.3, 4.4.3
   ------------------------------------------------------
   4.9.4 Revocation Request Grace
         Period                                4.4.4
   ------------------------------------------------------
   4.9.5 Time Within Which CA Must
         Process the Revocation Request    N/A
   ------------------------------------------------------
   4.9.6 Revocation Checking
         Requirements for Relying
         Parties                         2.1.4, 4.4.10,
                                         4.4.12, 4.4.14
   ------------------------------------------------------
   4.9.7 CRL Issuance Frequency          4.4.9, 4.8.3
   ------------------------------------------------------
   4.9.8 Maximum Latency for CRLs        4.4.9
   ------------------------------------------------------
   4.9.9 On-Line Revocation/Status
         Checking Availability           4.4.11, 4.8.3

   ------------------------------------------------------
   4.9.10 On-Line Revocation
          Checking Requirements          4.4.12
   ------------------------------------------------------
   4.9.11 Other Forms of Revocation
          Advertisements Available       4.4.13, 4.4.14,
                                         4.8.3
   ------------------------------------------------------
   4.9.12 Special Requirements re
          Key Compromise                 4.4.15
   ------------------------------------------------------
   4.9.13 Circumstances for Suspension   2.1.3, 4.4.5
   ------------------------------------------------------
   4.9.14 Who Can Request Suspension     4.4.6
   ------------------------------------------------------
   4.9.15 Procedure for
          Suspension Request             2.1.3, 4.4.7
   ------------------------------------------------------
   4.9.16 Limits on Suspension Period    4.4.8
   ------------------------------------------------------
   4.10 Certificate Status Services      4.4.9-4.4.14
   ------------------------------------------------------
   4.10.1 Operational
          Characteristics                4.4.9, 4.4.11,
                                         4.4.13
   ------------------------------------------------------
   4.10.2 Service Availability           4.4.9, 4.4.11,
                                         4.4.13
   ------------------------------------------------------
   4.10.3 Operational Features           4.4.9, 4.4.11,
                                         4.4.13
   ------------------------------------------------------
   4.11 End of Subscription                       N/A
   ------------------------------------------------------
   4.12 Key Escrow and Recovery                  6.2.3
   ------------------------------------------------------
   4.12.1 Key Escrow and Recovery Policy
          and Practices                          6.2.3
   ------------------------------------------------------
   4.12.2 Session Key Encapsulation
          and Recovery Policy and
          Practices                              6.2.3
   ------------------------------------------------------
   5. Facility, Management, and
      Operational Controls               2.1.3, 2.1.4,
                                         4., 5.
   ------------------------------------------------------
   5.1 Physical Controls                         5.1
   ------------------------------------------------------
   5.1.1 Site Location and Construction          5.1.1
   ------------------------------------------------------
   5.1.2 Physical Access                         5.1.2
   ------------------------------------------------------
   5.1.3 Power and Air Conditioning              5.1.3
   ------------------------------------------------------
   5.1.4 Water Exposures                         5.1.4
   ------------------------------------------------------
   5.1.5 Fire Prevention and Protection          5.1.5
   ------------------------------------------------------
   5.1.6 Media Storage                           5.1.6
   ------------------------------------------------------
   5.1.7 Waste Disposal                          5.1.7
   ------------------------------------------------------
   5.1.8 Off-Site Backup                         5.1.8
   ------------------------------------------------------
   5.2 Procedural Controls                       5.2
   ------------------------------------------------------
   5.2.1 Trusted Roles                           5.2.1
   ------------------------------------------------------
   5.2.2 Number of Persons Required
         per Task                                5.2.2
   ------------------------------------------------------
   5.2.3 Identification and
         Authentication for Each Role            5.2.3
   ------------------------------------------------------
   5.2.4 Roles Requiring Separation
         of Duties                          5.2.1, 5.2.2
   ------------------------------------------------------
   5.3 Personnel Controls                        5.3
   ------------------------------------------------------
   5.3.1 Qualifications, Experience,
         and Clearance Requirements         5.3.1
   ------------------------------------------------------
   5.3.2 Background Check Procedures        5.3.2
   ------------------------------------------------------
   5.3.3 Training Requirements              5.3.3
   ------------------------------------------------------
   5.3.4 Retraining Frequency
         and Requirements                   5.3.4
   ------------------------------------------------------
   5.3.5 Job Rotation Frequency
         and Sequence                       5.3.5
   ------------------------------------------------------
   5.3.6 Sanctions for Unauthorized
         Actions                            5.3.6

Okay bestie, the mapping table keeps going, and it's where RFC 2527 sections get matched up with their RFC 3647 homes 🗺️✨

   ------------------------------------------------------
   5.3.7 Independent Contractor
         Requirements                       5.3.7
   ------------------------------------------------------
   5.3.8 Documentation Supplied to
         Personnel                          5.3.8
   ------------------------------------------------------
   5.4 Audit Logging Procedures             4.5
   ------------------------------------------------------
   5.4.1 Types of Events Recorded           4.5.1
   ------------------------------------------------------
   5.4.2 Frequency of Processing Log        4.5.2
   ------------------------------------------------------
   5.4.3 Retention Period for Audit
         Log                                4.5.3
   ------------------------------------------------------
   5.4.4 Protection of Audit Log            4.5.4
   ------------------------------------------------------
   5.4.5 Audit Log Backup Procedures        4.5.5
   ------------------------------------------------------
   5.4.6 Audit Collection System
         (Internal vs. External)            4.5.6
   ------------------------------------------------------
   5.4.7 Notification to Event-Causing
         Subject                            4.5.7
   ------------------------------------------------------
   5.4.8 Vulnerability Assessments          4.5.8
   ------------------------------------------------------
   5.5 Records Archival                     4.6
   ------------------------------------------------------
   5.5.1 Types of Records Archived          4.6.1
   ------------------------------------------------------
   5.5.2 Retention Period for Archive       4.6.2
   ------------------------------------------------------
   5.5.3 Protection of Archive              4.6.3
   ------------------------------------------------------
   5.5.4 Archive Backup Procedures          4.6.4
   ------------------------------------------------------
   5.5.5 Requirements for Time-Stamping
         of Records                         4.6.5
   ------------------------------------------------------
   5.5.6 Archive Collection System
         (Internal or External)             4.6.6
   ------------------------------------------------------
   5.5.7 Procedures to Obtain and
         Verify Archive
         Information                        4.6.7

   ------------------------------------------------------
   5.6 Key Changeover                       4.7
   ------------------------------------------------------
   5.7 Compromise and Disaster Recovery     4.8
   ------------------------------------------------------
   5.7.1 Incident and Compromise
         Handling Procedures                4.8
   ------------------------------------------------------
   5.7.2 Computing Resources, Software,
         and/or Data Are Corrupted          4.8.1
   ------------------------------------------------------
   5.7.3 Entity Private Key
         Compromise Procedures              4.8.3
   ------------------------------------------------------
   5.7.4 Business Continuity
         Capabilities After a
         Disaster                           4.8.4
   ------------------------------------------------------
   5.8 CA or RA Termination                 4.9
   ------------------------------------------------------
   6. Technical Security Controls           2.1.3, 2.1.4,
                                            6.
   ------------------------------------------------------
   6.1 Key Pair Generation and
       Installation                         6.1
   ------------------------------------------------------
   6.1.1 Key Pair Generation                6.1.1, 6.1.8
   ------------------------------------------------------
   6.1.2 Private Key Delivery to
         Subscriber                         6.1.2
   ------------------------------------------------------
   6.1.3 Public Key Delivery to
         Certificate Issuer                 6.1.3
   ------------------------------------------------------
   6.1.4 CA Public Key Delivery to
         Relying Parties                    6.1.4
   ------------------------------------------------------
   6.1.5 Key Sizes                          6.1.5
   ------------------------------------------------------
   6.1.6 Public Key Parameters Generation
         and Quality Checking               6.1.6, 6.1.7
   ------------------------------------------------------
   6.1.7 Key Usage Purposes
         (as per X.509 v3
         Key Usage Field)                   6.1.9

   ------------------------------------------------------
   6.2   Private Key Protection and
         Cryptographic Module
         Engineering Controls               6.2, 6.8
   ------------------------------------------------------
   6.2.1 Cryptographic Module Standards
         and Controls                       6.2.1, 6.8
   ------------------------------------------------------
   6.2.2 Private Key (n out of m)
         Multi-Person Control               6.2.2
   ------------------------------------------------------
   6.2.3 Private Key Escrow                 6.2.3
   ------------------------------------------------------
   6.2.4 Private Key Backup                 6.2.4
   ------------------------------------------------------
   6.2.5 Private Key Archival               6.2.5
   ------------------------------------------------------
   6.2.6 Private Key Transfer Into
         or From a Cryptographic
         Module                             6.2.6
   ------------------------------------------------------
   6.2.7 Private Key Storage on
         Cryptographic Module               6.2.6
   ------------------------------------------------------
   6.2.8 Method of Activating Private
         Key                                6.2.7
   ------------------------------------------------------
   6.2.9 Method of Deactivating
         Private Key                        6.2.8
   ------------------------------------------------------
   6.2.10 Method of Destroying
          Private Key                       6.2.9
   ------------------------------------------------------
   6.2.11 Cryptographic Module Rating       6.2.1, 6.8
   ------------------------------------------------------
   6.3 Other Aspects of Key Pair
       Management                           6.3
   ------------------------------------------------------
   6.3.1 Public Key Archival                6.3.1
   ------------------------------------------------------
   6.3.2 Certificate Operational
         Periods and Key Pair Usage
         Periods                            6.3.2
   ------------------------------------------------------
   6.4 Activation Data                      6.4
   ------------------------------------------------------
   6.4.1 Activation Data Generation
         and Installation                   6.4.1
   ------------------------------------------------------
   6.4.2 Activation Data Protection         6.4.2
   ------------------------------------------------------
   6.4.3 Other Aspects of Activation
         Data                               6.4.3
   ------------------------------------------------------
   6.5 Computer Security Controls           6.5
   ------------------------------------------------------
   6.5.1 Specific Computer Security
         Technical Requirements             6.5.1
   ------------------------------------------------------
   6.5.2 Computer Security Rating           6.5.2
   ------------------------------------------------------
   6.6 Life Cycle Technical Controls        6.6
   ------------------------------------------------------
   6.6.1 System Development Controls        6.6.1
   ------------------------------------------------------
   6.6.2 Security Management Controls       6.6.2
   ------------------------------------------------------
   6.6.3 Life Cycle Security Controls       6.6.3
   ------------------------------------------------------
   6.7 Network Security Controls            6.7
   ------------------------------------------------------
   6.8 Time-Stamping                        N/A
   ------------------------------------------------------
   7. Certificate, CRL, and
      OCSP Profiles                         7.
   ------------------------------------------------------
   7.1 Certificate Profile                  7.1
   ------------------------------------------------------
   7.1.1 Version Number(s)                  7.1.1
   ------------------------------------------------------
   7.1.2 Certificate Extensions             7.1.2
   ------------------------------------------------------
   7.1.3 Algorithm Object Identifiers       7.1.3
   ------------------------------------------------------
   7.1.4 Name Forms                         7.1.4
   ------------------------------------------------------
   7.1.5 Name Constraints                   7.1.5
   ------------------------------------------------------
   7.1.6 Certificate Policy
         Object Identifier                  7.1.6
   ------------------------------------------------------
   7.1.7 Usage of Policy Constraints
         Extension                          7.1.7

   ------------------------------------------------------
   7.1.8 Policy Qualifiers Syntax
         and Semantics                      7.1.8
   ------------------------------------------------------
   7.1.9 Processing Semantics for the
         Critical Certificate Policies
         Extension                          7.1.9
   ------------------------------------------------------
   7.2 CRL Profile                          7.2
   ------------------------------------------------------
   7.2.1 Version Number(s)                  7.2.1
   ------------------------------------------------------
   7.2.2 CRL and CRL Entry Extensions       7.2.1
   ------------------------------------------------------
   7.3 OCSP Profile                         N/A
   ------------------------------------------------------
   7.3.1 Version Number(s)                  N/A
   ------------------------------------------------------
   7.3.2 OCSP Extensions                    N/A
   ------------------------------------------------------
   8. Compliance Audit and Other
      Assessments                           2.7
   ------------------------------------------------------
   8.1 Frequency and Circumstances
       of Assessment                        2.7.1
   ------------------------------------------------------
   8.2 Identity/Qualifications of
       Assessor                             2.7.2
   ------------------------------------------------------
   8.3 Assessor's Relationship to
       Assessed Entity                      2.7.3
   ------------------------------------------------------
   8.4 Topics Covered by Assessment         2.7.4
   ------------------------------------------------------
   8.5 Actions Taken as a Result
       of Deficiency                        2.7.5
   ------------------------------------------------------
   8.6 Communications of Results            2.7.6
   ------------------------------------------------------
   9. Other Business and Legal
      Matters                               2.

   ------------------------------------------------------
   9.1 Fees                                 2.5
   ------------------------------------------------------
   9.1.1 Certificate Issuance or
         Renewal Fees                       2.5.1

---

   ------------------------------------------------------
   9.1.2 Certificate Access Fees            2.5.2
   ------------------------------------------------------
   9.1.3 Revocation or Status
         Information Access Fees            2.5.3
   ------------------------------------------------------
   9.1.4 Fees for Other Services            2.5.4
   ------------------------------------------------------
   9.1.5 Refund Policy                      2.5.5
   ------------------------------------------------------
   9.2 Financial Responsibility             2.3
   ------------------------------------------------------
   9.2.1 Insurance Coverage                 2.3
   ------------------------------------------------------
   9.2.2 Other Assets                       2.3
   ------------------------------------------------------
   9.2.3 Insurance or Warranty Coverage
         for End-Entities                   2.3
   ------------------------------------------------------
   9.3 Confidentiality of Business
       Information                          2.8
   ------------------------------------------------------
   9.3.1 Scope of Confidential
         Information                        2.8.1, 2.8.3
   ------------------------------------------------------
   9.3.2 Information Not Within the
         Scope of Confidential
         Information                        2.8.2, 2.8.3
   ------------------------------------------------------
   9.3.3 Responsibility to Protect
         Confidential Information           2.8,

                                            2.8.3-2.8.7
   ------------------------------------------------------
   9.4 Privacy of Personal Information      2.8
   ------------------------------------------------------
   9.4.1 Privacy Plan                       N/A
   ------------------------------------------------------
   9.4.2 Information Treated as Private     2.8.1, 2.8.3
   ------------------------------------------------------
   9.4.3 Information Not Deemed Private     2.8.2, 2.8.3
   ------------------------------------------------------
   9.4.4 Responsibility to Protect
         Private Information                2.8, 2.8.1,
                                            2.8.3
   ------------------------------------------------------
   9.4.5 Notice and Consent to Use
         Private Information                N/A

   ------------------------------------------------------
   9.4.6 Disclosure Pursuant to
         Judicial or Administrative
         Process                            2.8.4-2.8.5
   ------------------------------------------------------
   9.4.7 Other Information Disclosure
         Circumstances                      2.8.6-2.8.7
   ------------------------------------------------------
   9.5 Intellectual Property rights         2.9
   ------------------------------------------------------
   9.6 Representations and Warranties       2.2
   ------------------------------------------------------
   9.6.1 CA Representations and
         Warranties                         2.2.1
   ------------------------------------------------------
   9.6.2 RA Representations and
         Warranties                         2.2.2
   ------------------------------------------------------
   9.6.3 Subscriber Representations
         and Warranties                     2.1.3
   ------------------------------------------------------

   9.6.4 Relying Party Representations
         and Warranties                     2.1.4
   ------------------------------------------------------
   9.6.5 Representations and Warranties
         of Other Participants                 N/A
   ------------------------------------------------------
   9.7 Disclaimers of Warranties            2.2, 2.3.2
   ------------------------------------------------------
   9.8 Limitations of Liability                2.2
   ------------------------------------------------------
   9.9 Indemnities                          2.1.3, 2.1.4,
                                            2.2, 2.3.1
   ------------------------------------------------------
   9.10 Term and Termination                   N/A
   ------------------------------------------------------
   9.10.1 Term                                 N/A
   ------------------------------------------------------
   9.10.2 Termination                          N/A
   ------------------------------------------------------
   9.10.3 Effect of Termination and
          Survival                             N/A
   ------------------------------------------------------
   9.11 Individual Notices and
        Communications with Participants       2.4.2
   ------------------------------------------------------
   9.12 Amendments                             8.1
   ------------------------------------------------------
   9.12.1 Procedure for Amendment              8.1
   ------------------------------------------------------
   9.12.2 Notification Mechanism
          and Period                           8.1
   ------------------------------------------------------
   9.12.3 Circumstances Under Which OID
          Must be Changed                      8.1
   ------------------------------------------------------
   9.13 Dispute Resolution Provisions          2.4.3
   ------------------------------------------------------
   9.14 Governing Law                          2.4.1
   ------------------------------------------------------
   9.15 Compliance with Applicable Law         2.4.1
   ------------------------------------------------------
   9.16 Miscellaneous Provisions               2.4
   ------------------------------------------------------
   9.16.1 Entire Agreement                     2.4.2
   ------------------------------------------------------
   9.16.2 Assignment                           N/A
   ------------------------------------------------------
   9.16.3 Severability                         2.4.2
   ------------------------------------------------------
   9.16.4 Enforcement (Attorney's Fees
          and Waiver of Rights)                2.4.3
   ------------------------------------------------------
   9.17 Other Provisions                       N/A
   ------------------------------------------------------

8. Acknowledgements ✨

The predecessor document (RFC 2527) got a big boost from the Government of Canada's Policy Management Authority (PMA) Committee, the National Security Agency, the National Institute of Standards and Technology (NIST), and the American Bar Association Information Security Committee Accreditation Working Group. Honestly, that's a whole squad 🫶

This revision effort is largely a result of constant inspiration from Michael Baum. 💜 Michael Power, Mike Jenkins, and Alice Sturgeon have also made several contributions 🌸

9. References 📚

• [ABA1] American Bar Association, Digital Signature Guidelines: Legal Infrastructure for Certification Authorities and Secure Electronic Commerce, 1996.
• [ABA2] American Bar Association, PKI Assessment Guidelines, v0.30, Public Draft For Comment, June 2001.
• [BAU1] Michael. S. Baum, Federal Certification Authority Liability and Policy, NIST-GCR-94-654, June 1994, available at http://www.verisign.com/repository/pubs/index.html.
• [ETS] European Telecommunications Standards Institute, "Policy Requirements for Certification Authorities Issuing Qualified Certificates," ETSI TS 101 456, Version 1.1.1, December 2000.
• [GOC] Government of Canada PKI Policy Management Authority, "Digital Signature and Confidentiality Certificate Policies for the Government of Canada Public Key Infrastructure," v.3.02, April 1999.
• [IDT] Identrus, LLC, "Identrus Identity Certificate Policy" IP-IPC Version 1.7, March 2001.
• [ISO1] ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information Technology - Open Systems Interconnection: The Directory: Authentication Framework," 1997 edition. (Pending publication of 2000 edition, use 1997 edition.)
• [PEM1] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management", RFC 1422, February 1993.
• [PKI1] Housley, R., Polk, W. Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
• [CPF] Chokhani, S. and W. Ford, "Internet X.509 Public Key Infrastructure, Certificate Policy and Certification Practices Statement Framework", RFC 2527, March 1999.

10. Notes 🦋

1. A paper copy of the ABA Digital Signature Guidelines can be purchased from the ABA. See http://www.abanet.com for ordering details. The DSG may also be downloaded without charge from the ABA website at http://www.abanet.org/scitech/ec/isc/digital_signature.html.
2. A draft of the PKI Assessment Guidelines may be downloaded without charge from the ABA website at http://www.abanet.org/scitech/ec/isc/pag/pag.html.
3. The term "meaningful" means that the name form has commonly understood semantics to determine the identity of a person and/or organization. Directory names and RFC 822 names may be more or less meaningful. 🧚
4. The subject may not need to prove to the CA that the subject has possession of the private key corresponding to the public key being registered if the CA generates the subject's key pair on the subject's behalf.
5. Examples of means to identify and authenticate individuals include biometric means (such as thumb print, ten finger print, and scan of the face, palm, or retina), a driver's license, a credit card, a company badge, and a government badge. 🪪
6. Certificate "modification" does not refer to making a change to an existing certificate, since this would prevent the verification of any digital signatures on the certificate and cause the certificate to be invalid. Rather, the concept of "modification" refers to a situation where the information referred to in the certificate has changed or should be changed, and the CA issues a new certificate containing the modified information. One example is a subscriber that changes his or her name, which would necessitate the issuance of a new certificate containing the new name. 🌈
7. The n out of m rule allows a private key to be split in m parts. The m parts may be given to m different individuals. Any n parts out of the m parts may be used to fully reconstitute the private key, but having any n-1 parts provides one with no information about the private key. 🔑
8. A private key may be escrowed, backed up, or archived. Each of these functions has a different purpose. Thus, a private key may go through any subset of these functions depending on the requirements. The purpose of escrow is to allow a third party (such as an organization or government) to obtain the private key without the cooperation of the subscriber. The purpose of back up is to allow the subscriber to reconstitute the key in case of the destruction or corruption of the key for business continuity purposes. The purpose of archives is to provide for reuse of the private key in the future, e.g., use to decrypt a document. 💅
9. WebTrust refers to the "WebTrust Program for Certification Authorities," from the American Institute of Certified Public Accountants, Inc., and the Canadian Institute of Chartered Accountants.
10. See <http://www.aicpa.org>.
11. All or some of the following items may be different for the various types of entities, i.e., CA, RA, and end entities. ✨ Just a heads up, bestie!

11. List of Acronyms 📚✨

okay so this is the cheat sheet bestie, every acronym from the whole doc in one place 💅 I kept it verbatim so you can ctrl+F it easily 🫶

   ABA - American Bar Association
   CA - Certification Authority
   CP - Certificate Policy
   CPS - Certification Practice Statement
   CRL - Certificate Revocation List
   DAM - Draft Amendment
   FIPS - Federal Information Processing Standard
   I&A - Identification and Authentication
   IEC - International Electrotechnical Commission
   IETF - Internet Engineering Task Force
   IP - Internet Protocol
   ISO - International Organization for Standardization
   ITU - International Telecommunications Union
   NIST - National Institute of Standards and Technology
   OID - Object Identifier
   PIN - Personal Identification Number
   PKI - Public Key Infrastructure
   PKIX - Public Key Infrastructure (X.509) (IETF Working Group)
   RA - Registration Authority
   RFC - Request For Comment
   URL - Uniform Resource Locator
   US - United States

---

12. Authors' Addresses 🎀

the authors, where to find them 🦋 these are all verbatim so you can reach out to the people who wrote this 💌

   Santosh Chokhani
   Orion Security Solutions, Inc.
   3410 N. Buchanan Street
   Arlington, VA 22207

   Phone: (703) 237-4621
   Fax:   (703) 237-4920
   EMail: chokhani@orionsec.com


   Warwick Ford
   VeriSign, Inc.
   6 Ellery Square
   Cambridge, MA 02138

   Phone: (617) 642-0139
   EMail: wford@verisign.com


   Randy V. Sabett, J.D., CISSP
   Cooley Godward LLP
   One Freedom Square, Reston Town Center
   11951 Freedom Drive
   Reston, VA 20190-5656

   Phone: (703) 456-8137
   Fax:   (703) 456-8100
   EMail: rsabett@cooley.com


   Charles (Chas) R. Merrill
   McCarter & English, LLP
   Four Gateway Center
   100 Mulberry Street
   Newark, New Jersey 07101-0652

   Phone: (973) 622-4444
   Fax:   (973) 624-7070
   EMail: cmerrill@mccarter.com
   Stephen S. Wu
   Infoliance, Inc.
   800 West El Camino Real
   Suite 180
   Mountain View, CA  94040

   Phone:  (650) 917-8045
   Fax:    (650) 618-1454
   EMail: swu@infoliance.com

---

13. Full Copyright Statement ⚖️💖

okay the legal bit, but make it cute 🌸 the copyright line is Copyright (C) The Internet Society (2003). All Rights Reserved. 🦋

So the Internet Society owns the copyright here, and everyone's allowed to copy this document and pass it around to others, and to make derivative works that comment on or explain it, or help with implementing it. You can publish and distribute those too, in whole or in part, with no restrictions of any kind 🙌 The one catch is that the copyright notice and this paragraph have to stay on every copy and derivative work 🫶

The document itself can't be changed in any way, though. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when you need it for developing Internet standards (then you have to follow the copyright procedures in the Internet Standards process), or when you need to translate it into languages other than English 🌍

These limited permissions are perpetual, and the Internet Society and its successors or assignees won't revoke them 💜

the disclaimer, bestie: this document and the info in it is provided "AS IS" 😭 THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED. That includes any warranty that using the information won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose. no warranties, babe 💀

Acknowledgement 🌈

funding moment ✨ Funding for the RFC Editor function is currently provided by the Internet Society. So the group that keeps the RFC series running gets its money from the Internet Society right now 👑