RFC 2527

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

📅 published March 1999, from ietf

RFC 2527: Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework ✨

Okay bestie, let's get into it 🎀 This doc is RFC 2527, from the Network Working Group, dated March 1999. It's in the Informational category, so it's giving "here's some good info," not "you must implement this" 💅 The authors are S. Chokhani (CygnaCom Solutions, Inc.) and W. Ford (VeriSign, Inc.). Its header has no Obsoletes or Updates lines, so it doesn't replace or change anything else 🌸

Status of this Memo 📝

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

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

Abstract 🧁

This doc is a framework that helps people writing certificate policies or certification practice statements for certification authorities and public key infrastructures. The big win is a comprehensive list of topics that might need to be covered in a certificate policy definition or a certification practice statement. Whether each one is needed is up to the writer 💖

1. INTRODUCTION ✨

1.1. BACKGROUND 🌈

Okay so, a public-key certificate (we'll just call it "certificate") binds a public-key value to a set of information that identifies the entity (like a person, organization, account, or site) connected to the matching private key. That entity is the "subject" of the certificate 🔑

A certificate is used by a "certificate user" or "relying party." This is someone who needs to use the public key from that certificate and trust that it's accurate. Usually that's an entity verifying a digital signature from the subject, or an entity sending encrypted data to the subject 🫶

How much a certificate user can trust the binding depends on a few things. There's the practices the certification authority (CA) follows when authenticating the subject. There's the CA's operating policy, procedures, and security controls. There's the subject's obligations, like protecting the private key. And there's the CA's stated undertakings and legal obligations, like warranties and limits on liability ⭐

A Version 3 X.509 certificate may contain a field saying that one or more specific certificate policies applies to that certificate [ISO1]. According to X.509, a certificate policy is "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." A certificate user can use the policy to help decide whether a certificate, and the binding in it, is trustworthy enough for a particular application. The certificate policy idea grew out of the policy statement concept from Internet Privacy Enhanced Mail [PEM1], and was expanded on in [BAU1] 🎀

A more detailed description of how a CA issues and manages certificates may be in a certification practice statement (CPS). That CPS is published by the CA or referenced by it. The American Bar Association Digital Signature Guidelines (we'll call them "ABA Guidelines") say, "a CPS is a statement of the practices which a certification authority employs in issuing certificates." [ABA1] 📜

1.2. PURPOSE 🎯

The point of this doc is to make a clear relationship between certificate policies and CPSs, and to give writers of certificate policies or CPSs a framework for their tasks. The framework names the elements that may need to be considered when writing a certificate policy or a CPS. It does not define particular certificate policies or CPSs 🙅‍♀️

1.3. SCOPE 🔍

This doc is limited to what goes in a certificate policy (as defined in X.509) or a CPS (as defined in the ABA Guidelines). It describes the types of information that should be considered for inclusion in a certificate policy definition or a CPS. The framework generally assumes the X.509 version 3 certificate format, but it isn't meant to be stuck to that format only. It's meant to be adaptable to other certificate formats that may come into use later 🦋

The scope doesn't extend to defining security policies in general, like organization security policy, system security policy, or data labeling policy. The only exception is the policy elements that matter for certificate policies or CPSs 🙈

This document does not define a specific certificate policy or CPS.

It's assumed the reader already knows the general concepts of digital signatures, certificates, and public-key infrastructure, as used in X.509 and the ABA Guidelines 🧠

2. DEFINITIONS 📚

This document uses the following defined terms:

  • 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). 🔐
  • CA-certificate - A certificate for one CA's public key issued by another CA. 🎀
  • Certificate policy - 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 certificate policy might indicate applicability of a type of certificate to the authentication of electronic data interchange transactions for the trading of goods within a given price range. 💅
  • Certification path - An ordered sequence of certificates which, 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. 🛤️
  • Certification Practice Statement (CPS) - A statement of the practices which a certification authority employs in issuing certificates. 📜
  • 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). 🏛️
  • Policy qualifier - Policy-dependent information that accompanies a certificate policy identifier in an X.509 certificate. 🏷️
  • Registration authority (RA) - An entity that is responsible for identification and authentication of certificate subjects, but that does 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 used elsewhere for the same concept.] 🪪
  • Relying party - A recipient of a certificate who acts in reliance on that certificate and/or digital signatures verified using that certificate. In this document, the terms "certificate user" and "relying party" are used interchangeably. 🤝
  • Set of provisions - A collection of practice and/or policy statements, spanning a range of standard topics, for use in expressing a certificate policy definition or CPS employing the approach described in this framework. 🧩
  • 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). 👑

3. CONCEPTS 💡

This section explains the ideas of certificate policy and CPS, and how they relate to each other. It also covers some other related concepts. Some of the material in this section and a few others is specific to the certificate policies extension defined in X.509 version 3. Apart from those parts, the framework is meant to be adaptable to other certificate formats that may come into use 🌸

3.1. CERTIFICATE POLICY 🎀

When a certification authority issues a certificate, it's basically telling a certificate user (a relying party) that a particular public key is bound to a particular entity (the certificate subject). But the certificate user still needs to figure out how much to rely on that statement from the CA. Different certificates get issued under different practices and procedures, so they might suit different applications and/or purposes 🧐

The X.509 standard defines a certificate policy 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 contain an indication of certificate policy. A certificate user can use that indication to decide whether or not to trust a certificate for a particular purpose 💖

A certificate policy has to be recognized by both the issuer and the user of a certificate. It's represented in a certificate by a unique, registered Object Identifier. The registration follows the procedures in ISO/IEC and ITU standards. The party that registers the Object Identifier also publishes a textual specification of the certificate policy so certificate users can read it. Usually one certificate declares a single certificate policy, or maybe it's issued consistent with a small number of different policies 🦋

Certificate policies are also the basis for accrediting CAs. Each CA is accredited against one or more certificate policies 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 accreditation for the policies involved. The assessed set is then indicated by the issuing CA in the CA-certificate. The X.509 certification path processing logic uses these certificate policy indications in its well-defined trust model 👑

3.2. Certificate Policy Examples ✨

okay so let's make this concrete 💅 imagine IATA decides to define some certificate policies for the whole airline industry 🛫, running a public-key infrastructure that it operates together with the PKIs that each individual airline runs. IATA comes up with two policies: the IATA General-Purpose policy and the IATA Commercial-Grade policy 🎀

The General-Purpose one is for everyday industry stuff, like protecting casual emails 📧 and securing web browser connections to servers for general info. The key pairs can be made and kept using cheap, software-based tools, like the browsers you already have. Under this policy, a certificate can be issued automatically to anyone listed as an employee in IATA's corporate directory, or in a member airline's directory, as long as they hand a signed certificate request form to a network administrator in their organization. Very chill, very accessible 🌸

The Commercial-Grade one is way more serious 😤 It protects financial transactions and binding contracts between airlines. IATA requires that the certified key pairs get generated and stored on approved cryptographic hardware tokens 🔐 Only employees with disbursement authority get certificates and tokens. Before they're handed a token and a certificate, those people have to show up at the corporate security office, show a valid identification badge, and sign a promise to protect the token and only use it for authorized purposes. Strict but iconic 👑

