RFC 1422

Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management

📅 published February 1993, from ietf

Okay bestie, let's get into it 🎀 This is RFC 1422, Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management. It's from February 1993 and written by S. Kent at BBN, with the IAB IRTF PSRG and IETF PEM crew on the header. It's an IAB standards track protocol, and it obsoletes RFC 1114 💅 so 1114 is officially out and 1422 is in. The header doesn't list any updates. It's also part II of a whole series of email privacy docs 💌

Status of this Memo ✨

So this RFC is an IAB standards track protocol for the Internet community 🧚 It's basically asking for discussion and suggestions for improvements 💬 For the current standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards" 📚 And distribution of this memo is unlimited 🌈

Acknowledgements 🫶

This memo is the result of a bunch of meetings held by the Privacy and Security Research Group of the Internet Research Task Force (IRTF) and the Privacy-Enhanced Electronic Mail Working Group of the Internet Engineering Task Force (IETF). The author wants to thank everyone in the PSRG and the PEM WG who gave comments and contributions at those meetings and helped shape the document 🥹 Shoutout also to the folks on the PEM-DEV mailing list, whose input made it into this memo too 💜

1. Executive Summary 💖

This is one of a series of docs that define privacy enhancement mechanisms for email sent over Internet mail protocols 💌 RFC 1421 [6] lays out protocol extensions and processing procedures for RFC-822 mail messages, as long as originators and recipients already hold suitable cryptographic keys. That's the big precondition ✨ RFC 1423 [7] covers the algorithms, modes and associated identifiers used when processing privacy-enhanced messages, as called for in RFC 1421 and this doc 🔐 This document is the supporting key management architecture and infrastructure, built on public-key certificate techniques, that gives keying info to message originators and recipients 🗝️ And RFC 1424 [8] adds extra specs for services that run alongside the key management infrastructure described here 🧁

Okay so the key management architecture here is compatible with the authentication framework in CCITT 1988 X.509 [2] 🫶 But this doc goes beyond X.509 by setting up procedures and conventions for a key management infrastructure to be used with Privacy Enhanced Mail (PEM), and with other protocols from both the TCP/IP and OSI suites down the line 🚀 Why not just rely on the very general X.509 framework? There are a few reasons, and they're giving very good reasons:

  • It matters that a certificate management infrastructure for the Internet community can handle a range of clearly-articulated certification policies for both users and organizations, in a well-architected way 📋 Every user needs to be able to tell which policies govern any certificate they might run into 👀 Introducing and standardizing these procedures and conventions means going outside the scope of X.509 💅
  • Authenticating originators and recipients during message submission and delivery should be simple, automated and uniform, even when certificate management policies differ 🤍 For example, users shouldn't have to carefully go through a complicated set of certification relationships just to check whether a claimed identity is credible 🙅‍♀️
  • The X.509 authentication framework is designed to run in the X.500 directory server environment 🗂️ But X.500 directory servers aren't expected to be everywhere on the Internet in the near future, so some conventions are adopted to make the key management infrastructure work in the near term ⏰
  • Public key cryptosystems are central to X.509 authentication, and the ones with the most widespread use are patented in the U.S. 😬 This certification management scheme works with different digital signature algorithms, but the RSA cryptosystem is expected to be the primary signature algorithm for building the Internet certification hierarchy 🔑 Special license arrangements have been made so this algorithm can be used in the U.S. portion of the Internet 🇺🇸

The infrastructure in this doc sets up a single root for all certification on the Internet, the Internet Policy Registration Authority (IPRA) 👑 The IPRA sets the global policies in this doc, which apply to all certification done under this hierarchy 🌳 Beneath the IPRA root are Policy Certification Authorities (PCAs). Each PCA sets up and publishes its registration policies for users or organizations in the form of an informational RFC 📜 Each PCA is certified by the IPRA. It's desirable to have a relatively small number of PCAs, each with a substantively different policy, so users can get familiar with the set of PCA policies 🧠 Still, there's no explicit requirement that the number of PCAs be limited this way 🤷‍♀️ Below the PCAs are Certification Authorities (CAs), which certify users and subordinate organizational entities like departments, offices, subsidiaries, and so on 🏢

At first, most users will be registered through their organization, which is how most user mailboxes are already set up 📬 Honestly it's giving university or company ID card energy 🪪

Some CAs are expected to certify residential users, for people who want to register without any organizational affiliation 🏡 Over time, civil government entities that already run similar identification services in other contexts, like driver's licenses, may offer this service too 🚗 And for users who want anonymity while still using PEM privacy features, one or more PCAs will be set up with policies that allow users to register under subordinate CAs without disclosing their identities 🎭

2. Overview of Approach 🦋

This document defines a key management architecture built on public-key certificates, mainly to support the message encipherment and authentication procedures in RFC 1421 🔐 The concept of public-key certificates comes from X.509, and this architecture is a compliant subset of what X.509 envisions 🧩

Quick version: a (public-key) certificate is a data structure with the name of a user (the "subject"), plus that user's public component 🗝️ (This doc uses "private component" and "public component" for the quantities in asymmetric cryptosystems that are, respectively, kept secret and made publicly available. The reason is to avoid mixing things up with "secret key," which can mean either of those or a key in a symmetric cryptosystem 🤓) The certificate also has the name of an entity (the "issuer") that vouches for the binding between the public component and the named user 🤝 That data, along with a time interval during which the binding is claimed to be valid, is cryptographically signed by the issuer using the issuer's private component ✍️ The subject and issuer names in certificates are Distinguished Names (DNs) as defined in the directory system (X.500) 🏷️

Once signed, certificates can be stored in directory servers, sent over non-secure message exchanges, or passed around by any other means that make them easy for message system users to access 📨 The security of the transmission medium doesn't matter here, because the signature is what does the heavy lifting 💪 In PEM, certificates give the originator of a message the (authenticated) public component of each recipient, and give each recipient the (authenticated) public component of the originator 🔁 Here's the flow for originators and recipients 👇

Before sending an encrypted message with PEM, an originator must get a certificate for each recipient and must validate those certificates 📥 Validation basically means checking the digital signature in the certificate, using the public component of the issuer whose private component signed it ✅ The issuer's public component is either available out of band (for the IPRA), or it's distributed in a certificate that gets the same validation procedure applied to it, recursively 🔄 In that second case, the issuer of a user's certificate becomes the subject of a certificate issued by another certifying authority (or a PCA), which creates a certification hierarchy 🌲 Along the way, the validity interval for each certificate is checked, and Certificate Revocation Lists (CRLs) are checked to make sure none of the certificates used in validation has been revoked by its issuer 🚫

Once a recipient's certificate is validated, the public component inside it is pulled out and used to encrypt the data encryption key (DEK) 🔑 That DEK then encrypts the message itself 🔒 The encrypted DEK goes into the Key-Info field of the message header 📋 When an encrypted message comes in, the recipient uses their private component to decrypt this field, pulls out the DEK, and uses the DEK to decrypt the message 🎉

For message integrity and data origin authentication, the originator generates a message integrity code (MIC), signs (encrypts) the MIC using the private component of their own public-key pair, and puts the result in the MIC-Info field of the message header 🧾 The originator's certificate can optionally be included in the header in the Certificate field, as described in RFC 1421 📎 That's there to make validation easier when ubiquitous directory services aren't available 🙏 When a recipient gets a privacy-enhanced message, they validate the originator's certificate (using the IPRA public component as the root of a certification path) and check that it hasn't been revoked 🕵️‍♀️ Then they pull the public component out of the certificate, use it to recover (decrypt) the MIC, and compare the recovered MIC against the MIC they calculated locally 🧮 If they match, the integrity and data origin authenticity of the message are verified 💖

