RFC 1114

Privacy enhancement for Internet electronic mail: Part II - certificate-based key management

📅 published August 1989, from ietf

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

okay bestie, so this is RFC 1114 🎀, part II of the privacy enhancement series for internet email. it's all about certificate-based key management, which is basically how people get the keys they need to actually protect their mail 🔐

Here's the title block tea ☕

  • Working group: Network Working Group
  • Authors: S. Kent (BBNCC) and J. Linn (DEC)
  • Prepared for: IAB Privacy Task Force
  • Date: August 1989
  • Status: draft standard elective protocol, and they literally want discussion and suggestions 🫶
  • Obsoletes or updates: the title block doesn't list anything it obsoletes or updates 🤷‍♀️

Status of This Memo ✨

so this RFC suggests a draft standard elective protocol for the Internet community. it's basically saying "hey, talk to us and tell us how to improve this" 💬 distribution of this memo is unlimited, so share it around 🌈

Acknowledgment 🙏

this RFC grew out of a bunch of IAB Privacy Task Force meetings and the internal working papers passed around for those meetings. big thank you to the Privacy Task Force members whose comments and contributions at those meetings helped get this RFC written: David Balenson, Curt Barker, Matt Bishop, Morrie Gasser, Russ Housley, Dan Nessett, Mike Padlipsky, Rob Shirey, and Steve Wilbur 🫶

Table of Contents 📑

   1.  Executive Summary                                               2
   2.  Overview of Approach                                            3
   3.  Architecture                                                    4
   3.1  Scope and Restrictions                                         4
   3.2  Relation to X.509 Architecture                                 7
   3.3  Entities' Roles and Responsibilities                           7
   3.3.1  Users and User Agents                                        8
   3.3.2  Organizational Notaries                                      9
   3.3.3  Certification Authorities                                   11
   3.3.3.1  Interoperation Across Certification Hierarchy Boundaries  14
   3.3.3.2  Certificate Revocation                                    15
   3.4  Certificate Definition and Usage                              17
   3.4.1  Contents and Use                                            17
   3.4.1.1  Version Number                                            18
   3.4.1.2  Serial Number                                             18
   3.4.1.3  Subject Name                                              18
   3.4.1.4  Issuer Name                                               19
   3.4.1.5  Validity Period                                           19
   3.4.1.6  Subject Public Component                                  20
   3.4.1.7  Certificate Signature                                     20
   3.4.2  Validation Conventions                                      20
   3.4.3  Relation with X.509 Certificate Specification               22
   NOTES                                                              24

1. Executive Summary 🌸

okay so this is one of a series of RFCs defining privacy enhancement mechanisms for electronic mail sent using internet mail protocols. RFC-1113 (the successor to RFC 1040) lays out protocol extensions and processing procedures for RFC-822 mail messages, as long as suitable cryptographic keys are already held by originators and recipients. that's the necessary precondition, no cap 🔑. RFC-1115 specifies the algorithms for processing privacy-enhanced messages, as RFC-1113 calls for. this RFC defines a supporting key management architecture and infrastructure, based on public-key certificate techniques, to give keying information to message originators and recipients. a subsequent RFC, the fourth in this series, will provide detailed specifications, paper and electronic application forms, etc. for the key management infrastructure described here ✨

the key management architecture in this RFC is compatible with the authentication framework described in X.509. the big contributions here aren't in computer communication protocols or algorithms. they're in procedures and conventions for the key management infrastructure 💅. this RFC packs in a bunch of conventions to make near-term implementation easier. some of them may get superseded over time, once the motivations for them stop applying, e.g., when X.500 or similar directory servers become well established 🌷

the RSA cryptographic algorithm was selected for this key management system 🦄. it's covered in the U.S. by patents administered through RSA Data Security, Inc. (hereafter abbreviated RSADSI). it got picked because it provides all the necessary algorithmic facilities, it's "time tested," and it's relatively efficient to implement in software or hardware. it's also the primary algorithm identified (at this time) for use in international standards where an asymmetric encryption algorithm is required. protocol facilities (e.g., algorithm identifiers) exist to permit use of other asymmetric algorithms if it ever becomes appropriate to use a different one for key management. however, the infrastructure described here is specific to the RSA algorithm in many respects, so it might be different if the underlying algorithm were to change 🤔

current plans call for RSADSI to work with subscriber organizations as a "certifying authority," in a fashion described later in this RFC. RSADSI will offer a service in which it signs a certificate that a user has generated and that has been vouched for either by an organization or by a Notary Public. this service carries a $25 biennial fee, which includes an associated license to use the RSA algorithm in conjunction with privacy protection of electronic mail 💸. users who don't come under the purview of the RSA patent, e.g., users affiliated with the U.S. government or users outside of the U.S., may use different certifying authorities and won't require a license from RSADSI. procedures for interacting with those other certification authorities, maintenance and distribution of revoked certificate lists from them, etc. are outside the scope of this RFC. however, techniques for validating certificates issued by other authorities are contained within this RFC, to ensure interoperability across the resulting jurisdictional boundaries 🌍

2. Overview of Approach 🦋

this RFC defines a key management architecture based on the use of public-key certificates, in support of the message encipherment and authentication procedures defined in RFC-1113. in the proposed architecture, a "certification authority" representing an organization applies a digital signature to a collection of data. that data includes a user's public component, various information that serves to identify the user, and the identity of the organization whose signature is affixed. (throughout this RFC we use "private component" and "public component" to refer to the quantities that are, respectively, kept secret and made publicly available in asymmetric cryptosystems. this avoids the possible confusion that comes from using "secret key" to mean either of those quantities, or a key in a symmetric cryptosystem 🗝️) this sets up a binding between these user credentials, the user's public component, and the organization that vouches for the binding. the resulting signed data item is called a certificate. the organization identified as the certifying authority for a certificate is the "issuer" of that certificate 💅