3.3. X.509 Certificate Fields

okay so there are three extension fields in an X.509 certificate that exist to support certificate policies 🧚 they are:

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

3.3.1. Certificate Policies Extension

the Certificate Policies extension comes in two flavors, one flagged non-critical and one flagged critical 🦋 and the job of the field is different depending on which one you get, which is kind of the whole tea ☕

with a non-critical field, the certification authority is just saying "these policies apply to this cert" 📋 but it does NOT lock the certificate down to only those purposes. Taking the IATA example from Section 3.2, regular airline employees' certificates will carry the object identifier for the General-Purpose policy 🌈 Employees with disbursement authority get the object identifiers for both the General-Purpose and the Commercial-Grade policies. The field can also optionally carry qualifier values for each policy identified in it, and we'll get into qualifiers in Section 3.4 💜

the non-critical field is meant to be used by applications like this: each application is pre-configured to know which policy it needs 🤓 Going back to the Section 3.2 example, email apps and web servers get set up to require the General-Purpose policy. An airline's financial apps, though, are set up to require the Commercial-Grade policy before validating financial transactions above a certain dollar amount 💸

when you're processing a certification path, a certificate policy that the certificate-using application accepts has to show up in every certificate along the path, which means CA-certificates AND end entity certificates both. no skipping, bestie 🚫

now if the Certificate Policies field is flagged critical, it does everything the non-critical one does, PLUS it has an extra job 😭 it says the certificate can only be used according to one of the listed policies. So the certification authority is basically declaring "this cert must only be used in line with the rules of one of these policies." The point is to protect the CA from damage claims 💀 from a relying party who used the certificate for something inappropriate, or in a way the applicable policy definition doesn't allow.

here's the example they give: the Internal Revenue Service might issue certificates to taxpayers so they can protect their tax filings 🧾 The IRS is totally fine with the risk of accidentally issuing a bad certificate, like to someone who got authenticated wrongly. BUT imagine someone used an IRS tax-filing certificate to encrypt proprietary secrets worth millions of dollars, and those secrets leaked because the IRS certificate was issued in error 😱 The IRS would reasonably want protection from damage claims in a situation like that. The critical-flagged Certificate Policies extension exists to reduce that risk for the issuer 🛡️

3.3.2. Policy Mappings Extension

the Policy Mappings extension can ONLY be used in CA-certificates 🙅‍♀️ It lets a certification authority say that certain policies in its own domain are equivalent to certain other policies in the subject certification authority's domain 🔁

let's do an example 🎀 the ACE Corporation makes an agreement with the ABC Corporation to cross-certify each other's PKIs so they can mutually protect electronic data interchange (EDI). Both companies already have financial transaction protection policies, called ace-e-commerce and abc-e-commerce. Here's the problem: just generating cross certificates between the two domains will NOT give them the interoperability they need 😩 Why? Because each company's apps are configured with their own policy, and their employee certs are populated with their own policy too.

one fix would be reconfiguring all the financial apps to accept either policy, then reissuing every certificate with both policies. That's a lot of work 🥲 The other option, which is probably easier to administer, is the Policy Mappings field. If the ACE Corporation CA puts this field in the cross-certificate it issues for the ABC Corporation CA, it can state that ABC's financial transaction protection policy (abc-e-commerce) is equivalent to ACE's (ace-e-commerce) ✨ No reissuing needed, just a clean mapping!

3.3.3. Policy Constraints Extension

the Policy Constraints extension has two optional features 🧩

Feature one: a certification authority can require that explicit certificate policy indications show up in ALL the certificates that come after it in a certification path 🔒 Certificates at the very start of a path might be considered part of a trusted domain by a certificate user, meaning those CAs are trusted for everything, so no specific certificate policy is needed in the Certificate Policies extension. Those starting certificates don't need to contain explicit policy indications. BUT, when a CA in the trusted domain certifies something outside that domain, it can switch on the requirement for explicit certificate policy in every certificate that follows in the path 🚦

Feature two: a certification authority can disable policy mapping by the CAs that come after it in the path 🚫 It can be super prudent to turn policy mapping off when certifying outside your domain. This helps control risks from transitive trust. For instance, say domain A trusts domain B, and domain B trusts domain C. Domain A might NOT want to be forced into trusting domain C, and this feature helps it avoid that 🙅‍♀️

3.4. Policy Qualifiers

the Certificate Policies extension has a spot for attaching extra policy-dependent info, called a qualifier field, alongside each certificate policy identifier 🎁 The X.509 standard doesn't require any particular purpose for that field, and it doesn't prescribe a syntax for it either. Basically, it's wide open. Also, ANY organization can register policy qualifier types 🌍

the following policy qualifier types are defined in PKIX Part I [PKI1] 💖

  • (a) The CPS Pointer qualifier holds a pointer to a Certification Practice Statement (CPS) that the CA has published 📜 The pointer comes in the form of a uniform resource identifier (URI).
  • (b) The User Notice qualifier holds a text string that gets displayed to a certificate user (including subscribers and relying parties) before the certificate is used 👀 The text string can be an IA5String or a BMPString, which is a subset of the ISO 100646-1 multiple octet coded character set. A CA can also invoke a procedure that requires the certificate user to acknowledge that the applicable terms and conditions have been disclosed or accepted ✅

policy qualifiers can be used to support generic, or parameterized, certificate policy definitions 🌸 As long as the base certificate policy definition allows it, qualifier types can be defined to carry per-certificate details that fill in the generic definition. Think of it as the policy being a template and the qualifier being the custom bit that makes each cert specific 🫶

3.5 CERTIFICATION PRACTICE STATEMENT 📜

okay so the ABA Guidelines define a certification practice statement (CPS) like this 💅

"A statement of the practices which a certification authority employs in issuing certificates." [ABA1]

the 1995 draft of those guidelines goes further and adds these comments 🫶

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, or it may be a statute or regulation applicable to the certification authority and covering similar subject matter. It may also be part of the contract between the certification authority and the subscriber. A certification practice statement may also be comprised of multiple documents, a combination of public law, private contract, and/or declaration. Certain forms for legally implementing certification practice statements lend themselves to particular relationships. For example, when the legal relationship between a certification authority and subscriber is consensual, a contract would ordinarily be the means of giving effect to a certification practice statement. The certification authority's duties to a relying person are generally based on the certification authority's representations, which may include a certification practice statement. Whether a certification practice statement is binding on a relying person depends on whether the relying person has knowledge or notice of the certification practice statement. A relying person has knowledge or at least notice of the contents of the certificate used by the relying person to verify a digital signature, including documents incorporated into the certificate by reference. It is therefore advisable to incorporate a certification practice statement into a certificate by reference. As much as possible, a certification practice statement should indicate any of the widely recognized standards to which the certification authority's practices conform. Reference to widely recognized standards may indicate concisely the suitability of the certification authority's practices for another person's purposes, as well as the potential technological compatibility of the certificates issued by the certification authority with repositories and other systems.

3.6 RELATIONSHIP BETWEEN CERTIFICATE POLICY AND CERTIFICATION PRACTICE STATEMENT 🦋

certificate policy and CPS come from different places and were built for different reasons, but they're deeply connected, so let's talk about it 🌸