3. Architecture 👑

3.1. Scope and Restrictions 🌸

The architecture is basically a plan for managing public-key stuff so privacy enhanced email can actually work on the Internet 🔐💖. It covers how you register certification authorities and users, how certificates get generated and handed out, and how CRLs get generated and distributed too 📜. RFC 1421 explains the header fields used to move certificates around and to carry the DEK and MIC in this public-key setup 📮. The algorithms, modes of use and their identifiers live in RFC 1423, so adding new algorithms later is way easier 🦋. This doc focuses on the management side of certificate-based public-key crypto for privacy enhanced mail, bestie 🎀.

The architecture adds some conventions to the certification hierarchy that X.509 doesn't strictly require, and the technology itself doesn't need them either ✨. They're mainly there because the architecture needs authentication semantics that work with automated validation, plus a way to automatically work out which policy a certificate was issued under 🤖.

Here's the main idea. User (or mailing list) certificates are the leaves of the certification hierarchy 🍃. That hierarchy is largely isomorphic to the X.500 directory naming hierarchy, with two exceptions 👑. First, the IPRA forms the root of the tree, since the root of the X.500 DIT isn't instantiated as a node. Second, a number of Policy Certification Authorities (PCAs) form the "roots" of subtrees, and each one represents a different certification policy 🌳.

Not every level in the directory hierarchy has to be a certification authority 🗺️. For example, geographic entities in a distinguished name (countries, states, provinces, localities) don't mean various governments have to become certifying authorities to use this architecture 🌍. Still, it's expected that over time a bunch of those points will get instantiated as CAs, which will make it easier to hand management over to the right governmental authorities later on 🏛️.

These conventions keep validating user certificates simple, e.g., by making the link between a certificate issuer and the user explicit through the naming hierarchy 💅. Note that in this architecture, only PCAs may be certified by the IPRA. Every CA's certification path can be traced to a PCA, through zero or more CAs. If a CA is certified by more than one PCA, each certificate issued by a PCA for that CA must contain a distinct public component 🧩. All of this adds up to a certification hierarchy that's a compatible subset of what X.509 allows, both in syntax and in semantics 🫶.

Even though this key management architecture was designed mainly for privacy enhanced mail, the infrastructure may, in principle, also support X.400 mail security facilities (as per 1988 X.411) and X.500 directory authentication facilities 📬. So setting up this infrastructure paves the way for using these and other OSI protocols on the Internet down the road 🚀. In the future, these certificates may also be used to provide security services in other protocols in the TCP/IP and OSI suites 🌈.

3.2. Relation to X.509 Architecture

Okay so CCITT 1988 Recommendation X.509, "The Directory - Authentication Framework", is the framework for authenticating entities involved in a distributed directory service 🔑. Strong authentication, as X.509 defines it, is done with public-key cryptosystems 💜. Unforgeable certificates get generated by certification authorities, and these authorities may be organized hierarchically, though X.509 doesn't require that organization 🌸. There's no implied mapping between a certification hierarchy and the naming hierarchy set up by directory system naming attributes, so don't go assuming they line up 🙈.

This document takes the X.509 certificate mechanism and adapts it to serve PEM's needs in the Internet environment 🎀. The certification hierarchy proposed here for privacy enhanced mail is intentionally a subset of what X.509 allows ✨. It also has semantics that X.509 doesn't explicitly address, but they're consistent with X.509 precepts, so no clash there 💅. You can find an overview of the reasoning behind those semantics in Section 1 🧚.

3.3. Certificate Definition

Certificates are the central piece of the key management architecture for X.509 and PEM, so they're kind of a big deal 👑. This section gives you an overview of the syntax and a description of what the certificate semantics mean. Appendix A has the ASN.1 syntax for certificates 📜. A certificate includes the following contents:

  1. version
  2. serial number
  3. signature (algorithm ID and parameters)
  4. issuer name
  5. validity period
  6. subject name
  7. subject public key (and associated algorithm ID)

3.3.1. Version Number

The version number field is there so certificate formats can change in an orderly way over time 🔄. The initial version number for certificates used in PEM is the X.509 default, which is zero (0), meaning the 1988 version 💖. PEM implementations are encouraged to accept later versions as CCITT/ISO endorses them 🫶.

3.3.2. Serial Number

The serial number field is a short-form, unique identifier for each certificate an issuer generates ✨. An issuer must ensure that no two distinct certificates with the same issuer DN contain the same serial number 🚨. This requirement must still be met when the certification function is done on a distributed basis, and/or when the same issuer DN is certified under two different PCAs 🌐. This is especially critical for residential CAs certified under different PCAs 🏠. The serial number is used in CRLs to identify revoked certificates, as described in Section 3.4.3.4 📋. This attribute is an integer, but PEM UA processing of it doesn't need to involve any arithmetic operations 🧮. All PEM UA implementations must be capable of processing serial numbers at least 128 bits in length, and size-independent support for serial numbers is encouraged 💅.

3.3.3. Signature

This field specifies the algorithm the issuer used to sign the certificate, plus any parameters that go with it 🖋️. (The certificate signature is appended to the data structure, as the signature macro in X.509 defines. This algorithm identification information gets replicated with the signature.) The UA processing a certificate validates the signature to make sure the contents weren't modified after a CA (IPRA, or PCA) signed it 🔍. Here, a signature is made using a Certificate Integrity Check (CIC) algorithm and a public-key encryption algorithm 🔐. RFC 1423 has the definitions and algorithm IDs for the signature algorithms used in this architecture 📖.

3.3.4. Subject Name

A certificate represents its subject's identity as a Distinguished Name (DN) 🪪. The fundamental binding that the key management architecture guarantees is the one between the public component and the user's identity in this form 💜. A distinguished name is an X.500 directory system concept. If a user is already registered in an X.500 directory, their distinguished name is defined through that registration 📇. Users who aren't registered in a directory should keep the likely directory naming structure (schema) in mind when picking a distinguished name for their certificate 🧠.

3.3.5. Issuer Name

A certificate also represents its issuer's identity, in the form of a Distinguished Name 🏷️. The issuer identification is used to select the right issuer public component to use when validating the certificate 🎯. If an issuer (CA) is certified by multiple PCAs, the issuer DN doesn't uniquely identify the public component used to sign the certificate. In that situation, it may be necessary to try validation with multiple public components, taken from certificates the issuer holds under different PCAs 🤹. If the 1992 version of a certificate is used, the issuer may use distinct issuer UIDs in the certificates it issues, which helps pick out the right issuer public component even more 💅. The issuer is the certifying authority (IPRA, PCA or CA) who vouches for the binding between the subject identity and the public key in the certificate 🫶.

3.3.6. Validity Period

A certificate carries a pair of date and time indications, marking the start and end of the period it's meant to be used in ⏳. The length of that interval may be constant for all user certificates a given CA issues, or it might vary depending on the nature of the user's affiliation 🎟️. For example, an organization might issue certificates with shorter intervals to temporary employees than to permanent employees 💼. It's recommended that the UTCT (Coordinated Universal Time) values recorded here specify granularity to no more than the minute, even though finer granularity can be expressed in the format 🕰️. Implementors, be warned: no DER is defined for UTCT in X.509, so converting between local and transfer syntax has to be done carefully, e.g., when computing the hash value for a certificate 😬. For instance, a UTCT value that includes explicit zero values for seconds would not produce the same hash value as one where the seconds were omitted 🙈. It's also recommended that all times be expressed as Greenwich Mean Time (Zulu), which keeps comparisons simple and avoids daylight savings confusion 🌞. Note that UTCT expresses the year modulo 100 (with no indication of century), so comparisons involving dates in different centuries must be done with care 🧐.