when signing the certificate, the certification authority vouches for the user's identification, especially as it relates to the user's affiliation with the organization. the digital signature is affixed on behalf of that organization, in a form that every member of the privacy-enhanced electronic mail community can recognize ✨. once generated, certificates can be stored in directory servers, sent through unsecure message exchanges, or distributed by any other means that make them easily accessible to message originators, without regard for the security of the transmission medium 📬

prior to sending an encrypted message, an originator must acquire a certificate for each recipient and must validate those certificates. briefly, validation is done by checking the digital signature in the certificate, using the public component of the issuer whose private component was used to sign it. the issuer's public component is made available via some out of band means (described later), or it is itself distributed in a certificate to which this validation procedure is applied recursively 🔁

once a certificate for a recipient is validated, the public component contained in it is extracted and used to encrypt the data encryption key (DEK) that is used to encrypt the message itself 🔒

the resulting encrypted DEK is incorporated into the X-Key-Info field of the message header. when an encrypted message is received, a recipient uses their secret component to decrypt this field, extracting the DEK, and then uses this DEK to decrypt the message 🔓

in order to provide message integrity and data origin authentication, the originator generates a message integrity code (MIC), signs (encrypts) the MIC using the secret component of their public-key pair, and includes the resulting value in the message header in the X-MIC-Info field. the originator's certificate is also included in the header, in the X-Certificate field as described in RFC-1113, to make validation possible in the absence of ubiquitous directory services 📜. when a privacy-enhanced message is received, the recipient validates the originator's certificate, extracts the public component from the certificate, and uses that value to recover (decrypt) the MIC. the recovered MIC is then compared against the locally calculated MIC, to verify the integrity and data origin authenticity of the message 💖

3. Architecture 🏗️

3.1. Scope and Restrictions ✨

okay so bestie, this section is basically the vibe check for the whole architecture 💅 The goal is a base for managing public-key cryptosystem values so privacy enhanced electronic mail (see RFC-1113) can work on the Internet 🦋 It covers how you order certificates from issuers, how they get generated and distributed, and the "hot listing" of revoked certificates 🚫 (the hot list is literally where the revoked ones go 💀). Heads up: RFC 1040 got updated and reissued as RFC-1113 at the same time as this one 🌸 RFC-1113 explains the syntax and meaning of the new or revised header fields used to transfer certificates, represent the DEK and MIC in this public-key setting, and pull algorithm definitions into their own RFC so more algorithms can be added later 🧚 So this RFC handles the certificate management side, and RFC-1113 handles how the mail itself is represented and processed, including the changes this key management tech needs 🫶

Next, the architecture adds conventions for certification paths that X.509 doesn't strictly require, and the technology itself doesn't need them either 🙈 Ngl, this was a choice. It comes from two things: RSA being a patented algorithm in the U.S. 🇺🇸 and the fact that some organization has to take on operational responsibility for certificate management while the directory system for email is still super minimal 📭 The RFC expects some of these constraints, like directory service availability, to change over time, and the procedures will get reviewed and modified when that happens 🌈

Here's the big picture: user certificates are the leaves in a shallow (usually two tier) certification hierarchy, aka a tree 🌳 Organizations that act as issuers sit higher up in the tree 👑 This keeps validating user certs simple, because the certification paths stay short, and it makes the link between a certificate issuer and a user super explicit 💖 Only organizations can be issuers here, and a user certificate may not appear in a certification path except as the terminal node (the last stop) 🛑 These conventions end up making a hierarchy that's a compatible subset of what X.509 permits, in both syntax and semantics ✨

The RFC proposes that RSADSI act as a "co-issuer" of certificates on behalf of most organizations 🤝 This can be done "transparently," so the organizations look like the issuers as far as certificate formats and validation procedures go 🎀 How? RSADSI generates and holds the secret components used to sign certificates for the organizations 🔐 Why? Two reasons. One, it simplifies accounting for licensing, making sure RSADSI gets paid for each certificate 💸 Two, it boosts the overall integrity of the system by giving the private components used to sign certificates one uniform, high level of protection 🛡️ If an organization signed directly for its affiliated users, it would need very stringent security and accounting mechanisms and (elaborate) legal agreements with RSADSI to get a comparable level of assurance 😭 Direct signing requests will be considered case by case, but orgs are strongly urged to use the facilities this RFC proposes 💅

Now, disclosure risks are different depending on whose secret component leaks 👀 An organization's secret component is only used to sign certificates, never to encrypt message traffic 🔏 So if it got exposed, forged certificates could be made for users affiliated with that org, but privacy-enhanced messages protected with legitimate certificates would be unaffected 🙌 Also, any certificates generated after such a disclosure are readily traceable to the issuing authority holding that component (e.g., RSADSI), thanks to the non-repudiation feature of the digital signature 🧾 The registration and signing procedures in this RFC would provide non-repudiable evidence if RSADSI disclosed an organization's secret component 🕵️‍♀️ That's why this RFC advocates using RSADSI as a co-issuer until technical security mechanisms can offer a similar, system-wide level of assurance for (distributed) certificate signing by organizations 🔥

Heads up, bestie: the exceptions to this signing paradigm are a big deal, so read this part twice 👀