a CPS is a detailed statement from a certification authority about its practices, and subscribers and certificate users (relying parties) may need to read and check it. the level of detail can vary between CPSs, but they're generally more detailed than certificate policy definitions. honestly, CPSs can be super comprehensive, robust documents that describe the exact service offerings, detailed procedures for the life-cycle management of certificates, and more. that level of detail ties the CPS to one particular (proprietary) implementation of a service offering 👀

that detail can be totally necessary to disclose properly, and it's how you make a full assessment of trustworthiness when there's no accreditation or other recognized quality metrics. BUT a detailed CPS is NOT a good foundation for interoperability between CAs run by different organizations. instead, certificate policies are the best vehicle for building common interoperability standards and common assurance criteria across an industry (or maybe even more globally) 🌈 a CA with one CPS can support multiple certificate policies (used for different application purposes and/or by different certificate user communities). also, multiple different CAs, with non-identical certification practice statements, can support the same certificate policy.

for example, the Federal Government might define a government-wide certificate policy for handling confidential human resources information. the certificate policy definition is a broad statement of the general characteristics of that policy, plus an indication of the types of applications it's suitable for. different departments or agencies that run certification authorities with different certification practice statements might support this certificate policy. at the same time, those certification authorities may support other certificate policies too 💜

so the main difference between certificate policy and CPS can be summed up like this ✨

  • (a) Most organizations that operate public or inter-organizational certification authorities will document their own practices in CPSs or similar statements. The CPS is one of the organization's means of protecting itself and positioning its business relationships with subscribers and other entities.
  • (b) There is strong incentive, on the other hand, for a certificate policy to apply more broadly than to just a single organization. If a particular certificate policy is widely recognized and imitated, it has great potential as the basis of automated certificate acceptance in many systems, including unmanned systems and systems that are manned by people not independently empowered to determine the acceptability of different presented certificates.
also, a certification authority can add a reference to its certification practice statement in the certificates it issues, on top of filling in the certificate policies field with the certificate policy identifier. the standard way to do this uses a certificate policy qualifier, which is covered in Section 3.4.

3.7 SET OF PROVISIONS 🎀

a set of provisions is a collection of practice and/or policy statements that covers a range of standard topics. you use it to express a certificate policy definition or a CPS using the approach in this framework 🧚

a certificate policy can be expressed as a single set of provisions.

a CPS can be expressed as a single set of provisions, where each component addresses the requirements of one or more certificate policies. or, alternatively, it can be an organized collection of sets of provisions. for example, a CPS could be a combination of the following:

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

the statements in (b) and (c) may augment or refine the stipulations of the applicable certificate policy definition, but must not conflict with any of the stipulations of such certificate policy definition. 🫶

this framework lays out the contents of a set of provisions in terms of eight primary components 👑

  • Introduction;
  • General Provisions;
  • Identification and Authentication;
  • Operational Requirements;
  • Physical, Procedural, and Personnel Security Controls;
  • Technical Security Controls;
  • Certificate and CRL Profile; and
  • Specification Administration.

components can be split into subcomponents, and a subcomponent may contain multiple elements. Section 4 goes deeper into what those components and subcomponents contain 🔥

4. CONTENTS OF A SET OF PROVISIONS 💖

this section expands on the contents of a set of provisions, which we first met in Section 3.7. so the topics here are candidate topics for a certificate policy definition or CPS 🌷

there are a lot of topics, but a certificate policy or CPS doesn't need a concrete statement for every single one. instead, it can say "no stipulation" for any component, subcomponent, or element that it doesn't impose requirements on. basically, the list is a checklist for whoever is writing the certificate policy or CPS to think through 📝 it is recommended that each and every component and subcomponent be included in a certificate policy or CPS, even if there is "no stipulation". that tells the reader a conscious decision was made to include or exclude that topic. it protects against accidentally leaving a topic out, and it makes it easier to compare different certificate policies or CPSs, e.g., when making policy mapping decisions 🦋

a certificate policy definition can leave certain components, subcomponents, and/or elements unspecified, and state that the required information will be given in a policy qualifier. those are called parameterized definitions. the set of provisions should reference or define the required policy qualifier types and should specify any applicable default values 🍓

4.1 INTRODUCTION 🌈

this component identifies and introduces the set of provisions, and says which types of entities and applications the specification is aimed at.

this component has the following subcomponents:

  • Overview;
  • Identification;
  • Community and Applicability; and
  • Contact Details.

4.1.1 Overview ✨

this subcomponent gives a general introduction to the specification.

4.1.2 Identification 🔖

this subcomponent gives any applicable names or other identifiers, including ASN.1 object identifiers, for the set of provisions.

4.1.3 Community and Applicability 🌸

this subcomponent describes the types of entities that issue certificates or that are certified as subject CAs (2, 3), the types of entities that perform RA functions (4), and the types of entities that are certified as subject end entities or subscribers. (5, 6)

this subcomponent also contains:

  • A list of applications for which the issued certificates are suitable. (Examples of application in this case are: electronic mail, retail transactions, contracts, travel order, etc.)
  • A list of applications for which use of the issued certificates is restricted. (This list implicitly prohibits all other uses for the certificates.)
  • A list of applications for which use of the issued certificates is prohibited.

4.1.4 Contact Details 📬

this subcomponent includes the name and mailing address of the authority that is responsible for the registration, maintenance, and interpretation of this certificate policy or CPS. it also includes the name, electronic mail address, telephone number, and fax number of a contact person. 💜

4.2 General Provisions 🎀

okay so this component is where we spell out any presumptions about legal and general practices. not the most glamorous part, but it's giving foundation 💅

This component contains the following subcomponents:

  • Obligations;
  • Liability;
  • Financial Responsibility;
  • Interpretation and Enforcement;
  • Fees;
  • Publication and Repositories;
  • Compliance Audit;
  • Confidentiality; and
  • Intellectual Property Rights.

Each subcomponent may need to separately state provisions applying to the entity types: CA, repository, RA, subscriber, and relying party. (Specific provisions regarding subscribers and relying parties are only applicable in the Liability and Obligations subcomponents.) 🫶

4.2.1 Obligations 🧾

this subcomponent is the "who owes what to who" section 🔥 for each entity type, it can include any provisions about the entity's obligations to other entities. things it might cover:

  • CA and/or RA obligations:
    • Notification of issuance of a certificate to the subscriber who is the subject of the certificate being issued;
    • Notification of issuance of a certificate to others than the subject of the certificate;
    • Notification of revocation or suspension of a certificate to the subscriber whose certificate is being revoked or suspended; and
    • Notification of revocation or suspension of a certificate to others than the subject whose certificate is being revoked or suspended.
  • Subscriber obligations:
    • Accuracy of representations in certificate application;
    • Protection of the entity's private key;
    • Restrictions on private key and certificate use; and
    • Notification upon private key compromise.
  • Relying party obligations:
    • Purposes for which certificate is used;
    • Digital signature verification responsibilities;
    • Revocation and suspension checking responsibilities; and
    • Acknowledgment of applicable liability caps and warranties.
  • Repository obligations:
    • Timely publication of certificates and revocation information.

4.2.2 Liability ⚖️