The longer the interval, the greater the likelihood that compromise of a private component or a name change will make the certificate invalid and require it to be revoked 🚫. Once revoked, the certificate must remain on the issuer's CRL (see Section 3.4.3.4) until the validity interval expires 📜. PCAs may impose restrictions on the maximum validity interval that CAs operating in their certification domain may choose (see Appendix B) 🛡️.

3.3.7. Subject Public Key

A certificate carries the public component of its associated subject, along with an indication of the algorithm and any algorithm parameters the public component is to be used with 🔑. This algorithm identifier is independent of the one specified in the signature field described above ✨. RFC 1423 specifies the algorithm identifiers that may be used in this context 📖.

3.4. Roles and Responsibilities

One way to get the hang of this architecture is to look at the roles it defines for each kind of entity, and what each one has to do for the whole system to work 💅 this part covers four types: users and user agents, the Internet Policy Registration Authority, Policy Certification Authorities, and other Certification Authorities ✨ for each type, the doc spells out the procedures the entity must execute as part of the architecture, plus the responsibilities it takes on based on the role it plays 👑

3.4.1 Users and User Agents 🎀

okay so the term User Agent (UA) is borrowed from CCITT X.400 Message Handling Systems (MHS) Recommendations, which define it like this: "In the context of message handling, the functional object, a component of MHS, by means of which a single direct user engages in message handling." 🙈 on the Internet, programs like rand mh and Gnu emacs rmail count as UAs 💌 UAs exchange messages by calling on a supporting Message Transfer Service (MTS), e.g., the SMTP mail relays used in the Internet 📬

3.4.1.1 Generating and Protecting Component Pairs 🔐

bestie, a UA process that supports PEM must protect the private component of its associated entity (like a human user or a mailing list) from disclosure, though how it does that is a local matter 🫶 honestly, it's essential that the user takes every available precaution to protect their private component, because keeping that value secret is central to the security PEM gives them 🔒

for example, the private component might be stored in encrypted form, protected with a locally managed symmetric encryption key (e.g., using DES) 🗝️ the user would supply a password or passphrase, which would be used as a symmetric key to decrypt the private component whenever it's needed for PEM processing (either on a per message or per session basis) 🔑

or the private component might live on a diskette that the user pops in whenever they originate or receive PEM messages 💾 explicitly zeroing the memory locations where this component briefly sits could give extra protection 🧹 other precautions, based on local operating system security facilities, also should be employed ✨