We spot two classes of exceptions. First, RSA is patented only within the U.S., so certificate signing by issuers is very likely to happen outside the U.S., independent of RSADSI 🌍 Second, the research that led to RSA was sponsored by the National Science Foundation, so the U.S. government keeps royalty-free license rights to the algorithm 🦅 That means the U.S. government may set up its own certificate generation facility for its affiliated users 🏛️ A bunch of the procedures in this document only apply when RSADSI is the certificate co-issuer, and all other certificate generation practices are outside this RFC's scope 📜

This RFC specifies how users order certificates either directly from RSADSI or through a representative at an organization they're affiliated with (like their employer or school) 🎓 Syntax lets a recipient figure out, to some granularity, which identifying information in the certificate is vouched for by the issuer 🔍 Usually orgs vouch for a user's affiliation with them and maybe the user's role, on top of their name 💼 In other cases (covered in section 3.3.3) a certificate may say the issuer only vouches for the user's name, which implies that any other identifying info in it may not have been validated by the issuer 🤷‍♀️ These semantics go beyond X.509, but they're not incompatible with it ✨

The key management architecture here is designed to support privacy enhanced mail as defined in this RFC, RFC-1113, and their successors 💌 It also supports X.400 mail security facilities (per X.411), which paves the way for a future move to the OSI/CCITT Message Handling System paradigm on the Internet 🧚‍♀️ The certificate issued to a user for the $25 biennial fee grants that user a license from RSADSI to employ the RSA algorithm for certificate validation and for encryption and decryption in this electronic mail context 💸 No use of the algorithm outside the scope defined in this RFC is authorized as of now 🚫 Expanding the license to other Internet security applications is possible, but not yet authorized ⏳ And the license does not authorize selling software or hardware that incorporates RSA, since it's an end-user license, not a developer's license 💀

3.2. Relation to X.509 Architecture 🗂️

CCITT 1988 Recommendation X.509, "The Directory - Authentication Framework", defines a framework for authenticating entities involved in a distributed directory service 🔐 Strong authentication, as defined in X.509, is done with public-key cryptosystems 🔑 Unforgeable certificates are generated by certification authorities, and these authorities may be organized hierarchically, though X.509 doesn't require that 🌲 There's no implied mapping between a certification hierarchy and the naming hierarchy imposed by directory system naming attributes ❌ The public-key certificate approach from X.509 was also adopted in CCITT 1988 X.411 to support the message handling application 📨

This RFC interprets the X.509 certificate mechanism so it serves the needs of privacy-enhanced mail on the Internet 💜 The certification hierarchy proposed here is intentionally a subset of what X.509 allows 🎯 Lots of the constraints were added to simplify certificate validation, since there isn't a widely available, user-level directory service yet 🙃 The hierarchy also embodies semantics that X.509 doesn't explicitly address, but those are consistent with X.509 precepts 🧠 The extra semantic constraints were adopted to explicitly address questions of issuer "authority," which the RFC feels are not well defined in X.509 🤔

3.3. Entities' Roles and Responsibilities 🎭

One way to explain the architecture is to look at the roles defined for the various entities and what each one needs to do for the proposed system to work properly 🧩 The next sections identify three types of entities: users and user agents, organizational notaries, and certification authorities 🫶 For each class, we describe the (electronic and paper) procedures the entity must execute as part of the architecture, plus the responsibilities it takes on based on its role ✅ The infrastructure described here applies when RSADSI acts as a co-issuer of certificates, sharing the role of certification authority (described later) 👑 Other certifying authority arrangements may employ different procedures and aren't addressed by this RFC 🙅‍♀️

3.3.1. Users and User Agents ✨

Okay so the term User Agent (UA) is borrowed from the CCITT X.400 Message Handling Systems (MHS) Recommendations 💅 and they 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." Iconic definition, tbh. UAs swap messages by calling on a supporting Message Transfer Service (MTS) 📬

Big rule time 🔒 A UA process doing privacy-enhanced mail processing must protect the private component of its associated entity (usually a real human user) from disclosure. Treat that private component like your diary 🧚

We expect a user to use some helper software (not otherwise tied to the UA) to generate his public/private component pair and to compute the (one-way) message hash that the registration procedure needs. The public component, along with info that identifies the user, will get sent to an organizational notary (see below) so it can be included in an order to an issuer. How the components get generated is a local matter, but we're expecting Internet-wide distribution of software for pair generation to make the whole thing easier 🌈 The mechanisms used to transfer the public component and the user identification info must preserve the integrity of both quantities and bind the two during this transfer.

There are two ways a user can order a certificate 📜: through their affiliation with an organization, or directly through RSADSI. Either way, a user will be required to send a paper order to RSADSI on a form described in a subsequent RFC, and it has to contain the following:

  1. Distinguished Name elements (e.g., full legal name, organization name, etc.)
  2. Postal address
  3. Internet electronic mail address
  4. A message hash function, binding the above information to the user's public component

Here's the twist 🙈 the user's public component is NOT sent via this paper path. Part of the reason is that the public component is made up of many (>100) digits, so it's super prone to errors if you copy it to and from a piece of paper. Instead, a message hash is computed on the identifying information and the public component, and only this (smaller) message hash value gets sent along with the identifying information. So the public component only travels through an electronic path, as described below 💖

If the user isn't affiliated with an organization that has set up its own "electronic notary" capability (an organization notary, or "ON," as discussed in the next section), then this paper registration form must be notarized by a Notary Public. If the user is affiliated with an organization that has set up one or more ONs, the paper form doesn't need a Notary Public's endorsement. At the same time as the paper registration, the user has to send the information outlined above plus their public component, either to their ON or directly to RSADSI if no appropriate ON is available to them. Direct transmission to RSADSI happens via electronic mail, using a representation described in a subsequent RFC. The paper registration must come with a check or money order for $25, or an organization can set up some other billing arrangement with RSADSI. The maximum (and default) lifetime of a certificate ordered through this process is two years ⏳