this one covers, for each entity type, any provisions about how liability gets divvied up 😭 things like:

  • Warranties and limitations on warranties;
  • Kinds of damages covered (e.g., indirect, special, consequential, incidental, punitive, liquidated damages, negligence and fraud) and disclaimers;
  • Loss limitations (caps) per certificate or per transaction; and
  • Other exclusions (e.g., Acts of God, other party responsibilities).

4.2.3 Financial Responsibility 💸

for CAs, repository, and RAs, this subcomponent holds any provisions about financial responsibilities, such as:

  • Indemnification of CA and/or RA by relying parties;
  • Fiduciary relationships (or lack thereof) between the various entities; and
  • Administrative processes (e.g., accounting, audit).

4.2.4 Interpretation and Enforcement 📜

this is where any provisions about how to interpret and enforce the certificate policy or CPS go, covering topics like:

  • Governing law;
  • Severability of provisions, survival, merger, and notice; and
  • Dispute resolution procedures.

4.2.5 Fees 🪙

any provisions about fees charged by CAs, repositories, or RAs live here, like:

  • Certificate issuance or renewal fees;
  • Certificate access fee;
  • Revocation or status information access fee;
  • Fees for other services such as policy information; and
  • Refund policy.

4.2.6 Publication and Repositories 📚

this subcomponent contains any applicable provisions regarding:

  • A CA's obligations to publish information regarding its practices, its certificates, and the current status of such certificates;
  • Frequency of publication;
  • Access control on published information objects including certificate policy definitions, CPS, certificates, certificate status, and CRLs; and
  • Requirements pertaining to the use of repositories operated by CAs or by other independent parties.

4.2.7 Compliance Audit 🔍

this one addresses the following:

  • Frequency of compliance audit for each entity;
  • Identity/qualifictions of the auditor;
  • Auditor's relationship to the entity being audited; (30)
  • List of topics covered under the compliance audit; (31)
  • Actions taken as a result of a deficiency found during compliance audit; (32)
  • Compliance audit results: who they are shared with (e.g., subject CA, RA, and/or end entities), who provides them (e.g., entity being audited or auditor), how they are communicated.

4.2.8 Confidentiality Policy 🤫

main character secrets energy 🕵️‍♀️ this subcomponent addresses the following:

  • Types of information that must be kept confidential by CA or RA;
  • Types of information that are not considered confidential;
  • Who is entitled to be informed of reasons for revocation and suspension of certificates;
  • Policy on release of information to law enforcement officials;
  • Information that can be revealed as part of civil discovery;
  • Conditions upon which CA or RA may disclose upon owner's request; and
  • Any other circumstances under which confidential information may be disclosed.

4.2.9 Intellectual Property Rights 🦋

this subcomponent addresses ownership rights of certificates, practice/policy specifications, names, and keys. who owns what, basically ✨

4.3 Identification and Authentication 🪪

this component describes the procedures used to authenticate a certificate applicant to a CA or RA before certificate issuance happens. it also covers how parties asking for rekey or revocation get authenticated. and it touches on naming practices too, including name ownership recognition and name dispute resolution 🌸

This component has the following subcomponents:

  • Initial Registration;
  • Routine Rekey;
  • Rekey After Revocation; and
  • Revocation Request.

4.3.1 Initial Registration 🌱

this subcomponent includes the following elements about identification and authentication during entity registration or certificate issuance:

  • Types of names assigned to the subject (7);
  • Whether names have to be meaningful or not (8);
  • Rules for interpreting various name forms;
  • Whether names have to be unique;
  • How name claim disputes are resolved;
  • Recognition, authentication, and role of trademarks;
  • If and how the subject must prove possession of the companion private key for the public key being registered (9);
  • Authentication requirements for organizational identity of subject (CA, RA, or end entity) (10);
  • Authentication requirements for a person acting on behalf of a subject (CA, RA, or end entity) (11), including:
    • Number of pieces of identification required;
    • How a CA or RA validates the pieces of identification provided;
    • If the individual must present personally to the authenticating CA or RA;
    • How an individual as an organizational person is authenticated (12).

4.3.2 Routine Rekey 🔄

this subcomponent describes the identification and authentication procedures for routine rekey for each subject type (CA, RA, and end entity). (13)

4.3.3 Rekey After Revocation -- No Key Compromise 🙅‍♀️🔑

this subcomponent describes the identification and authentication procedures for rekey for each subject type (CA, RA, and end entity) after the subject certificate has been revoked. (14)

4.3.4 Revocation Request 🚫

this subcomponent describes the identification and authentication procedures for a revocation request by each subject type (CA, RA, and end entity). (16)

4.4 Operational Requirements ⚙️

this component specifies requirements imposed on issuing CA, subject CAs, RAs, or end entities for various operational activities. it's the behind-the-scenes choreography 💃

This component consists of the following subcomponents:

  • Certificate Application;
  • Certificate Issuance;
  • Certificate Acceptance;
  • Certificate Suspension and Revocation;
  • Security Audit Procedures;
  • Records Archival;
  • Key Changeover;
  • Compromise and Disaster Recovery; and
  • CA Termination.

Within each subcomponent, separate consideration may need to be given to issuing CA, repository, subject CAs, RAs, and end entities. 🧚

4.4.1 Certificate Application 📝

this subcomponent is used to state requirements about subject enrollment and request for certificate issuance 🍓

4.4.2 Certificate Issuance 🎁

this subcomponent is used to state requirements about issuance of a certificate and notification to the applicant of such issuance ✨

4.4.3 Certificate Acceptance 👍

this subcomponent is used to state requirements about acceptance of an issued certificate and for the consequent publication of certificates 💜

4.4.4 Certificate Suspension and Revocation ⏸️🛑

this subcomponent addresses the following:

  • Circumstances under which a certificate may be revoked;
  • Who can request the revocation of the entity certificate;
  • Procedures used for certificate revocation request;
  • Revocation request grace period available to the subject;
  • Circumstances under which a certificate may be suspended;
  • Who can request the suspension of a certificate;
  • Procedures to request certificate suspension;
  • How long the suspension may last;
  • If a CRL mechanism is used, the issuance frequency;
  • Requirements on relying parties to check CRLs;
  • On-line revocation/status checking availability;
  • Requirements on relying parties to perform on-line revocation/status checks;
  • Other forms of revocation advertisements available; and
  • Requirements on relying parties to check other forms of revocation advertisements.
  • Any variations on the above stipulations when the suspension or revocation is the result of private key compromise (as opposed to other reasons for suspension or revocation).

4.4.5 Security Audit Procedures 🛡️

this subcomponent describes event logging and audit systems, set up to keep the environment secure 🔐 elements include the following:

  • Types of events recorded; (28)
  • Frequency with which audit logs are processed or audited;
  • Period for which audit logs are kept;
  • Protection of audit logs:
    • Who can view audit logs;
    • Protection against modification of audit log; and
    • Protection against deletion of audit log.
  • 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.

4.4.6 Records Archival 📚✨

Okay bestie, records archival (aka records retention) policies are all about keeping receipts 🧾💅. Your policy needs to cover all of this:

  • Types of events recorded (29);
  • Retention period for archive;
  • Protection of archive:
    • Who can view the archive;
    • Protection against modification of archive; and
    • Protection against deletion of archive.
  • 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.