it's recommended that each user use ancillary software (not otherwise tied to normal UA operation) or hardware to generate their personal public-key component pair 🧚 software for generating user component pairs will be available as part of the reference implementation of PEM, distributed freely in the U.S. portion of the Internet 🌈 it's critically important that the component pair generation procedure be done as securely as possible, so the resulting private component is unpredictable 😭 adding adequate randomness is potentially the hardest part of the whole process, so the user is advised to pay particular attention to it 👀 (component pairs used in public-key cryptosystems tend to be large integers that have to be "randomly" selected, subject to mathematical constraints imposed by the cryptosystem. the input(s) used to seed the component pair generation process must be as unpredictable as possible. an example of a poor random number selection technique is one where a pseudo-random number generator is seeded solely with the current date and time 💀 an attacker who could figure out roughly when a component pair was generated could easily regenerate candidate component pairs, and compare the public component to the user's public component to spot when the matching private component had been found 🕵️)

there's no requirement imposed by this architecture that anyone other than the user, including any certification authority, have access to the user's private component 🙅‍♀️ so a user can keep their component pair even if their certificate changes, e.g., because of rollover in the validity interval or a change of certifying authority 🔄 even if a user gets a certificate through their job, there's generally no requirement that the employer have access to the private component. the rationale is that any messages signed by the user are verifiable using their public component ✅ if the corresponding private component becomes unavailable, any ENCRYPTED messages directed to the user would be indecipherable and would require retransmission 💔

note that if the user stores messages in ENCRYPTED form, those messages also become indecipherable if the private component is lost or changed 😵 to cut down on data loss in those situations, messages can be transformed into MIC-ONLY or MIC-CLEAR form, if cryptographically-enforced confidentiality isn't required for messages stored on the user's computer 💾 alternatively, these transformed messages might be forwarded in ENCRYPTED form to a (trivial) distribution list that serves as a backup, and for which the user's employer holds the private component 🫣

a user may have multiple certificates that embody the same or different public components 📇 for example, those certificates might represent a current and a former organizational user identity, plus a residential user identity 🏠 it's recommended that a PEM UA be capable of supporting a user who has multiple certificates, whether or not those certificates contain the same or different DNs or public components 🎀

3.4.1.2 User Registration 📝

most details of user registration are a local matter, subject to policies set by the user's CA and by the PCA that certified that CA 🏛️ generally, a user must give a CA (or a representative of one) at a minimum their public component and distinguished name, for inclusion in the user's certificate 🪪 (the user also might provide a complete certificate, minus the signature, as described in RFC 1424.) the CA uses some means, specified by the CA in line with its PCA's policy, to validate the user's claimed identity and to make sure the public component provided is tied to the user whose distinguished name is going into the certificate 🕵️ (for PERSONA certificates, described below, the procedure is a bit different 🧐) the certifying authority then generates a certificate containing the user's distinguished name and public component, the authority's distinguished name and other information (see Section 3.3), and signs the result using the authority's private component ✍️

3.4.1.3 CRL Management 🗂️

mechanisms for managing a UA certificate cache are, in typical standards parlance, a local matter 🤷 still, proper maintenance of that cache is critical to the correct, secure operation of a PEM UA, and it provides a basis for improved performance 🚀 plus, using a cache lets a PEM UA operate without directories (and in circumstances where directories are inaccessible) 📚 the discussion below gives a paradigm for one aspect of cache management, namely the processing of CRLs. the functional equivalent of that processing must be embodied in any PEM UA implementation compliant with this document 🧩 the specifications for CRLs used with PEM are provided in Section 3.5 📖

X.500 makes provision for storing CRLs as directory attributes associated with CA entries 🗃️ so, when X.500 directories become widely available, UAs can retrieve CRLs from directories as required. in the interim, the IPRA will coordinate with PCAs to provide a robust database facility containing CRLs issued by the IPRA, by PCAs, and by all CAs 💅 access to this database is provided through mailboxes maintained by each PCA 📬 every PEM UA must provide a facility for requesting CRLs from this database using the mechanisms defined in RFC 1424. so the UA must include a configuration parameter that specifies one or more mailbox addresses from which CRLs may be retrieved 🔧 access to the CRL database may be automated, e.g., as part of the certificate validation process (see Section 3.6), or it may be user directed 🤖 responses to CRL requests will employ the PEM header format specified in RFC 1421 for CRL propagation. as noted in RFC 1421, every PEM UA must be capable of processing CRLs distributed via such messages. this message format also may be employed to support a "push" (versus a "pull") model of CRL distribution, i.e., to support unsolicited distribution of CRLs 📣

CRLs received by a PEM UA must be validated (a CRL is validated in much the same manner as a certificate, i.e., the CIC (see RFC 1113) is calculated and compared against the decrypted signature value obtained from the CRL. see Section 3.6 for additional details related to validation of certificates) prior to being processed against any cached certificate information 🔍 any cache entries which match CRL entries should be marked as revoked, but it isn't necessary to delete cache entries marked as revoked, nor to delete subordinate entries 🗑️ when processing a CRL against the cache, it's important to remember that certificate serial numbers are unique only for each issuer, and that multiple, distinct CRLs may be issued under the same CA DN (signed using different private components), so care must be exercised in effecting this cache search ⚠️ (this situation may arise either because an organizational CA is certified by multiple PCAs, or because multiple residential CAs are certified under different PCAs 🌸)

this procedure applies to cache entries associated with PCAs and CAs, as well as user entries 🎯 the UA also must retain each CRL to screen incoming messages for use of revoked certificates carried in PEM message headers 🛡️ so a UA must be capable of processing and retaining CRLs issued by the IPRA (which will list revoked PCA certificates), by any PCA (which will list revoked CA certificates issued by that PCA), and by any CA (which will list revoked user or subordinate CA certificates issued by that CA) 💖

3.4.1.4 Facilitating Interoperation 🤝

in the absence of ubiquitous directory services, or of knowledge (acquired through out-of-band means) that a recipient already possesses the necessary issuer certificates, it's recommended that an originating (PEM) UA include enough certificates to permit validation of the user's public key 🔑 to that end, every PEM UA must be capable of including a full (originator) certification path in a PEM message. that means the user's certificate (using the Originator-Certificate field) and every superior (CA/PCA) certificate (using Issuer-Certificate fields) all the way back to the IPRA 🧵 a PEM UA may send less than a full certification path, e.g., based on analysis of a recipient list, but a UA which provides this sort of optimization must also provide the user with a capability to force transmission of a full certification path ✨

Okay so the UA can optimize the transmitted originator certification path as a side effect of what it already does during message submission 💅✨. When an originator submits an ENCRYPTED message (per RFC 1421), his UA must validate the recipients' certificates (see Section 3.6) 🎀. While doing that validation, the UA can work out the minimum set of certificates that must be included so every recipient can process the message 🧚. Submitting a MIC-ONLY or MIC-CLEAR message (per RFC 1421) doesn't involve validating recipient certificates, so the originator's UA may not be able to figure out that minimum set 💀.

3.4.2 The Internet Policy Registration Authority (IPRA) 👑

The IPRA is the root of the certification hierarchy for the Internet community 🌳. Its public component is the foundation for all certificate validation in this hierarchy 🌈. The IPRA will be operated under the auspices of the Internet Society, an international, non-profit organization 🫶. It certifies all PCAs, making sure they agree to abide by the Internet-wide policy the IPRA set up. That policy, and the services the IPRA provides, are detailed below 🍓.

3.4.2.1 PCA Registration 🎀

The IPRA only certifies PCAs, not CAs or users 🙈. Each PCA has to file a description of its proposed policy with the IPRA, and that document will be published as an informational RFC. A copy, signed by the IPRA (in the form of a PEM MIC-ONLY message), will be available through electronic mail access from the IPRA 📬. This convention exists so every Internet user has a reference point for figuring out the policies behind any certificate they run into 🦋. A digitally signed copy ensures the document is immutable. A PCA is authorized to operate in the Internet hierarchy when the policy document is published and the IPRA issues it a certificate, signed by the IPRA ✨. An outline for PCA policy statements is in Section 3.4.3 of this document 📝.

As part of registration, each PCA will be required to execute a legal agreement with the IPRA, and to pay a fee to cover the costs of running the IPRA 💸. Each PCA must specify its distinguished name. The IPRA will take reasonable precautions to make sure the DN a PCA claims is legitimate, for example by requiring the PCA to provide documentation supporting its claim to a DN 🔍. But certifying a PCA doesn't count as an endorsement of the PCA's claim to that DN outside of this certification system 🙅‍♀️.

3.4.2.2 Ensuring the Uniqueness of Distinguished Names 🔐

Here's the big rule: certificates are never issued to distinct entities under the same distinguished name 😭. This matters a lot for distributed management of the hierarchy. The IPRA won't certify two PCAs with the same DN, and no PCA may certify two CAs with the same DN. But PCAs are expected to certify organizational CAs in widely disjoint parts of the directory namespace, and X.500 directories aren't everywhere. So there needs to be a way for PCAs to coordinate and keep CA DNs unique 🧚.

(Residential CAs are a special case. This architecture lets multiple PCAs certify residential CAs, so multiple distinct residential CAs with identical DNs may come into existence, at least until civil authorities take over that responsibility. So on an interim basis, the architecture explicitly makes room for duplicate residential CA DNs 🙈.)

To support the uniqueness requirement, the IPRA will establish and maintain a database that detects potential, unintended duplicate certification of CA distinguished names. All PCAs will be able to access this database through an email interface 💌. Each entry in the database is a 4-tuple:

  1. The first element is a hash value, computed on a canonical, ASN.1 encoded representation of a CA distinguished name.
  2. The second element is the subjectPublicKey that appears in the CA's certificate.
  3. The third element is the distinguished name of the PCA which registered the entry.
  4. The fourth element is the date and time the entry was made, as established by the IPRA ⏰.

This database structure gives a degree of privacy to CAs registered by PCAs, while still providing a way to ensure global uniqueness of CA DNs certified in this scheme 🌸.

To avoid conflicts, a PCA should query the database using a CA DN hash value as the search key before certifying a CA. The database returns any entries that match the query, meaning entries with the same CA DN. The PCA can use whatever comes back to decide if it should contact any PCAs to resolve possible DN conflicts. If no potential conflicts appear, a PCA can submit a candidate entry, made of the first three element values plus any entries the query returned 💅. The database registers this entry, adding the time and date stamp, only if two conditions are met: (1) the first two elements (the CA DN hash and the CA subjectPublicKey) of the candidate entry together must be unique, and (2) any other entries included in the submission must match what the current database would return if the query for the candidate entry were submitted 🎀.

If the database detects a conflicting entry (failure of case 1 above), or if the submission shows that the PCA's perception of possible conflicting entries isn't current (failure of case 2), the submission is rejected and the database returns the potential conflicting entry or entries 🚫. If the submission succeeds, the database returns the timestamped new entry ✅. The database does not, by itself, guarantee uniqueness of CA DNs, since it allows two DNs tied to different public components to be registered. Instead, it's up to the PCAs to coordinate with one another whenever the database indicates a potential DN conflict, and to resolve those conflicts before certifying CAs 🤝. Details of the protocol used to access the database will be provided in another document 📚.

As noted earlier, a CA may be certified under more than one PCA, e.g., because the CA wants to issue certificates under two different policies. If a CA is certified by multiple different PCAs, the CA must use a different public key pair for each PCA. In that case, the certificate each PCA issues to the CA will contain a different subjectPublicKey, so each one becomes a different entry in this database 👯. The same situation may come up if multiple, equivalent residential CAs are certified by different PCAs.

To finish the strategy for ensuring DN uniqueness, there's a DN subordination requirement on CAs 🌷. In general, CAs are expected to sign certificates only if the subject DN in the certificate is subordinate to the issuer (CA) DN. This makes sure certificates issued by a CA are syntactically constrained to refer to subordinate entities in the X.500 directory information tree (DIT), which further limits the possibility of duplicate DN registration 🌿. CAs may sign certificates that don't follow this requirement if the certificates are "cross-certificates" or "reverse certificates" (see X.509) used with applications other than PEM 🔁.

The IPRA will also establish and maintain a separate database to detect potential duplicate certification of (residential) user distinguished names 🏠. Each entry in this database is a 4-tuple like the one above, but the first element is the hash of a residential user DN, and the third element is the DN of the residential CA which registered the user. This structure gives a degree of privacy to users registered by CAs that service residential users, while still providing a way to ensure global uniqueness of user DNs certified under this scheme 💜. The same database access facilities described above for the CA database are provided here too. Whenever this database indicates a potential conflict, it's the CAs' job to coordinate and resolve the conflict before (residential) user certification 🫶.

3.4.2.3 Accuracy of Distinguished Names 🔍

As noted above, the IPRA will make a reasonable effort to ensure that PCA DNs are accurate 🎯. The procedures used to ensure the accuracy of a CA distinguished name (the confidence attached to the DN/public component binding a certificate implies) will vary according to PCA policy 🧐. Still, every PCA is expected to make a good faith effort to ensure the legitimacy of each CA DN it certifies 💖. Part of that effort should include checking that the purported CA DN is consistent with any applicable national standards for DN assignment, e.g., NADF recommendations within North America [5,9] 🌎.

3.4.2.4 Distinguished Name Conventions 📋

A few basic DN conventions are included in the IPRA policy. The IPRA certifies PCAs, but not CAs or users. PCAs certify CAs, but not users. These conventions are required to allow simple certificate validation within PEM, as described later 🧩. Certificates issued by CAs (for use with PEM) will be for users or for other CAs, and either one must have a DN subordinate to that of the issuing CA 🌸.

The attributes used to build DNs will be specified in a list maintained by the IANA, giving a coordinated basis for attribute identification across all applications that use DNs 🗂️. That list will initially be populated with attributes taken from X.520. This document doesn't impose detailed restrictions on the attributes used to identify the different entities certificates are issued to, but PCAs may impose those restrictions as part of their policies 🙋‍♀️. PCAs, CAs and users are urged to use only DN attributes that have printable representations, to make display and entry easier 🖨️.

3.4.2.5 CRL Management 📜

Among the procedures each PCA spells out in its policy statement are procedures for maintaining and distributing CRLs, both by the PCA itself and by its subordinate CAs 🔔. How often CRLs are issued may vary according to PCA-specific policy, but every PCA and CA must issue a CRL upon inception, so there's a basis for uniform certificate validation procedures throughout the Internet hierarchy 🌐. The IPRA will maintain a CRL for all the PCAs it certifies, and this CRL will be updated monthly 🗓️. Each PCA will maintain a CRL for all of the CAs it certifies, and these CRLs will be updated in accordance with each PCA's policy 💅. The format for these CRLs is the one specified in Section 3.5.2 of the document 💜.

Okay bestie, since we don't have ubiquitous X.500 directory services 😭, the IPRA is making every PCA give its users solid database access to CRLs across the whole Internet hierarchy 🌐. That means the IPRA CRL, the PCA CRLs, and CRLs from all CAs, all in one place. How the database actually gets built is something the IPRA and the PCAs have to coordinate together 🤝. People can reach it by email as laid out in RFC 1424, both to grab the (current) CRLs (any user can do that!) and to submit new CRLs from CAs, PCAs, and the IPRA 💌. Individual PCAs also MAY elect to keep CRL archives for their CAs 🗂️, but this is not REQUIRED by this policy, so no pressure bestie 🫶.

3.4.2.6. Public Key Algorithm Licensing Issues 🔑

This whole certification hierarchy is architecturally independent of any specific digital signature (public key) algorithm, so it isn't married to one algorithm 💍. But here's the tea: some algorithms, the ones used for signing certificates and checking certificate signatures, are patented in some countries 🙈. The IPRA will not grant any PCA a license to use any signature algorithm for managing this hierarchy 🚫. Instead, the IPRA will acquire licenses for itself, for every algorithm it supports, so it can sign certificates and CRLs for PCAs 📜. Every PCA will be REQUIRED to represent to the IPRA that it has obtained any licenses REQUIRED to issue (sign) certificates and CRLs in the environment(s) it will serve 🧾.

For example 🇺🇸, the RSA cryptosystem is patented in the United States, so any PCA operating in the U.S. that uses RSA to sign certificates and CRLs MUST represent that it has a valid license to employ RSA that way. In contrast, a PCA employing RSA and operating outside of the U.S. would represent that it is exempt from these licensing constraints 🌍.

3.4.3. Policy Certification Authorities 📝

The policy statement a prospective PCA submits MUST address the topics in the outline below. Additional policy information MAY be contained in the statement, but PCAs are requested not to use these statements as advertising vehicles 📣🚫.

  1. PCA Identity - The DN of the PCA MUST be specified. A postal address, an Internet mail address, and telephone (and OPTIONAL fax) numbers MUST be provided for (human) contact with the PCA. The date on which this statement takes effect, and its scheduled duration, MUST be specified 📅.
  2. PCA Scope - Each PCA MUST describe the community it plans to serve. A PCA SHOULD indicate whether it will certify organizational, residential, and/or PERSONA CAs. There is not a requirement that a single PCA serve only one type of CA, but if a PCA serves multiple types of CAs, the policy statement MUST specify clearly how a user can tell these classes apart. If the PCA will operate CAs to directly serve residential or PERSONA users, it MUST say so 🎯.
  3. PCA Security & Privacy - Each PCA MUST specify the technical and procedural security measures it will use to generate and protect its component pair 🛡️. If any security requirements are imposed on CAs certified by the PCA, these MUST be specified as well. A PCA also MUST specify what measures it will take to protect the privacy of any information collected while certifying CAs 🤫. If the PCA operates one or more CAs directly to serve residential or PERSONA users, this privacy statement applies to those CAs as well.
  4. Certification Policy - Each PCA MUST specify the policy and procedures that govern its certification of CAs, and how this policy applies transitively to entities (users or subordinate CAs) certified by those CAs 🔗. For example, a PCA MUST state what procedure it uses to verify a CA's claimed identity and the CA's right to use a DN. Similarly, if any requirements are imposed on CAs to validate user identities, these requirements MUST be specified. Since all PCAs are REQUIRED to cooperate in resolving potential DN conflicts, each PCA is REQUIRED to specify the procedure it will use to resolve such conflicts 🤝. If the PCA imposes a maximum validity interval on the CA certificates it issues, and/or on user (or subordinate CA) certificates issued by the CAs it certifies, then these restrictions MUST be specified ⏳.
  5. CRL Management - Each PCA MUST specify how often it will issue scheduled CRLs 🗓️. It also MUST specify any constraints it places on how often the CAs it certifies, and subordinate CAs, issue scheduled CRLs. Both maximum and minimum constraints SHOULD be specified. Since the IPRA policy calls for each CRL issued by a CA to be forwarded to the cognizant PCA, each PCA MUST specify a mailbox address to which CRLs are to be sent 📬. The PCA also MUST specify a mailbox address for CRL queries. If the PCA offers any additional CRL management services, such as archiving old CRLs, then the procedures for invoking those services MUST be specified. If the PCA requires CAs to provide any additional CRL management services, those services MUST be specified here.
  6. Naming Conventions - If the PCA imposes any conventions on DNs used by the CAs it certifies, or by entities certified by those CAs, these conventions MUST be specified. If any semantics are associated with such conventions, those semantics MUST be specified too 🏷️.
  7. Business Issues - If a legal agreement MUST be executed between a PCA and the CAs it certifies, a reference to that agreement MUST be noted, but the agreement itself ought not be part of the policy statement 📑. Similarly, if the PCA charges any fees, this SHOULD be noted, but the fee structure per se ought not be part of this policy statement 💸.
  8. Other - Any other topics the PCA deems relevant to a statement of its policy can be included. However, the PCA SHOULD be aware that a policy statement is considered to be an immutable, long-lived document, and thus considerable care SHOULD be exercised in deciding what material goes into the statement 💅.

Translation: policy statements are basically forever, so think before you type 🧠✨

3.4.4. Certification Authorities 🏛️

In X.509, the term "certification authority" is defined as "an authority trusted by one or more users to create and assign certificates". X.509 puts few constraints on CAs, but a practical worldwide certification system needs technical and procedural conventions that every CA is expected to follow ✨. Those conventions are set out throughout this document 📖. All CAs are REQUIRED to maintain a database of the DNs they have certified, and to take measures making sure they never certify duplicate DNs, whether for users or for subordinate CAs 🗃️.

It's critical that a CA's private component gets a high level of security 🔐, because otherwise the authenticity guarantee implied by certificates signed by that CA is voided 💀. Some PCAs MAY impose strict requirements on the CAs within their purview to make sure the certificate signing process gets a high level of security, but not all PCAs are expected to impose such constraints 🧐.

3.4.4.1. Organizational CAs 🏢

Many of the CAs certified by PCAs are expected to represent organizations 🏢. The model covers a wide range of them: commercial, governmental, educational, non-profit, professional societies, etc. The common thread is that the entities certified by these CAs have some form of affiliation with the organization 🤝. The object classes for organizations, organizational units, organizational persons, organizational roles, etc., as defined in X.521, form the models for entities certified by such CAs. The affiliation implied by organizational certification is what motivates the DN subordination requirement cited in Section 3.4.2.4.

As an example, an organizational user certificate might contain a subject DN of the form:

C = "US" SP = "Massachusetts" L = "Cambridge" O = "Bolt Beranek and Newman" OU = "Communications Division" CN = "Steve Kent"

The issuer of this certificate might have a DN of the form:

C = "US" SP = "Massachusetts" L = "Cambridge" O= "Bolt Beranek and Newman"

Note that the organizational unit attribute is omitted from the issuer DN, implying that there is no CA dedicated to the "Communications Division" 🤔.

3.4.4.2. Residential CAs 🏠

Users may want certificates that don't imply any organizational affiliation but do purport to accurately and uniquely identify them 🪪. Such users can be registered as residential persons, and the DN of such a user SHOULD be consistent with the attributes of the corresponding X.521 object class. Over time, we anticipate that civil government entities will accommodate such users, taking on electronic certification responsibility at geographically designated points in the naming hierarchy 🏛️. Until civil authorities are prepared to issue certificates of this form, residential user CAs will accommodate such users 🫂.

Because residential CAs may be operated under the auspices of multiple PCAs, there's a potential for the same residential CA DN to be assumed by several distinct entities 😬. This is the one exception to the rule throughout this document that no two entities may have the same DN. The conflict is tolerated so residential CAs can be set up offering different policies 🎀. Two requirements are levied on residential CAs as a result: (1) residential CAs MUST employ the residential DN conflict detection database maintained by the IPRA, and (2) residential CAs MUST coordinate to make sure they do not assign duplicate certificate serial numbers 🔢.

As an example, a residential user certificate might include a subject name of the form:

C = "US" SP = "Massachusetts" L = "Boston" PA = "19 North Square" CN = "Paul Revere."

The issuer of that certificate might have a DN of the form:

C = "US"  SP = "Massachusetts" L = "Boston"

Note that the issuer DN is superior to the subject DN, as REQUIRED by the IPRA policy described earlier 👑.

3.4.4.3. PERSONA CAs 🎭

One or more CAs will be set up to accommodate users who want to hide their identities while using PEM security features 🕵️, e.g., to keep the anonymity offered by "arbitrary" mailbox names in the current mail environment. In this case, the certifying authority is explicitly NOT vouching for the identity of the user 🙅. All such certificates are issued under a PERSONA CA, subordinate to a PCA with a PERSONA policy, so users are explicitly warned that the subject DN is NOT a validated user identity ⚠️. To minimize the chance of syntactic confusion with certificates that do purport to specify an authenticated user identity, a PERSONA certificate is issued as a form of organizational user certificate, not a residential user certificate 🎭. There are no explicit, reserved words used to identify PERSONA user certificates.

A CA issuing PERSONA certificates MUST institute procedures to ensure it does not issue the same subject DN to multiple users (a constraint REQUIRED for all certificates of any type issued by any CA) 🔁. There are no requirements on an issuer of PERSONA certificates to keep any other records that might tie the subject's true identity to their certificate 🤐. However, a CA issuing such certificates MUST establish procedures (not specified in this document) that let the holder of a PERSONA certificate ask for their certificate to be revoked (i.e., listed on a CRL) 💔.

Okay bestie, so a PERSONA user cert can have a subject DN that looks like this 🎭✨

C = "US" SP = "Massachusetts" L = "Boston" O = "Pseudonyms R US" CN = "Paul Revere."

And the issuer of that cert might have a DN like this 🧚

C = "US"  SP = "Massachusetts" L = "Boston" O = "Pseudonyms R US"

Look at the differences between this PERSONA "Paul Revere" cert and the regular residential cert for the same common name. It's giving alter ego energy 💅🦋

3.4.4.4 CA Responsibilities for CRL Management 🌸

Once X.500 directory servers are actually around, CRLs SHOULD be maintained and accessed through them 🏛️ But until X.500 directories are widely deployed, this document adds some extra rules for CRL management by CAs and PCAs. Per X.509, each CA is REQUIRED to maintain a CRL (in the format specified by this document in Appendix A) that contains entries for all certificates it issued and later revoked. Once a certificate gets put on a CRL, it stays there until its validity interval expires 🔒 Each PCA is REQUIRED to maintain a CRL for revoked CA certificates within its domain.

The interval at which a CA issues a CRL is not fixed by this document, but the PCAs MAY establish minimum and maximum intervals for that issuance ⏰

As noted earlier, each PCA will provide access to a database containing CRLs issued by the IPRA, PCAs, and all CAs 📚 To make that work, each CA MUST supply its current CRL to its PCA, following the CRL issuance rules the PCA imposes and using the next scheduled issue date the CA specified (see Section 3.5.1). CAs MAY distribute CRLs to subordinate UAs using the CRL processing type available in PEM messages (see RFC 1421). CAs also MAY provide access to CRLs via the database mechanism described in RFC 1424 and alluded to immediately above. 💜

3.5 Certificate Revocation 🦋

3.5.1 X.509 CRLs ✨

X.509 says it's a CA's job to maintain a "time-stamped list of the certificates it issued which have been revoked." 📜 There are two main reasons a CA revokes a certificate: suspected compromise of a private component (which invalidates the matching public component), or a change of user affiliation (which invalidates the DN). Certificate Revocation Lists (CRLs) as defined in X.509 are one way to pass along revocation info, but ngl they're not a perfect mechanism 🙈 The big issue is that an X.509 CRL only tells you how old its information is. It doesn't give you any way to tell whether it's the most current CRL available from a given CA.

The proposed architecture sets a CRL format that specifies not only the date of issue, but also the next scheduled date of issue 🗓️ With that convention, when the next scheduled issue date arrives, a CA (throughout this section, when the term "CA" is employed, it SHOULD be interpreted broadly, to include the IPRA and PCAs as well as organizational, residential, and PERSONA CAs) will issue a new CRL, even if the list of entries hasn't changed. So each CA can independently establish and advertise how often it issues CRLs 🥰 This doesn't rule out issuing one more often, e.g., in case of some emergency, but no system-wide mechanisms are architected for alerting users that an unscheduled issuance has happened. This scheduled issuance convention lets UAs determine whether a given CRL is "out of date," which is something the (1988) X.509 CRL format just can't do.

The text describing CRL management and the CRL format specified in X.509 (1988) don't match, bestie 😭 For example, the format associates an issuer distinguished name with each revoked certificate, even though the text says a CRL contains entries for only a single issuer (which is separately specified in the CRL format). The CRL format adopted for PEM is a (simplified) format consistent with the text of X.509, but not identical to the accompanying format. The ASN.1 format for CRLs used with PEM is provided in Appendix A.

X.509 also defines a syntax for the "time-stamped list of revoked certificates representing other CAs." This syntax, the "AuthorityRevocationList" (ARL), lets the list include references to certificates issued by CAs other than the list maintainer. There's no syntactic difference between these two lists except how they're stored in directories. Since PEM is expected to be used before widespread directory deployment, this distinction between ARLs and CRLs isn't syntactically significant. As a simplification, this document specifies the use of the CRL format defined below for revocation of both user and CA certificates 🎀

3.5.2 PEM CRL Format 💖

Appendix A contains the ASN.1 description of the CRLs specified by this document. This section gives an informal description of the CRL components, kind of like what we did for certificates in Section 3.3 🧁

  1. signature (signature algorithm ID and parameters)
  2. issuer
  3. last update
  4. next update
  5. revoked certificates

The "signature" is completely analogous to the signature data item in a certificate. Similarly, the "issuer" is the DN of the CA which signed the CRL. The "last update" and "next update" fields contain time and date values (UTCT format) that say, respectively, when this CRL was issued and when the next CRL is scheduled to be issued. Finally, "revoked certificates" is a sequence of ordered pairs. The first element is the serial number of the revoked certificate, and the second element is the time and date of the revocation for that certificate 🔍

The semantics of that second element aren't made clear in X.509 🤷‍♀️ For example, the time and date might indicate when a private component was thought to have been compromised, or when the report of that compromise reached the CA.

For uniformity, this document goes with the latter convention: the revocation date is the time and date at which a CA formally acknowledges a report of a compromise or a change of DN attributes. As with certificates, it is RECOMMENDED that the UTCT values be of no finer granularity than minutes and that all values be stated in terms of Zulu ⏱️

3.6 Certificate Validation 🧚

3.6.1 Validation Basics 🌈

Every UA MUST contain the public component of the IPRA as the root for its certificate validation database 👑 Public components associated with PCAs MUST be identified as such, so the certificate validation process described below can operate correctly. Whenever a certificate for a PCA is entered into a UA cache, e.g., if it's encountered in a PEM message encapsulated header, the certificate MUST NOT be entered into the cache automatically. Instead, the user MUST be notified and MUST explicitly direct the UA to enter any PCA certificate data into the cache. This precaution is essential because putting a PCA certificate in the cache implies the user recognizes the policy associated with that PCA 🛡️

Bestie, that last bit is the whole vibe. The user has to say yes. The UA is not allowed to just do it on its own 🙅‍♀️

Validating a certificate begins with verifying that the signature on it is valid. That means the hash computed on the certificate contents has to match the value you get from decrypting the signature field with the issuer's public component 🔐 In order to do this, the user MUST possess the public component of the issuer, either via some integrity-assured channel or by extracting it from another (validated) certificate. To rapidly end this recursive validation process, we recommend each PCA sign certificates for all CAs within its domain, even CAs that are certified by other, superior CAs in the certification hierarchy 🏃‍♀️💨

The public component needed to validate certificates signed by the IPRA is made available to each user as part of registration or through the PEM installation process. So a user can validate any PCA certificate immediately 🙌 CAs are certified by PCAs, so validating a CA certificate requires processing a validation path of length two. User certificates are issued by CAs (either immediately subordinate to PCAs or subordinate to other CAs), so validating a user certificate may require three or more steps. Local caching of validated certificates by a UA can speed this up significantly 🚀

Consider this: a user receives a privacy enhanced message from an originator they've never corresponded with before, and the message originator includes a full certification path in the PEM message header 📨 First, the recipient can use the IPRA's public component to validate a PCA certificate contained in an Issuer-Certificate field. Using the PCA's public component extracted from that certificate, the CA certificate in an Issuer-Certificate field can also be validated. This process can be repeated until the certificate for the originator, from the Originator-Certificate field, is validated.

Once that's done, the recipient can extract the originator's public component and use it to decrypt the content of the MIC-Info field. By comparing the decrypted contents of this field against the MIC computed locally on the message, the user verifies the data origin authenticity and integrity of the message 🥹 It is RECOMMENDED that implementations of privacy enhanced mail cache validated public components (acquired from incoming mail) to speed up this process. If a message arrives from an originator whose public component is held in the recipient's cache (and if the cache is maintained in a fashion that ensures timely incorporation of received CRLs), the recipient can immediately use that public component without the certificate validation process described here. (For some digital signature algorithms, the processing required for certificate validation is considerably faster than that involved in signing a certificate. Use of such algorithms serves to minimize the computational burden on UAs.) ⚡

3.6.2 Display of Certificate Validation Data 🦋

PEM provides authenticated identities for message recipients and originators, expressed in the form of distinguished names 🪪 Mail systems in which PEM is employed MAY use identifiers other than DNs as the primary means of identifying recipients or originators. So to benefit from these authentication facilities, each PEM implementation MUST employ some means of binding native mail system identifiers to distinguished names, in a fashion that does not undermine this basic PEM functionality 💅✨

okay so, if a real human is using PEM directly, the full DN of whoever sent a PEM message they received SHOULD be shown to them 💌🫶. Just showing the PEM-protected content next to a sender name from the native mail system is not the same security glow-up 😬, and it could let somebody spoof the sender 👻. If the recipient is a forwarding agent, like a list exploder or a mail relay, showing the originator's DN isn't a relevant thing at all 🤷‍♀️. The essential thing, always, is that the final recipient of a PEM message can figure out who the originator is using the PEM certification system, rather than trusting unauthenticated stuff pulled out of the native message system 💅.

Flip it around for the originator of an ENCRYPTED message 🔁. It's important that recipient identities get linked to the DNs listed in the PEM certificates 🔗. The PEM implementation can do this in a bunch of ways 🧩, like showing recipient DNs when you submit the message, or keeping a super tightly controlled binding between local aliases and the DNs 🔐. If the originator is a forwarding process, the linkage can happen through mechanisms that don't really apply to a human typing things in 🤖. Again, the essential requirement is to avoid any procedures that might undermine the authentication services PEM provides 🛡️.

So yeah, it's a local matter how and what certification info gets shown to a human during submission or delivery of a PEM message 🎀. Still, all PEM implementations MUST let the user display a full certification path for any certificate used in PEM whenever they ask 🧾. But bestie, implementors are urged to not overwhelm people with certification path info 🙈, because that can confuse or distract them from the critical stuff above 🌸.

3.6.3 Validation Procedure Details ✨

Every PEM implementation is REQUIRED to run the following validation steps 🧐 for every public component used when submitting an ENCRYPTED PEM message or delivering an ENCRYPTED, MIC-ONLY, or MIC-CLEAR PEM message 📬. A public component MAY be pulled from an internal source, like a (secure) cache at the originator or recipient, or it MAY come from an external source, like the PEM header of an incoming message or a directory 📂. The following procedures applies to validating certificates from either type of source 💖.

Validating a public component means building a certification path between that component and the public component of the IPRA 🛤️. Every certificate in this path MUST have its validity interval checked ⏰. PEM software MUST, at a minimum, warn the user if any certificate in the path fails the validity interval check, though how that warning looks is a local matter 🎨. For example, the warning might say which certificate in the path has expired 😵. Local security policy MAY prohibit use of expired certificates 🚫.

Each certificate also MUST be checked against the current CRL from that certificate's issuer, so revoked certificates don't sneak in 🙅‍♀️. If the UA doesn't have access to the current CRL for any certificate in the path, the user MUST be warned 🚨. Again, the form of that warning is a local matter. For example, it might say whether the CRL is unavailable or, if it's available but not current, the CRL issue date SHOULD be displayed 📅. Local policy MAY prohibit use of a public component that can't be checked against a current CRL, and in that case the user SHOULD receive the same information as the warnings described above 💫.

If any revoked certificates turn up while building a certification path, the user MUST be warned 🚩. The form of the warning is a local matter, but it is RECOMMENDED that this warning be more stringent than the ones mentioned above 💥. For example, this warning might show the issuer and subject DNs from the revoked certificate plus the date of revocation, and then require the user to give a positive response before the submission or delivery process MAY proceed 🛑. In the case of message submission, the warning might show the identity of the recipient hit by this validation failure, and the user might get the option to drop that recipient from recipient list processing without affecting PEM processing for the remaining recipients 👯. Local policy MAY prohibit PEM processing if a revoked certificate shows up while building a certification path 🙅.

Heads up 📝: to follow these validation procedures, a certificate cache MUST maintain all of the information in a certificate, not just the DNs and the public component 🗂️. For example, the serial number and validity interval MUST be associated with the cache entry so the checks above actually work ✅. Also, these procedures apply to human interaction during message submission and delivery, and they aren't directly applicable to forwarding processes 🔁. When non-human interaction is involved, a compliant PEM implementation MUST provide parameters so a process can specify whether certificate validation will succeed or fail if any condition shows up that would cause a warning to a human user 🤖.

Finally, while validating certificates like we talked about, there's one more check ✨: one additional check MUST be performed, and it's this: the subject DN of every certificate MUST be subordinate to the certificate issuer DN, EXCEPT if the issuer is the IPRA or a PCA (which is another reason to keep the IPRA and PCA entries separate in a certificate cache 🗃️). This requirement applies to all PEM implementations as part of keeping up the certification hierarchy constraints defined in this document 🏛️. Any certificate which does not comply with these requirements is considered invalid and MUST be rejected in PEM submission or delivery processing 💀. The user MUST be notified of the nature of this fatal error 🚨.

A. Appendix A: ASN.1 Syntax for Certificates and CRLs 🎀

A.1 Certificate Syntax 🧚

The X.509 certificate format is defined by the following ASN.1 syntax 📜:

Certificate ::= SIGNED SEQUENCE{
        version [0]     Version DEFAULT v1988,
        serialNumber    CertificateSerialNumber,
        signature       AlgorithmIdentifier,
        issuer          Name,
        validity        Validity,
        subject         Name,
        subjectPublicKeyInfo    SubjectPublicKeyInfo}

Version ::=     INTEGER {v1988(0)}

CertificateSerialNumber ::=     INTEGER

Validity ::=    SEQUENCE{
        notBefore       UTCTime,
        notAfter        UTCTime}

SubjectPublicKeyInfo ::=        SEQUENCE{
        algorithm               AlgorithmIdentifier,
        subjectPublicKey        BIT STRING}


AlgorithmIdentifier ::= SEQUENCE{
        algorithm       OBJECT IDENTIFIER,
        parameters      ANY DEFINED BY algorithm OPTIONAL}

The components of this structure are defined by the ASN.1 syntax from the X.500 Series Recommendations 📚. RFC 1423 gives references for, and the values of, the AlgorithmIdentifiers that PEM uses in the subjectPublicKeyInfo and the signature data items 🔑. It also describes how a signature gets generated and how the results are represented ✍️. Since the certificate is a signed data object, the distinguished encoding rules (see X.509, section 8.7) MUST be applied before signing 🔒.

A.2 Certificate Revocation List Syntax 💜

This ASN.1 syntax is derived from X.509 and lines up with the suggested format from recently submitted defect reports 🛠️. It defines the format of CRLs for use in the PEM environment 🦋.

CertificateRevocationList ::= SIGNED SEQUENCE{
        signature       AlgorithmIdentifier,
        issuer          Name,
        lastUpdate      UTCTime,
        nextUpdate      UTCTime,
        revokedCertificates
                        SEQUENCE OF CRLEntry OPTIONAL}

CRLEntry ::= SEQUENCE{
        userCertificate SerialNumber,
        revocationDate UTCTime}

References 📚

[1] CCITT Recommendation X.411 (1988), "Message Handling Systems: Message Transfer System: Abstract Service Definition and Procedures".

[2] CCITT Recommendation X.509 (1988), "The Directory - Authentication Framework".

[3] CCITT Recommendation X.520 (1988), "The Directory - Selected Attribute Types".

[4] NIST Special Publication 500-183, "Stable Agreements for Open Systems Interconnection Protocols," Version 4, Edition 1, December 1990.

[5] North American Directory Forum, "A Naming Scheme for c=US", RFC 1255, NADF, September 1991.

[6] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, DEC, February 1993.

[7] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, TIS, February 1993.

[8] Balaski, B., "Privacy Enhancement for Internet Electronic Mail: Part IV: Notary, Co-Issuer, CRL-Storing and CRL-Retrieving Services", RFC 1424, RSA Laboratories, February 1993.

[9] North American Directory Forum, "NADF Standing Documents: A Brief Overview", RFC 1417, NADF, February 1993.

Patent Statement ✨

okay so this version of Privacy Enhanced Mail (PEM) leans on patented public key encryption tech for authentication and encryption 🔐 which is a big deal, bestie. The Internet Standards Process (as defined in RFC 1310) is picky about this. Before a spec can be approved as a Proposed, Draft or Internet Standard, the patent holder has to give a written statement saying a license will be made available to applicants under reasonable terms and conditions. no cap, that's the rule 💅

The Massachusetts Institute of Technology and the Board of Trustees of the Leland Stanford Junior University gave Public Key Partners (PKP) exclusive sub-licensing rights to the following US patents, plus all of their corresponding foreign patents 🌸

      Cryptographic Apparatus and Method
      ("Diffie-Hellman")............................... No. 4,200,770

      Public Key Cryptographic Apparatus
      and Method ("Hellman-Merkle").................... No. 4,218,582

      Cryptographic Communications System and
      Method ("RSA")................................... No. 4,405,829

      Exponential Cryptographic Apparatus
      and Method ("Hellman-Pohlig").................... No. 4,424,414

PKP says these patents cover all known methods of practicing public key encryption, including the variations collectively known as El Gamal. that's a LOT of territory 😭

PKP gave the Internet Society written assurance that parties will be able to obtain, under reasonable, nondiscriminatory terms, the right to use the technology covered by these patents. 🫶 That assurance is documented in RFC 1170, titled "Public Key Standards and Licenses". A copy of the written assurance dated April 20, 1990, may be obtained from the Internet Assigned Number Authority (IANA).

Now the disclaimers, which are very important. The Internet Society, Internet Architecture Board, Internet Engineering Steering Group and the Corporation for National Research Initiatives take no position on the validity or scope of the patents and patent applications, and no position on whether the terms of the assurance are appropriate ⚖️ The Internet Society and the other groups above haven't decided anything about any other intellectual property rights that might apply to practicing this standard. So any further thinking about these matters is the user's own responsibility 🙈 bestie, go do your homework!

Security Considerations 🔒

okay, the entire document is about security. 🔐😤 Like, every single bit of it. Literally nothing but security, so yeah, take it seriously, periodt 💀

Author's Address 🖋️

   Steve Kent
   BBN Communications
   50 Moulton Street
   Cambridge, MA 02138

   Phone: (617) 873-3988
   EMail: kent@BBN.COM
📦 where this page comes from