Sending the ID info and public component from a user to their ON is a local matter 🫶 but we expect electronic mail will be the preferred approach in lots of situations, and we anticipate general distribution of software to support this process. Heads up: it's the responsibility of the user and their organization to make sure this transfer has integrity, using some means they consider adequately secure for their local computing and communication environment. There's no requirement for secrecy with this info transfer, but the integrity of the information must be ensured 🔐

3.3.2. Organizational Notaries 🦋

An organizational notary is an individual who acts as a clearinghouse for certificate orders coming from within an administrative domain, like a corporation or a university 🏫 An ON represents an organization or organizational unit (in X.500 naming terms), and is assumed to have some independence from the users on whose behalf certificates are ordered. An ON will be restricted, through mechanisms implemented by the issuing authority (e.g., RSADSI), to ordering certificates that are properly associated with that ON's domain. For example, an ON for BBN should not be able to order certificates for users affiliated with MIT or MITRE, and vice versa. Similarly, if a corporation such as BBN set up ONs on a per-subsidiary basis (corresponding to organization units in X.500 naming parlance), then an ON for the BBN Communications subsidiary should not be allowed to order a certificate for a user who claims affiliation with the BBN Software Products subsidiary. Boundaries, bestie 💅

It's safe to assume the set of ONs changes pretty slowly and that there are relatively few of them compared to the number of users 🌸 So a more extensive, higher assurance process may reasonably be attached to ON accreditation than to per-user certificate ordering. Restrictions on the range of information an ON is authorized to certify are set up as part of this more elaborate registration process. The procedures for establishing organizations and organizational units in the RSADSI database, and for registering ONs, will be described in a subsequent RFC.

An ON is responsible for establishing the correctness and integrity of the information in an order, and will generally vouch for (certify) the accuracy of identity information at a finer granularity than a Notary Public can provide. We don't think it's feasible to enforce uniform standards for the user certification process across all ONs, but we anticipate that organizations will try hard to keep high standards here, given the "visibility" of the identification data contained in certificates 👀 An ON may also constrain the validity period of an ordered certificate, restricting it to less than the default two year interval imposed by the RSADSI license agreement.

An ON takes part in the certificate ordering process by accepting and validating identification information from a user and forwarding it to RSADSI. The ON accepts the electronic ordering information described above (Distinguished Name elements, mailing address, public component, and message hash computed on all of this data) from a user. (The representation for user-to-ON transmission of this data is a local matter, but we anticipate that the encoding specified for ON-to-RSADSI representation of this data will often be used.) The ON sends an integrity-protected (as described in RFC-1113) electronic message to RSADSI, vouching for the correctness of the binding between the public component and the identification data. So, to support this function, each ON will hold a certificate as an individual user within the organization it represents 🎀 RSADSI will maintain a database that identifies the users who also act as ONs, and the database will specify constraints on the credentials each ON is authorized to certify. The electronic mail representation for a user's certificate data in an ON message to RSADSI will be specified in a subsequent RFC ✨

3.3.3 Certification Authorities ✨

okay so in X.509, "certification authority" is defined as "an authority trusted by one or more users to create and assign certificates" 💅 this alt expansion of "CA" is basically the same vibe as the "central authority" from RFC-1040 and RFC-1113 🫶. the only difference is that X.509 doesn't require a CA to be a distinguished entity or to serve a huge number of users, which is what these RFCs imagined 😭. instead, any user who holds a certificate can act as a CA for any other user 🌈. as we said above, we're limiting the CA role in this email setup to organizational entities 🎀 to keep certificate validation simple ✨, to make organizational affiliation the basis for certification 💜, and to make license accountability easier 🧚.

in the proposed architecture, people affiliated with (registered) organizations go through the process from above 🦋. they forward their certificate info to their ON for certification 💌. the ON checks the user's credentials based on local procedures, then sends the info to RSADSI using privacy-enhanced mail 🔐 so the integrity and authenticity of the info are protected. RSADSI does the actual certificate generation on behalf of the organization the ON represents. remember, it's the identity of the organization (not the ON) that shows up in the issuer field of the user certificate 👑. so it's the organization's private component, not the ON's, that signs the user certificate. obsessed ngl 🙈

RSADSI is the repository for the private components of certificates for organizations or organizational units (but not individuals) 🗝️. basically the CA role is shared between the organizational notaries and RSADSI 🤝. this shared role isn't visible in the certificate syntax, and it isn't apparent from the validation procedure, so RSADSI acting as the actual signer for organizations is transparent to this part of the system ✨.

if an organization did the signing locally and held the private component for its own organization certificate, it would need to contact RSADSI to talk about security safeguards, special legal agreements, etc 📝

a bunch of requirements would be imposed if an organization went this route 😬. the organization would be required to execute additional legal instruments with RSADSI, e.g., to make sure certificates generated by the organization are properly accounted for 🧾. special software would be required to support the signing process, separate from what an ON needs 💻. stringent procedural, physical, personnel and computer security safeguards would be required to keep the whole system at a relatively high security level 🔒. so at this time it's not recommended that organizations pursue this approach 🙅‍♀️, although local certificate generation is not expressly precluded by the proposed architecture 🤷‍♀️.