4.4.7 Key Changeover 🔑🦋

This one is about how a CA gets a brand new public key into the hands of its users. Big glow-up moment 🌸✨

4.4.8 Compromise and Disaster Recovery 🚨💜

This part is the "oh no, what now?" section 😭. It covers notification and recovery stuff for when things go wrong. Each of these situations might need its own plan, so think about them separately 🧩.

  • 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 reestablished, 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 recertified.
  • The recovery procedures used if the entity public key is revoked. These procedures describe how a secure environment is reestablished, how the new entity public key is provided to the users, and how the subjects are recertified.
  • The recovery procedures used if the entity key is compromised. These procedures describe how a secure environment is reestablished, how the new entity public key is provided to the users, and how the subjects are recertified.
  • The CA's procedures for securing its facility during the period of time following a natural or other disaster and before a secure environment is reestablished either at the original site or a remote hot-site. For example, procedures to protect against theft of sensitive materials from an earthquake-damaged site.

4.4.9 CA Termination 🌅🫶

This subcomponent is about the goodbye process 😢. It covers the requirements for terminating a CA or RA, how termination gets notified, and the identity of the custodian of CA and RA archival records. Make sure someone is clearly responsible for those records!

4.5 PHYSICAL, PROCEDURAL, AND PERSONNEL SECURITY CONTROLS 🔐

This component is the non-technical security stuff: physical, procedural, and personnel controls. The issuing CA uses these to securely handle key generation, subject authentication, certificate issuance, certificate revocation, audit, and archival 🛡️.

This component can also define non-technical security controls for the repository, subject CAs, RAs, and end entities. Those controls for subject CAs, RAs, and end entities could be the same, similar, or very different 🤷‍♀️.

These non-technical controls are super critical for trusting certificates 💯. If security is lacking, CA operations can get messed up, which might lead to certificates or CRLs with wrong information, or to the CA private key getting compromised. Yikes 😱.

This component has three subcomponents:

  • Physical Security Controls;
  • Procedural Controls; and
  • Personnel Security Controls.

Within each subcomponent, you'll generally need to think separately about each entity type: issuing CA, repository, subject CAs, RAs, and end entities 🧠.

4.5.1 Physical Security Controls 🏢

This subcomponent describes the physical controls on the facility that houses the entity systems (21). Topics it may cover include:

  • Site location and construction;
  • Physical access;
  • Power and air conditioning;
  • Water exposures;
  • Fire prevention and protection;
  • Media storage;
  • Waste disposal; and
  • Off-site backup.

4.5.2 Procedural Controls 📋

This subcomponent describes the requirements for recognizing trusted roles, along with the responsibilities for each role (22).

For each task identified for each role, you should also state how many individuals are required to perform the task (n out m rule). Identification and authentication requirements for each role may also be defined 🪪.

4.5.3 Personnel Security Controls 👩‍💼

This subcomponent covers the following:

  • Background checks and clearance procedures required for the personnel filling the trusted roles; (23)
  • Background checks and clearance procedures requirements for other personnel, including janitorial staff; (24)
  • Training requirements and training procedures for each role;
  • Any retraining period and retraining procedures for each role;
  • 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; (25)
  • Controls on contracting personnel, including:
    • Bonding requirements on contract personnel;
    • Contractual requirements including indemnification for damages due to the actions of the contractor personnel;
    • Audit and monitoring of contractor personnel; and
    • Other controls on contracting personnel.
  • Documentation to be supplied to personnel.

4.6 TECHNICAL SECURITY CONTROLS 💻🔒

This component defines 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 can also put constraints on repositories, subject CAs, and end entities so they protect their cryptographic keys and critical security parameters. Secure key management is a must, so 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 the issuing CA uses to securely do key generation, user authentication, certificate registration, certificate revocation, audit, and archival. Technical controls include life-cycle security controls (including software development environment security, trusted software development methodology) and operational security controls ⚙️.

This component can also define other technical security controls for repositories, subject CAs, RAs, and end entities.

This component has these subcomponents:

  • Key Pair Generation and Installation;
  • Private Key Protection;
  • Other Aspects of Key Pair Management;
  • Activation Data;
  • Computer Security Controls;
  • Life-Cycle Security Controls;
  • Network Security Controls; and
  • Cryptographic Module Engineering Controls.

4.6.1 Key Pair Generation and Installation 🔑✨

Key pair generation and installation need to be considered for the issuing CA, repositories, subject CAs, RAs, and subject end entities. For each of these entity types, these questions potentially need answers:

  1. Who generates the entity public, private key pair?
  2. How is the private key provided securely to the entity?
  3. How is the entity's public key provided securely to the certificate issuer?
  4. If the entity is a CA (issuing or subject) how is the entity's public key provided securely to the users?
  5. What are the key sizes?
  6. Who generates the public key parameters?
  7. Is the quality of the parameters checked during key generation?
  8. Is the key generation performed in hardware or software?
  9. 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 the Version 3, X.509 certificates)?

4.6.2 Private Key Protection 🛡️🔐

Requirements for private key protection need to be considered for the issuing CA, repositories, subject CAs, RAs, and subject end entities. For each of these entity types, these questions potentially need answers:

  1. What standards, if any, are required for the module used to generate the keys? For example, are the keys certified by the infrastructure required to be generated using modules complaint with the US FIPS 140-1? If so, what is the required FIPS 140-1 level of the module?
  2. Is the private key under n out of m multi-person control? (18) 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? (19) 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. Who enters the private key in the cryptographic module? In what form (i.e., plaintext, encrypted, or split key)? How is the private key stored in the module (i.e., plaintext, encrypted, or split key)?
  7. 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?
  8. Who can deactivate the private key and how? Example of how might include, logout, power off, remove token/key, automatic, or time expiration.
  9. Who can destroy the private key and how? Examples of how might include token surrender, token destruction, or key overwrite.

4.6.3 Other Aspects of Key Pair Management 🗂️💫

Other aspects of key management need to be considered for the issuing CA, repositories, subject CAs, RAs, and subject end entities. For each of these entity types, these questions potentially 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? The archival system should provide integrity controls other than digital signatures since: the archival period may be greater than the cryptanalysis period for the key and the archive requires tamper protection, which is not provided by digital signatures.
  2. What are the usage periods, or active lifetimes, for the public and the private key respectively?

4.6.4 Activation Data ✨

Okay so activation data is any data that isn't a key but still has to be there to operate cryptographic modules, and it needs protecting too 🔐 (20). 💖 Protection of activation data potentially needs to be considered for the issuing CA, subject CAs, RAs, and end entities. The whole life-cycle needs a look, from generation through archival and destruction 🧚. For each entity type (issuing CA, repository, subject CA, RA, and end entity), all the questions from 4.6.1 through 4.6.3 potentially need answering, just about activation data instead of keys 💅.

4.6.5 Computer Security Controls 🛡️

This part covers computer security controls like the trusted computing base concept, discretionary access control, labels, mandatory access controls, object reuse, audit, identification and authentication, trusted path, security testing, and penetration testing 👑. Product assurance may also get addressed here.