RSADSI has offered to run a service where it acts as a CA for users who aren't affiliated with any organization, or who are affiliated with an organization that hasn't opted to set up an organizational notary 🌸. to tell these "non-affiliated" certificates apart, the distinguished string "Notary" appears as the organizational unit name of the issuer 🏷️. this convention is used throughout the system. so not only RSADSI, but any other organization that wants to offer this to non-affiliated users can do it in a standard way 💖. for example, a corporation might issue "Notary" certificates to summer students to tell them apart from full-time employees 🍓. at least in RSADSI's case, the standards for verifying credentials with this designation will be well known and widely recognized (e.g., Notary Public endorsement) 📜.

okay let's look at some examples 👀. RSADSI employees will hold certificates that list "RSADSI" as the organization in both the issuer field and the subject field, maybe with no organizational unit specified 💅. certificates obtained directly from RSADSI by users who aren't affiliated with any ON will also say "RSADSI" as the organization and specify "Notary" as the organizational unit in the issuer field 🎀. but these latter certificates carry some other designation for organization (and, optionally, organizational unit) in the subject field 🦋. also, an organization designated in the subject field of such a certificate won't match any organization RSADSI has an ON registered for, to avoid possible confusion 🙈.

in all the cases above, when a certificate is generated, RSADSI will send a paper reply to the ordering user, including two message hash functions 📬:

  1. a message hash computed on the user's identifying information and public component (sent to RSADSI in the registration process), to guarantee its integrity across the ordering process, and
  2. a message hash computed on RSADSI's public component, to provide independent authentication for this public component, which is sent to the user via email (see below).

RSADSI will send the user via electronic mail (not privacy-enhanced) a copy of their certificate, a copy of the organization certificate named in the issuer field of the user's certificate, and the public component used to validate certificates signed by RSADSI 💌. the issuer certificate is included to simplify validation when there's no user-level directory system 🧩, and this distribution will probably be phased out in the future. so, as described in RFC-1113, the originator of a message is encouraged, though not required, to include their certificate and that of its issuer in the privacy-enhanced message header (X-Issuer-Certificate) 🫶. that way, each recipient can process the message using only the info in this header ✨.

the organization (organizational unit) identified in the subject field of the issuer certificate should correspond to the one the user claims affiliation with (as declared in the subject field of their certificate) 🧐. if there's no appropriate correspondence between these fields, recipients ought to be suspicious of the implied certification path 🚨. this relationship should hold, except in the case of "non-affiliated" users, where the "Notary" convention is used.

in contrast, the issuer field of the issuer's certificate will specify "RSADSI" as the organization. in other words, RSADSI certifies all organizational certificates 👑. this lets a recipient validate any originator's certificate (within the RSADSI certification hierarchy) in just two steps ⚡. even if an organization sets up a certification hierarchy with organizational units, certificates for each unit can be certified by both RSADSI and the organizational entity immediately superior to the unit in the hierarchy. this keeps the short certification path feature 🌈. first, the RSADSI public component is used to validate the issuer's certificate. then the issuer's public component is extracted from that certificate and used to validate the originator's certificate 🔁. the recipient then extracts the originator's public component for use in processing the X-Mic-Info field of the message (see RFC-1113) 💜.

the electronic representation used to transmit the data items described above (between an ON and RSADSI) will be contained in a subsequent RFC 📚. to verify that the registration process has been successfully completed and to get ready for privacy-enhanced electronic mail, the user should perform the following steps 🫧:

  1. extract the RSADSI public component, the issuer's certificate and the user's certificate from the message
  2. compute the message hash on the RSADSI public component and compare the result to the corresponding message hash that was included in the paper receipt
  3. use the RSADSI public component to validate the signature on the issuer's certificate (RSADSI will be the issuer of this certificate)
  4. extract the organization public component from the validated issuer's certificate and use this public component to validate the user certificate
  5. extract the identification information and public component from the user's certificate, compute the message hash on it, and compare the result to the corresponding message hash value transmitted via the paper receipt

for a user whose order was processed via an ON, finishing these steps shows that the certificate issued to them matches what they requested and what their ON certified 🎉. it also shows they have the correct public component for RSADSI and for the issuer of their certificate ✅. for a user whose order was placed directly with RSADSI, this shows that their certificate order was properly processed by RSADSI and that they have the valid issuer certificate for the RSADSI Notary 🥳. the user can use the RSADSI public component to validate organizational certificates for organizations other than their own 🌍. they can also use the public component associated with their own organization to validate certificates issued to other users in their organization 🫶.

3.3.3.1 Interoperation Across Certification Hierarchy Boundaries ✨

Okay so, to play nicely with other certification authorities (like foreign CAs or U.S. government CAs), there are two conventions 💅. First, every certifying authority must agree to "cross-certify" each other. That means each one has to be willing to sign a certificate where the issuer is that certifying authority and the subject is another certifying authority. So RSADSI might generate a certificate that names itself as the issuer and a certifying authority for the U.S. government as the subject. Then the reverse happens: that U.S. government CA generates a certificate where it's the issuer and RSADSI is the subject. This cross-certification of "top-level" CAs gives us a basis for validating "lower level" (organization and user) certificates across hierarchy boundaries 🌈. It means users in one hierarchy don't have to do some "out-of-band" thing just to grab a public key for validating certificates from a different hierarchy. Iykyk, it's so much less work 😭

The second convention is that more than one X-Issuer-Certificate field may appear in a privacy-enhanced mail header 🎀. Multiple issuer certificates can be included so a recipient can validate an originator's certificate more easily when they aren't in a common CA hierarchy. For example, say an originator served by the RSADSI certification hierarchy sends a message to a recipient served by a U.S. government hierarchy. The originator could (optionally) include an X-Issuer-Certificate field with a certificate issued by the U.S. government CA for RSADSI. The recipient can then use their public component for the U.S. government CA to validate the RSADSI certificate. From there they pull out the RSADSI public component, use it to validate the certificate for the originator's organization, and then pull out the public component they need to validate the originator's certificate. So yes, more steps are needed when you cross hierarchy boundaries, but it's the same basic procedure. Caching of certificates by UAs can seriously cut down the effort it takes to process messages, so these examples should be viewed as "worst case" scenarios 🙈

3.3.3.2 Certificate Revocation 🦋

X.509 says it's a CA's responsibility to maintain:

  1. a time-stamped list of the certificates it issued which have been revoked
  2. a time-stamped list of revoked certificates representing other CAs

There are two main reasons a CA would revoke a certificate: suspected compromise of a secret component (which invalidates the corresponding public component), or a change of user affiliation (which invalidates the Distinguished Name). As X.509 describes, "hot listing" is one way to propagate revocation information, though it isn't a perfect mechanism 💀. The problem is that an X.509 Revoked Certificate List (RCL) only tells you how old its information is. It gives no basis for figuring out whether the list is the most current RCL available from a given CA. To help with this, the proposed architecture sets up an RCL format that includes not only the date of issue but also the next scheduled date of issue. This is a deviation from the format specified in X.509.

With this convention, when the next scheduled issue date arrives, a CA must issue a new RCL, even if the list of entries hasn't changed. That way each CA can independently set and advertise how often it issues RCLs 🍓. This doesn't rule out issuing RCLs more often, e.g., in case of some emergency. But no Internet-wide mechanisms are architected for alerting users that an unscheduled issuance has happened. This scheduled issuance convention lets users (UAs) figure out whether a given RCL is "out of date," which is something the standard RCL format can't do.

A recent (draft) version of the X.509 recommendation says each RCL should contain the serial numbers of certificates that have been revoked by the CA administering that list, i.e., the CA identified as the issuer for the corresponding revoked certificates. When a UA gets an RCL, it should compare the entries against any cached certificate information and delete the cache entries that match the RCL entries. (Recall that certificate serial numbers are unique only for each issuer, so you have to be careful with this cache search.) The UA should also keep the RCL so it can screen incoming messages for revoked certificates carried in their headers. More specific details on processing RCLs are beyond the scope of this RFC, since they depend on local certificate management techniques 🧚

In the architecture this RFC defines, an RCL is maintained for each CA (organization or organizational unit). It's signed using that organization's private component, so it can be verified with the public component taken from that organization's certificate ⭐ The RSADSI Notary organizational unit is included in this collection of RCLs. CAs operated under the auspices of the U.S. government or foreign CAs are requested to provide RCLs that follow these conventions, at least until X.509 RCLs offer equivalent functionality, so they can interoperate with the Internet community. There's also an additional "top level" RCL that RSAD-SI maintains, and other "top level" CAs should maintain it too, for revoked organizational certificates 👑

The hot listing procedure (except for this top level RCL) works like this: an ON from each organization transmits to RSADSI a list of the serial numbers of users within its organization that should be hot listed. This list gets sent using privacy-enhanced mail to ensure authenticity and integrity, and it uses representation conventions that will be provided in a subsequent RFC. RSADSI then formats the RCL, signs it using the organization's private component, and transmits it back to the ON for dissemination, using a representation defined in a subsequent RFC 🔥 How RCLs get disseminated, both within a CA's administrative domain and across domain boundaries, isn't specified by this proposal. Still, it's anticipated that each hot list will also be available through network information center databases, directory servers, etc. 🌸

Here's the ASN.1 syntax, derived from X.509, that defines the RCL format for the Internet privacy enhanced email environment. You can compare it with the ASN.1 definition of certificates (later in this RFC or in X.509, Annex G) 🫶

      revokedCertificateList  ::=     SIGNED SEQUENCE {
              signature       AlgorithmIdentifier,
              issuer          Name,
              list            SEQUENCE RCLEntry,
              lastUpdate      UTCTime,
              nextUpdate      UTCTime}

      RCLEntry        ::=     SEQUENCE {
              subject         CertificateSerialNumber,
              revocationDate  UTCTime}

3.4 Certificate Definition and Usage 💜

3.4.1 Contents and Use

A certificate contains the following contents:

  1. version
  2. serial number
  3. certificate signature (and associated algorithm identifier)
  4. issuer name
  5. validity period
  6. subject name
  7. subject public component (and associated algorithm identifier)

This section discusses how each of these certificate elements gets interpreted and used 🎀

3.4.1.1 Version Number

The version number field is there to make orderly changes in certificate formats over time easier 🌈 The initial version number for certificates is zero (0).

3.4.1.2 Serial Number

The serial number field is a short form, unique identifier for each certificate generated by an issuer ✨ It gets used in RCLs to identify revoked certificates, instead of including entire certificates. So every certificate an issuer generates must contain a unique serial number. It is suggested that these numbers be issued as a compact, monotonic increasing sequence 🦋

3.4.1.3 Subject Name

A certificate represents its subject's identity and organizational affiliation in the form of a Distinguished Name 🌸 The fundamental binding that the privacy enhancement mechanisms ensure is the one between the public key and the user identity. CCITT Recommendation X.500 defines the concept of Distinguished Name 💅