A computer security rating for computer systems may be required 📋. The rating could be based on things like the Trusted System Evaluation Criteria (TCSEC), the Canadian Trusted Products Evaluation Criteria, the European Information Technology Security Evaluation Criteria (ITSEC), or the Common Criteria 🌈. This subcomponent can also cover product evaluation analysis, testing, profiling, product certification, and/or product accreditation activity, whatever gets done 🫶.

4.6.6 Life Cycle Security Controls 🔄

This subcomponent is all about 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 running tools and procedures so the operational systems and networks stick to their configured security. Those tools and procedures include checking the integrity of the security software, firmware, and hardware to make sure they're working correctly ✨.

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

4.6.7 Network Security Controls 🌐

This subcomponent covers network security related controls, including firewalls 🔥.

4.6.8 Cryptographic Module Engineering Controls (26) ⚙️

This subcomponent covers the following aspects of a cryptographic module: 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 🦋. Requirements may be expressed by referring to a standard such as U.S. FIPS 140-1 (27) 📚.

4.7 CERTIFICATE AND CRL PROFILES 📜

This component specifies the certificate format and, if CRLs are used, the CRL format 💅. Assuming the X.509 certificate and CRL formats are in use, this covers the profiles, versions, and extensions used 🌸.

This component has two subcomponents:

  • Certificate Profile; and
  • CRL Profile.

4.7.1 Certificate Profile 🎟️

This subcomponent addresses topics like the following (potentially by reference to a separate profile definition, such as the PKIX Part I profile) 💖:

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

4.7.2 CRL Profile 🧾

This subcomponent addresses topics like the following (potentially by reference to a separate profile definition, such as the PKIX Part I profile) ✨:

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

4.8 SPECIFICATION ADMINISTRATION 🗂️

This component specifies how this particular certificate policy definition or CPS gets maintained 🫶.

It contains the following subcomponents:

  • Specification Change Procedures;
  • Publication and Notification Procedures; and
  • CPS Approval Procedures.

4.8.1 Specification Change Procedures 🔁

Okay so certificate policies and Certification Practice Statements will occasionally need changes 💅. Some changes won't materially reduce the assurance that a certificate policy or its implementation provides, and the policy administrator will judge them as not changing the acceptability of certificates asserting the policy for the purposes they've been used for 🌈. Those changes don't need a change in the certificate policy Object Identifier or the CPS pointer (URL) ✨. Other changes will change the acceptability of certificates for specific purposes, and those do require changes to the certificate policy Object Identifier or CPS pointer (URL) 🚨.

This subcomponent contains the following information:

  • A list of specification components, subcomponents, and/or elements thereof that can be changed without notification and without changes to the certificate policy Object Identifier or CPS pointer (URL).
  • A list of specification components, subcomponents, and/or elements thereof that may change following a notification period without changing the certificate policy Object Identifier or CPS pointer (URL). The procedures used to notify interested parties (relying parties, certification authorities, etc.) of the certificate policy or CPS changes are described here. The description of notification procedures includes the notification mechanism, notification period for comments, mechanism to receive, review and incorporate the comments, mechanism for final changes to the policy, and the period before final changes become effective 📣.
  • A list of specification components, subcomponents, and/or elements, changes to which require a change in certificate policy Object Identifier or CPS pointer (URL).. 💜

4.8.2 Publication and Notification Procedures 📢

This subcomponent contains the following elements:

  • A list of components, subcomponents, and elements thereof that exist but that are not made publicly available (33) 🙈.
  • Descriptions of mechanisms used to distribute the certificate policy definition or CPS, including access controls on such distribution 🔐.

4.8.3 CPS Approval Procedures ✅

In a certificate policy definition, this subcomponent describes how the compliance of a specific CPS with the certificate policy can be determined 🦋.

5. OUTLINE OF A SET OF PROVISIONS ✨

okay bestie, this section is basically a checklist 🧾💅 It's a possible outline for a set of provisions, and it's meant to be used as a template (or a starting point) by people writing certificate policies or CPSs 🌸 Having one shared layout is seriously helpful because it makes it way easier to:

  • (a) compare two certificate policies during cross-certification, so you can map which parts are equivalent 🗺️
  • (b) compare a CPS with a certificate policy definition and check that the CPS faithfully implements the policy 🔍
  • (c) compare two CPSs 🦋