Version 2 of the U.S. Government Open Systems Interconnection Profile (GOSIP) specifies maximum sizes for O/R Name attributes 🧚 Since most of these attributes also show up in Distinguished Names, we adopted the O/R Name attribute size constraints from GOSIP, noted below. Using these size constraints gives a maximum Distinguished Name length (excluding ASN encoding) of two-hundred fifty-nine (259) characters, based on the required and optional attributes described below for subject names. The following attributes are required in subject Distinguished Names for purposes of this RFC:

  1. Country Name in standard encoding (e.g., the two-character Printable String "US" assigned by ISO 3166 as the identifier for the United States of America, the string "GB" assigned as the identifier for the United Kingdom, or the string "NQ" assigned as the identifier for Dronning Maud Land). Maximum ASCII character length of three (3).
  2. Organizational Name (e.g., the Printable String "Bolt Beranek and Newman, Inc."). Maximum ASCII character length of sixty-four (64).
  3. Personal Name (e.g., the X.402/X.411 structured Printable String encoding for the name John Linn). Maximum ASCII character length of sixty-four (64).

The following attributes are optional in subject Distinguished Names for purposes of this RFC:

  1. Organizational Unit Name(s) (e.g., the Printable String "BBN Communications Corporation"). A hierarchy of up to four organizational unit names may be provided; the least significant member of the hierarchy is represented first. Each of these attributes has a maximum ASCII character length of thirty-two (32), for a total of one-hundred and twenty-eight (128) characters if all four are present 👑

3.4.1.4 Issuer Name

Okay so a certificate shows off its issuer's identity 💅 as a Distinguished Name ✨. The issuer ID matters because it's how you figure out which issuer public component to use when you're validating the cert 🔍. For this RFC, these attributes are required in issuer Distinguished Names:

  1. Country Name (e.g., encoding for "US")
  2. Organizational Name

These attributes are optional in issuer Distinguished Names for this RFC:

  1. Organizational Unit Name(s). (A hierarchy of up to four organizational unit names may be provided; the least significant member of the hierarchy is represented first.) If the issuer is vouching for the user identity in the Notary capacity described above, then exactly one instance of this field must be present and it must consist of the string "Notary". 🫶

As noted earlier, only organizations are allowed as issuers in the proposed authentication hierarchy 🏢. So the Distinguished Name for an issuer should always be that of an organization, not a user, and no Personal Name field may be included in the Distinguished Name of an issuer. No individual people as issuers, periodt 💅

3.4.1.5 Validity Period

A certificate carries a pair of time specifiers 🕰️, marking the start and end of the time period when the certificate is meant to be used. No message should ever be prepared for transmission with a non-current certificate 🚫. But recipients should be prepared to receive messages processed using recently-expired certificates, because mail is slow and unpredictable 📬💀. This fact results from the unpredictable (and sometimes substantial) transmission delay of the staged-delivery electronic mail environment. The default and maximum validity period for certificates issued in this system will be two years 🗓️✨.

3.4.1.6 Subject Public Component

A certificate carries the public component of its associated entity, plus an indication of the algorithm the public component is to be used with 🎀. For this RFC, the algorithm identifier will indicate use of the RSA algorithm, as specified in RFC-1115 🧮. Note that in this context, a user's public component is actually the modulus employed in RSA algorithm calculations. A "universal" (public) exponent is employed in conjunction with the modulus to complete the system 🔑. Two choices of exponents are recommended for use in this context and are described in section 3.4.3. Modulus size will be permitted to vary between 320 and 632 bits 🌸.

3.4.1.7 Certificate Signature

A certificate carries a signature algorithm identifier and a signature, applied to the certificate by its issuer ✍️. The signature is validated by the user of a certificate, in order to determine that the integrity of its contents have not been compromised subsequent to generation by a CA 🛡️. An encrypted, one-way hash will be employed as the signature algorithm. Hash functions suitable for this are notoriously difficult to design and tend to be computationally intensive 🥵. Initially, the system adopts a hash function developed by RSADSI that exhibits performance roughly equivalent to the DES (in software) 🔐. This same function has been selected for use in other contexts in this system where a hash function (message hash algorithm) is required, e.g., MIC for multicast messages 📣. In the future, we expect other one-way hash functions will be added to the list of algorithms designated for this purpose 🔮.

3.4.2 Validation Conventions

Validating a certificate means verifying that the signature affixed to it is valid, i.e., that the hash value computed on the certificate contents matches the value that results from decrypting the signature field using the public component of the issuer 🕵️‍♀️. 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 🔁. In the proposed architecture, this recursive operation is terminated quickly by adopting the convention that RSADSI will certify the certificates of all organizations or organizational units which act as issuers for end users 👑. (Additional validation steps may be required for certificates issued by other CAs as described in section 3.3.3.1.)

Certification means that RSADSI will sign certificates in which the subject is the organization or organizational unit, and for which RSADSI is the issuer. This implies that RSADSI vouches for the credentials of the subject 🫡. This is an appropriate construct since each ON representing an organization or organizational unit must have registered with RSADSI via a procedure more rigorous than individual user registration 🏅. This does not preclude an organizational unit from also holding a certificate in which the "parent" organization (or organizational unit) is the issuer. Both certificates are appropriate and permitted in the X.509 framework. However, in order to facilitate the validation process in an environment where user-level directory services are generally not available, we will (at this time) adopt this certification convention 🧚.

The public component needed to validate certificates signed by RSADSI (in its role as a CA for issuers) is transmitted to each user as part of the registration process. This uses electronic mail with independent, postal confirmation via a message hash 📮. Thus, a user will be able to validate any user certificate (from the RSADSI hierarchy) in at most two steps 🪜. Consider the situation in which a user receives a privacy enhanced message from an originator with whom the recipient has never previously corresponded 👀. Based on the certification convention described above, the recipient can use the RSADSI public component to validate the issuer's certificate contained in the X-Issuer-Certificate field. (We recommend that, initially, the originator include his organization's certificate in this optional field so that the recipient need not access a server or cache for this public component.) Using the issuer's public component (extracted from this certificate), the recipient can validate the originator's certificate contained in the X-Certificate field of the header 💌.

Having performed this certificate validation process, the recipient can extract the originator's public component and use it to decrypt the content of the X-MIC-Info field. That's how they verify the data origin authenticity and integrity of the message 🥰. Of course, implementations of privacy enhanced mail should cache validated public components (acquired from incoming mail or via the message from a user registration process) to speed up this process 🏃‍♀️💨. If a message arrives from an originator whose public component is held in the recipient's cache, the recipient can immediately employ that public component without the need for the certificate validation process described here. Also note that the arithmetic required for certificate validation is considerably faster than that involved in digitally signing a certificate, so as to minimize the computational burden on users 🧠.

A separate issue associated with validation of certificates is a semantic one. Is the entity identified in the issuer field appropriate to vouch for the identifying information in the subject field? This is a topic outside the scope of X.509, but one which must be addressed in any viable system 🤔. The hierarchy proposed in this RFC is designed to address this issue. In most cases, a user will claim, as part of his identifying information, affiliation with some organization, and that organization will have the means and responsibility for verifying this identifying information 🏢. In such circumstances, one should expect an obvious relationship between the Distinguished Name components in the issuer and subject fields 💕.

For example, if the subject field of a certificate identified an individual as affiliated with the "Widget Systems Division" (Organizational Unit Name) of "Compudigicorp" (Organizational Name), one would expect the issuer field to specify "Compudigicorp" as the Organizational Name. If an Organizational Unit Name were present, it should be "Widget Systems Division." 🧩 If the issuer's certificate indicated "Compudigicorp" as the subject (with no Organizational Unit specified), then the issuer should be "RSADSI." If the issuer's certificate indicated "Widget Systems Division" as Organizational Unit and "Compudigicorp" as Organization in the subject field, then the issuer could be either "RSADSI" (due to the direct certification convention described earlier) or "Compudigicorp" (if the organization elected to distribute this intermediate level certificate) 🌈. In the latter case, the certificate path would involve an additional step using the certificate in which "Compudigicorp" is the subject and "RSADSI" is the issuer. One should be suspicious if the validation path does not indicate a subset relationship for the subject and issuer Distinguished Names in the certification path, expect where cross-certification is employed to cross CA boundaries 🚩.

It is a local matter whether the message system presents a human user with the certification path used to validate a certificate associated with incoming, privacy-enhanced mail 📨. A visual display of the Distinguished Names involved in that path is one means of providing the user with the necessary information. We recommend, however, that certificate validation software incorporate checks and alert the user whenever the expected certification path relationships are not present ⚠️. The rationale here is that regular display of certification path data will likely be ignored by users, whereas automated checking with a warning provision is a more effective means of alerting users to possible certification path anomalies 🙈. We urge developers to provide facilities of this sort 🫶💜.

3.4.3 Relation with X.509 Certificate Specification ✨

okay bestie, so an X.509 certificate is basically two components: the contents and an encrypted hash 🔐. The encrypted hash gets made and checked in three steps:

  1. X, the hash, is computed as a function of the certificate contents
  2. the hash is signed by raising X to the power e (modulo n)
  3. the hash's signature is validated by raising the result of step 2 to the power d (modulo n), yielding X, which is compared with the result computed as a function of certificate contents.

Annex C to X.509 suggests using Fermat number F4 (65537 decimal, 1 + 2 **16) as a fixed value for e 💅. This keeps authentication processing relatively efficient, i.e., at most seventeen (17) multiplications are required to effect exponentiation 🧮. As an alternative, you can use three (3) as the value for e, which yields even faster exponentiation 🏎️, but some precautions must be observed (see RFC-1115) ⚠️. Users of the algorithm select values for d (a secret quantity 🤫) and n (a non-secret quantity 🫢) given this fixed value for e.

As noted earlier, this RFC proposes that either three (3) or F4 be employed as universal encryption exponents, with the choice specified in the algorithm identifier 🎀. In particular, use of an exponent value of three (3) for certificate validation is encouraged, to permit rapid certificate validation ⚡.

Given these conventions, a user's public component, and thus the quantity represented in their certificate, is actually the modulus (n) employed in this computation. It's also used in the computations used to protect the DEK and MSGHASH, as described in RFC-1113 🦋. A user's private component is the exponent (d) cited above 🗝️.

The X.509 certificate format is defined (in X.509, Annex G) 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}

All components of this structure are well defined by the ASN.1 syntax in the 1988 X.400 and X.500 Series Recommendations, except for the AlgorithmIdentifier 🙃. An algorithm identifier for RSA is contained in Annex H of X.509, but it's unofficial. RFC-1115 will provide detailed syntax and values for this field 👀💜

NOTES 📚

  • [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".

Authors' Addresses 💌

       Steve Kent
       BBN Communications
       50 Moulton Street
       Cambridge, MA 02138

       Phone: (617) 873-3988

       EMail: kent@BBN.COM


       John Linn
       Secure Systems
       Digital Equipment Corporation
       85 Swanson Road, BXB1-2/D04
       Boxborough, MA  01719-1326

       Phone: 508-264-5491

       EMail: Linn@ultra.enet.dec.com
📦 where this page comes from