Here's the full outline, copied exactly as written:

   1.   INTRODUCTION

   1.1  Overview

   1.2  Identification

   1.3  Community and Applicability
      1.3.1  Certification authorities
      1.3.2  Registration authorities
      1.3.3  End entities
      1.3.4  Applicability

   1.4  Contact Details
      1.4.1  Specification administration organization
      1.4.2  Contact person
      1.4.3  Person determining CPS suitability for the policy

   2.  GENERAL PROVISIONS

   2.1  Obligations

      2.1.1  CA obligations
      2.1.2  RA obligations
      2.1.3  Subscriber obligations
      2.1.4  Relying party obligations
      2.1.5  Repository obligations

   2.2  Liability

      2.2.1  CA liability
      2.2.2  RA liability

   2.3  Financial responsibility

      2.3.1  Indemnification by relying parties
      2.3.2  Fiduciary relationships
      2.3.3  Administrative processes

   2.4  Interpretation and Enforcement

      2.4.1  Governing law
      2.4.2  Severability, survival, merger, notice
      2.4.3  Dispute resolution procedures

   2.5  Fees

      2.5.1  Certificate issuance or renewal fees
      2.5.2  Certificate access fees
      2.5.3  Revocation or status information access fees
      2.5.4  Fees for other services such as policy information
      2.5.5  Refund policy

   2.6  Publication and Repository

      2.6.1  Publication of CA information
      2.6.2  Frequency of publication
      2.6.3  Access controls
      2.6.4  Repositories

   2.7  Compliance audit

      2.7.1  Frequency of entity compliance audit
      2.7.2  Identity/qualifications of auditor
      2.7.3  Auditor's relationship to audited party
      2.7.4  Topics covered by audit
      2.7.5  Actions taken as a result of deficiency
      2.7.6  Communication of results

   2.8  Confidentiality

      2.8.1  Types of information to be kept confidential
      2.8.2  Types of information not considered confidential
      2.8.3  Disclosure of certificate revocation/suspension information
      2.8.4  Release to law enforcement officials
      2.8.5  Release as part of civil discovery
      2.8.6  Disclosure upon owner's request
      2.8.7  Other information release circumstances

   2.9  Intellectual Property Rights

   3.   IDENTIFICATION AND AUTHENTICATION (34)

   3.1  Initial Registration
      3.1.1  Types of names
      3.1.2  Need for names to be meaningful
      3.1.3  Rules for interpreting various name forms
      3.1.4  Uniqueness of names
      3.1.5  Name claim dispute resolution procedure
      3.1.6  Recognition, authentication and role of trademarks
      3.1.7  Method to prove possession of private key
      3.1.8  Authentication of organization identity
      3.1.9  Authentication of individual identity

   3.2  Routine Rekey

   3.3  Rekey after Revocation
   3.4  Revocation Request

   4.  OPERATIONAL REQUIREMENTS (34)

   4.1  Certificate Application

   4.2  Certificate Issuance

   4.3  Certificate Acceptance

   4.4  Certificate Suspension and Revocation
      4.4.1  Circumstances for revocation
      4.4.2  Who can request revocation
      4.4.3  Procedure for revocation request
      4.4.4  Revocation request grace period
      4.4.5  Circumstances for suspension
      4.4.6  Who can request suspension
      4.4.7  Procedure for suspension request
      4.4.8  Limits on suspension period
      4.4.9  CRL issuance frequency (if applicable)
      4.4.10  CRL checking requirements
      4.4.11  On-line revocation/status checking availability
      4.4.12  On-line revocation checking requirements
      4.4.13  Other forms of revocation advertisements available
      4.4.14  Checking  requirements  for  other  forms  of  revocation
              advertisements
      4.4.15  Special requirements re key compromise

   4.5  Security Audit Procedures
      4.5.1  Types of event recorded
      4.5.2  Frequency of processing log
      4.5.3  Retention period for audit log
      4.5.4  Protection of audit log
      4.5.5  Audit log backup procedures
      4.5.6  Audit collection system (internal vs external)
      4.5.7  Notification to event-causing subject
      4.5.8  Vulnerability assessments

   4.6  Records Archival

      4.6.1  Types of event recorded
      4.6.2  Retention period for archive
      4.6.3  Protection of archive
      4.6.4  Archive backup procedures
      4.6.5  Requirements for time-stamping of records
      4.6.6  Archive collection system (internal or external)
      4.6.7  Procedures to obtain and verify archive information

   4.7  Key changeover

   4.8  Compromise and Disaster Recovery
      4.8.1 Computing resources, software, and/or data are corrupted
      4.8.2 Entity public key is revoked
      4.8.3 Entity key is compromised
      4.8.4 Secure facility after a natural or other type of disaster

   4.9  CA Termination

   5.  PHYSICAL, PROCEDURAL, AND PERSONNEL SECURITY CONTROLS (34)

   5.1  Physical Controls
      5.1.1  Site location and construction
      5.1.2  Physical access
      5.1.3  Power and air conditioning
      5.1.4  Water exposures
      5.1.5  Fire prevention and protection
      5.1.6  Media storage
      5.1.7  Waste disposal
      5.1.8  Off-site backup

   5.2  Procedural Controls
      5.2.1  Trusted roles
      5.2.2  Number of persons required per task
      5.2.3  Identification and authentication for each role

   5.3  Personnel Controls
      5.3.1  Background, qualifications, experience, and  clearance
             requirements
      5.3.2  Background check procedures
      5.3.3  Training requirements
      5.3.4  Retraining frequency and requirements
      5.3.5  Job rotation frequency and sequence
      5.3.6  Sanctions for unauthorized actions
      5.3.7  Contracting personnel requirements
      5.3.8  Documentation supplied to personnel

   6.  TECHNICAL SECURITY CONTROLS (34)

   6.1  Key Pair Generation and Installation
      6.1.1  Key pair generation
      6.1.2  Private key delivery to entity
      6.1.3  Public key delivery to certificate issuer
      6.1.4  CA public key delivery to users
      6.1.5  Key sizes
      6.1.6  Public key parameters generation
      6.1.7  Parameter quality checking
      6.1.8  Hardware/software key generation
      6.1.9  Key usage purposes (as per X.509 v3 key usage field)

   6.2  Private Key Protection
      6.2.1  Standards for cryptographic module
      6.2.2  Private key (n out of m) multi-person control
      6.2.3  Private key escrow
      6.2.4  Private key backup
      6.2.5  Private key archival
      6.2.6  Private key entry into cryptographic module
      6.2.7  Method of activating private key
      6.2.8  Method of deactivating private key
      6.2.9  Method of destroying private key

   6.3  Other Aspects of Key Pair Management
      6.3.1  Public key archival
      6.3.2  Usage periods for the public and private keys

   6.4  Activation Data
      6.4.1  Activation data generation and installation
      6.4.2  Activation data protection
      6.4.3  Other aspects of activation data

   6.5  Computer Security Controls
      6.5.1  Specific computer security technical requirements
      6.5.2  Computer security rating

   6.6  Life Cycle Technical Controls
      6.6.1  System development controls
      6.6.2  Security management controls
      6.6.3  Life cycle security ratings

   6.7  Network Security Controls

   6.8  Cryptographic Module Engineering Controls

   7.  CERTIFICATE AND CRL PROFILES

   7.1  Certificate Profile

      7.1.1  Version number(s)
      7.1.2  Certificate extensions
      7.1.3  Algorithm object identifiers
      7.1.4  Name forms
      7.1.5  Name constraints
      7.1.6  Certificate policy Object Identifier
      7.1.7  Usage of Policy Constraints extension
      7.1.8  Policy qualifiers syntax and semantics
      7.1.9  Processing  semantics  for  the critical certificate policy
             extension

   7.2  CRL Profile

      7.2.1  Version number(s)
      7.2.2  CRL and CRL entry extensions

   8.  SPECIFICATION ADMINISTRATION

   8.1  Specification change procedures

   8.2  Publication and notification policies

   8.3  CPS approval procedures

6. ACKNOWLEDGMENTS 🫶

big thank-yous to the people and groups who made this doc happen 💖 The work was supported by 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 Technical Working Group 🌈 Special thanks to Dave Fillingham, Jim Brandt, and Edmond Van Hees for their inspiration, support, and valuable inputs ✨

The following individuals also deserve credit for their review and input:

  • Teresa Acevedo, A&N Associates;
  • Michael Baum; VeriSign;
  • Sharon Boeyen, Entrust;
  • Bob Burger, McCarter & English;
  • Bill Burr, NIST;
  • Patrick Cain, BBN;
  • Michael Harrop, Government of Canada Treasury Board;
  • Rick Hornbeck, Digital Commerce Services;
  • Francois Marinier, Domus Software;
  • John Morris, CygnaCom Solutions;
  • Tim Moses, Entrust;
  • Noel Nazario, NIST;
  • John Nicolletos, A&N Associates;
  • Jean Petty, CygnaCom Solutions;
  • Denis Pinkas, Bull;
  • J.-F. Sauriol, Domus Software;
  • Robert Shirey, BBN;
  • Mark Silvern, VeriSign;
  • David Simonetti, Booz, Allen and Hamilton; and
  • Darryl Stal, Entrust.

Johnny Hsiung, and Chris Miller assisted in the preparation of the manuscript 🧚

7. REFERENCES 📚

  • [ABA1] American Bar Association, Digital Signature Guidelines: Legal Infrastructure for Certification Authorities and Electronic Commerce, 1995.
  • [BAU1] Michael. S. Baum, Federal Certification Authority Liability and Policy, NIST-GCR- 94-654, June 1994.
  • [ISO1] ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information Technology - Open Systems Interconnection: The Directory: Authentication Framework," 1997 edition. (Pending publication of 1997 edition, use 1993 edition with the following amendment applied: Final Text of Draft Amendment DAM 1 to ISO/IEC 9594-8 on Certificate Extensions, June 1996.)
  • [PEM1] Kent, S., "Privacy Enhancement for Internet Electronic Mail, Part II: Certificate-Based Key Management", RFC 1422, February 1993.
  • [PKI1] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure, Certificate and CRL Profile", RFC 2459, January 1999.

8. AUTHORS' ADDRESSES 💌

Santosh Chokhani

Santosh Chokhani
CygnaCom Solutions, Inc.
Suite 100 West
7927 Jones Branch Drive
McLean, VA 22102

Phone: (703) 848-0883
Fax: (703) 848-0960
EMail: chokhani@cygnacom.com

Warwick Ford

Warwick Ford
VeriSign, Inc.
301 Edgewater Place, Suite 210
Wakefield, MA 01880

Phone: (781) 245-6996 x225
Fax: (781) 245-6006
EMail: wford@verisign.com

NOTES ✨

  1. The ABA Digital Signature Guidelines can be bought from the ABA. Check http://www.abanet.com for ordering details.
  2. Examples of subject CA types are a subordinate organization (like a branch or division), a federal government agency, or a state or provincial government department.
  3. This one has big implications 👀. Say a bank claims it only issues CA certificates to its branches. If you're the user of a CA certificate that bank issued, you can assume the subject CA is a branch of the bank.
  4. Examples of subject RA entity types are a branch or a division of an organization.
  5. Examples of subject end entity types are bank customers, telephone company subscribers, and employees of a government department.
  6. Another big-implications one 💅. Say a Government CA claims it only issues certificates to Government employees. If you're using a certificate the Government CA issued, you can assume the certificate's subject is a Government employee.
  7. Examples include an X.500 distinguished name, an Internet e-mail address, and a URL.
  8. "Meaningful" means the name form has commonly understood semantics for working out who a person and/or organization is. Directory names and RFC 822 names may be more or less meaningful 🤔.
  9. Examples of proof are the issuing CA generating the key, or requiring the subject to send an electronically signed request or to sign a challenge.
  10. Examples of organization identity authentication are articles of incorporation, duly signed corporate resolutions, a company seal, and notarized documents.
  11. Examples of individual identity authentication are biometrics (a thumb print, ten finger prints, a face, a palm, or a retina scan), a driver's license, a passport, a credit card, a company badge, and a government badge 🪪.
  12. Examples include duly signed authorization papers or a corporate ID badge.
  13. The identification policy for routine rekey should be the same as the one for initial registration, since the same subject needs rekeying. The rekey authentication may use the techniques for initial I&A or digitally signed requests 🔁.
  14. This identification and authentication policy could be the same as the one for initial registration.
  15. This policy could be the same as the one for initial registration.
  16. The identification policy for a revocation request could be the same as the one for initial registration, since the same subject certificate needs to be revoked. The authentication policy could accept a revocation request digitally signed by the subject. The authentication information used during initial registration could be acceptable for a revocation request. Other, less stringent authentication policies could be defined 🙈.
  17. The identification policy for key compromise notification could be the same as the one for initial registration, since the same subject certificate needs to be revoked. The authentication policy could accept a revocation request digitally signed by the subject. The authentication information used during initial registration could be acceptable for key compromise notification. Other, less stringent authentication policies could be defined 😭.
  18. The n out of m rule lets a key be split into m parts. The m parts may be given to m different individuals. Any n of the m parts can fully reconstitute the key, but having any n-1 parts gives you zero information about the key 🧩.
  19. A key may be escrowed, backed up, or archived, and each of these has a different purpose. So a key can go through any subset of these functions, depending on the requirements. Escrow lets a third party (like an organization or government) legally get the key without the subject's cooperation. Backup lets the subject rebuild the key if the key gets destroyed. Archive lets the key be reused in the future, for example using a private key to decrypt a document 🗄️.
  20. An example of activation data is a PIN or a passphrase 🔑.
  21. Examples of physical access controls are a monitored facility, a guarded facility, a locked facility, access controlled using tokens, access controlled using biometrics, and access controlled through an access list 🚪.
  22. Examples of roles include the system administrator, the system security officer, and the system auditor 👑. The system administrator's duties are to configure, generate, boot, and operate the system. The system security officer's duties are to assign accounts and privileges. The system auditor's duties are to set up the system audit profile, perform audit file management, and do audit review.
  23. Background checks may include a clearance level (none, sensitive, confidential, secret, top secret, and so on) and the name of the clearance granting authority. Instead of or in addition to a defined clearance, background checks may cover types of background information, like name, place of birth, date of birth, home address, previous residences, previous employment, and anything else that helps decide trustworthiness. The description should also say which information was verified and how 🕵️‍♀️.
  24. For example, the certificate policy may impose personnel security requirements on the network system administrator who's responsible for a CA's network access.
  25. Whether or not the authorized persons are employees, practices should be in place to make sure each authorized person is held accountable for their own actions 🫶.
  26. A cryptographic module is hardware, software, or firmware, or any combination of them 🔐.
  27. The compliance description should be specific and detailed. For example, for each FIPS 140-1 requirement, describe the level and whether that level has been certified by an accredited laboratory ✅.
  28. Examples of audit events are a request to create a certificate, a request to revoke a certificate, key compromise notification, creation of a certificate, revocation of a certificate, issuance of a certificate, issuance of a CRL, issuance of a key compromise CRL, establishment of trusted roles on the CA, actions of trusted personnel, changes to CA keys, and so on 📋.
  29. Examples of archive events are a request to create a certificate, a request to revoke a certificate, key compromise notification, creation of a certificate, revocation of a certificate, issuance of a certificate, issuance of a CRL, issuance of a key compromise CRL, and changes to CA keys 🗃️.
  30. A parent CA is an example of an audit relationship 🌳.
  31. Examples of compliance audit topics are a sample check on the various I&A policies, comprehensive checks on key management policies, comprehensive checks on system security controls, comprehensive checks on operations policy, and comprehensive checks on certificate profiles 🔍.
  32. Examples include temporarily suspending operations until deficiencies are corrected, revoking an entity's certificate, a change in personnel, invoking the liability policy, a more frequent compliance audit, and so on ⚠️.
  33. An organization may choose not to make public some of its security controls, clearance procedures, or other elements because of their sensitivity 🤫.
  34. All or some of the following items may be different for the various types of entities, meaning CA, RA, and end entities 💜.

LIST OF ACRONYMS 🧚

  • ABA - American Bar Association
  • CA - Certification Authority
  • 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

Here's the official notice, verbatim:

Copyright (C) The Internet Society (1999).  All Rights Reserved.

Okay, the permissions part is where the Internet Society is being generous 🥹. You can copy and share this document and translations of it, and you can make derivative works that comment on or explain it or help people implement it. You can publish and distribute those, in whole or in part, with no restrictions, as long as the copyright notice and this paragraph are on every copy and derivative work 🎀.

The catch is that you can't modify this document itself in any way. That means no removing the copyright notice or the references to the Internet Society or other Internet organizations. The one exception is when it's needed to develop Internet standards, and then the copyright procedures in the Internet Standards process have to be followed. Translating it into languages other than English is also allowed 🌍.

These limited permissions are perpetual, and the Internet Society or its successors or assigns will never revoke them 🦋.

The disclaimer, in full: this document and the information in it are provided "AS IS," and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. So no promises from them, bestie 💀.
📦 where this page comes from