RFC 1424

Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services

📅 published February 1993, from ietf

📜 Quick title-block tea: this is RFC 1424 from the Network Working Group, dated February 1993. It was written by B. Kaliski at RSA Laboratories. It's categorized as an IAB standards track protocol. The title block doesn't name any RFC that it obsoletes or updates, so there's no drama there 💅

Status of this Memo ✨

okay so this RFC specifies an IAB standards track protocol for the Internet community 🌈 and it's basically asking for discussion and suggestions for improvements. if you want the official standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards." distribution of this memo is unlimited, so share the tea 💖

Acknowledgements 🫶

this doc came from a ton of discussions at RSA Data Security, at Trusted Information Systems, and on the <pem-dev@tis.com> mailing list. the contributors are Dave Balenson, Jim Bidzos, Pat Cain, Vint Cerf, Pam Cochrane, Steve Dusse, Jeff Fassett, Craig Finseth, Jim Galvin, Mike Indovina, Bob Jueneman, Steve Kent, John Lowry, Paul McKenney, Jeff Thompson, and Charles Wu. it's also the product of the Privacy-Enhanced Electronic Mail Working Group, so the whole group deserves a standing ovation 👑

1. Executive Summary ✨

okay so this document describes three types of service that support Internet Privacy-Enhanced Mail (PEM) [1-3]: key certification 🔐, certificate-revocation list (CRL) storage 📦, and CRL retrieval 📥. these services are among the ones an RFC 1422 [2] certification authority is required to provide. other services, like certificate revocation and certificate retrieval, are left for the certification authority to define, though they may be based on the services in this document 🧚

each service involves an electronic-mail request and an electronic-mail reply 💌. the request is either an RFC 1421 [1] privacy-enhanced message or a message with a new syntax defined in this document. the new syntax follows the general RFC 1421 syntax but has a different process type, which is how it stands out from ordinary privacy-enhanced messages 🦋. the reply is either an RFC 1421 privacy-enhanced message or an ordinary unstructured message.

replies that are privacy-enhanced messages can be processed like any other privacy-enhanced message, so the new certificate or the retrieved CRLs can be inserted into the requestor's database during normal privacy-enhanced mail processing. it's giving seamless 🍓

certification authorities may also require non-electronic forms of request and may return non-electronic replies. descriptions of those forms are outside the scope of this document, but they're expected to be available through a certification authority's "information" service 💅

2. Overview of Services 🌸

this section describes the three services in general terms ✨

the electronic-mail address that requests are sent to is left for the certification authority to specify. certification authorities are expected to advertise their addresses as part of an "information" service. replies go to the address in the "Reply-To:" field of the request, and if that field is omitted, they go to the address in the "From:" field 📮

2.1 Key Certification 🔑

the key-certification service signs a certificate containing a specified subject name and public key. the service takes a certification request (see Section 3.1), signs a certificate built from that request, and returns a certification reply (see Section 3.2) containing the new certificate. main character energy 👑

the certification request specifies the requestor's subject name and public key in the form of a self-signed certificate. the certification request contains two signatures, and both are computed with the requestor's private key:

  1. The signature on the self-signed certificate, which has the cryptographic purpose of preventing a requestor from requesting a certificate with another party's public key. (See Section 4.)
  2. A signature on some encapsulated text, which has the practical purpose of letting the certification authority construct an ordinary RFC 1421 privacy-enhanced message as a reply, with user-friendly encapsulated text. (RFC 1421 doesn't provide for messages with certificates but no encapsulated text, and the self-signed certificate isn't "user friendly" text 🙈) the text should be something innocuous like "Hello world!" 🌈

a requestor would typically send a certification request after generating a public-key/private-key pair, but may also send one after a change in the requestor's distinguished name 💖

a certification authority signs a certificate only if both signatures in the certification request are valid. no exceptions, bestie 🔥

the new certificate contains the subject name and public key from the self-signed certificate, plus an issuer name, serial number, validity period, and signature algorithm chosen by the certification authority. (the validity period may be derived from the self-signed certificate.) following RFC 1422, the issuer may be any authority whose distinguished name is superior to the subject's distinguished name, typically the one closest to the subject 🧚 the certification authority signs the certificate with the issuer's private key, then transforms the request into a reply containing the new certificate (see Section 3.2 for details) ✨

the certification reply includes a certification path from the new certificate to the RFC 1422 Internet certification authority. it may also include other certificates, such as cross-certificates that the certification authority considers helpful to the requestor 🦋

2.2 CRL Storage 📦

the CRL storage service stores CRLs. it takes a CRL-storage request (see Section 3.3) that specifies the CRLs to be stored, stores them, and returns a CRL-storage reply (see Section 3.4) acknowledging the request 💌

the certification authority stores a CRL only if its signature and certification path are valid, following concepts in RFC 1422. (although a certification path is not required in a CRL-storage request, it may help the certification authority validate the CRL 🎀)

2.3 CRL Retrieval 📥

the CRL retrieval service retrieves the latest CRLs of specified certificate issuers. it takes a CRL-retrieval request (see Section 3.5), retrieves the latest CRLs that the request specifies, and returns a CRL-retrieval reply (see Section 3.6) containing those CRLs 🍓

there may be more than one "latest" CRL for a given issuer, if that issuer has more than one public key (see RFC 1422 for details) 🌸

the CRL-retrieval reply includes a certification path from each retrieved CRL to the RFC 1422 Internet certification authority. it may also include other certificates, such as cross-certificates that the certification authority considers helpful to the requestor 💜

3. Syntax 💅

this section describes the syntax of requests and replies for the three services, with simple examples 🧚

3.1 Certification request 💖

a certification request is an RFC 1421 MIC-ONLY or MIC-CLEAR privacy-enhanced message containing a self-signed certificate. there is only one signer 🔐

the fields of the self-signed certificate (which has type Certificate, as in RFC 1422) are as follows:

  • version is 0
  • serialNumber is arbitrary; the value 0 is suggested unless the certification authority specifies otherwise
  • signature is the algorithm by which the self-signed certificate is signed; it need not be the same as the algorithm by which the requested certificate is to be signed
  • issuer is the requestor's distinguished name
  • validity is arbitrary; the value with start and end both at 12:00am GMT, January 1, 1970, is suggested unless the certification authority specifies otherwise
  • subject is the requestor's distinguished name
  • subjectPublicKeyInfo is the requestor's public key

the requestor's MIC encryption algorithm must be asymmetric (e.g., RSA), and the MIC algorithm must be keyless (e.g., RSA-MD2, not MAC), so that anyone can verify the signature 🔥

Example:

To: cert-service@ca.domain
From: requestor@host.domain

-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-ONLY
Content-Domain: RFC822
Originator-Certificate: <requestor's self-signed certificate>
MIC-Info: RSA,RSA-MD2,<requestor's signature on text>

<text>
-----END PRIVACY-ENHANCED MESSAGE-----

3.2 Certification reply 🦋

a certification reply is an RFC 1421 MIC-ONLY or MIC-CLEAR privacy-enhanced message containing a new certificate, its certification path to the RFC 1422 Internet certification authority, and possibly other certificates. there is only one signer 🌈 the "MIC-Info:" field and encapsulated text are taken directly from the certification request. the reply has the same process type (MIC-ONLY or MIC-CLEAR) as the request ✨

since the reply is an ordinary privacy-enhanced message, the new certificate can be inserted into the requestor's database during normal privacy-enhanced mail processing. the requestor can forward the reply to other requestors to spread the certificate around 💌

Example:

To: requestor@host.domain
From: cert-service@ca.domain

-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-ONLY
Content-Domain: RFC822
Originator-Certificate: <requestor's new certificate>
Issuer-Certificate: <issuer's certificate>
MIC-Info: RSA,RSA-MD2,<requestor's signature on text>

<text>
-----END PRIVACY-ENHANCED MESSAGE-----

part 2 picks up with Section 3.3 (CRL-storage request) 🧚💖

3.6. CRL-retrieval reply 🎀

okay so the CRL-retrieval reply is an RFC 1421 CRL-type privacy-enhanced message 💌 and it carries back the CRLs you asked for, their certification paths up to the RFC 1422 Internet certification authority, and maybe some other certificates too 🧚

since it's just a normal privacy-enhanced message, the CRLs can get dropped straight into your database during regular privacy-enhanced mail processing 💅 and you're totally allowed to forward the reply to other requestors so they can get the CRLs too. spreading the love 🫶

Example:

To: requestor@host.domain
From: cert-service@ca.domain

-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,CRL
CRL: <issuer's latest CRL>
Originator-Certificate: <issuer's certificate>
CRL: <other issuer's latest CRL>
Originator-Certificate: <other issuer's certificate>
-----END PRIVACY-ENHANCED MESSAGE-----

Patent Statement 🦋

okay this part is kinda serious bestie 🥺 this version of Privacy Enhanced Mail (PEM) relies on patented public key encryption tech for authentication and encryption. the Internet Standards Process (RFC 1310) says a patent holder has to put in writing that a license will be available to applicants under reasonable terms and conditions before a spec gets approved as a Proposed, Draft or Internet Standard. 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 these US patents, plus all their matching 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 the known ways of doing Public Key encryption, including the variations collectively known as El Gamal 👑

PKP gave the Internet Society written assurance that parties can get the right to use this tech under reasonable, nondiscriminatory terms 🌸 that assurance is written up in RFC 1170, titled "Public Key Standards and Licenses". a copy of the written assurance dated April 20, 1990, can be obtained from the Internet Assigned Number Authority (IANA).

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, nor on whether the terms of the assurance are appropriate. the Internet Society and the other groups above haven't made any determination about any other intellectual property rights that might apply to practicing this standard. any further consideration of these matters is the user's own responsibility 💀

Security Considerations 🔐

okay this is the important bit, so pay attention 🙈 the self-signed certificate (Section 3.1) stops a requestor from asking for a certificate with someone else's public key. that attack would give the requestor the minor ability to pretend to be the originator of any message signed by the other party 😭 and this attack only matters if the requestor doesn't know the message being signed, and the signed part of the message doesn't identify the signer. the requestor still couldn't decrypt messages meant for the other party, obviously 🙅‍♀️

References 📚

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

[2] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management", RFC 1422, BBN, February 1993.

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

Author's Address 💖

Burton S. Kaliski, Jr. RSA Laboratories (a division of RSA Data Security, Inc.) 10 Twin Dolphin Drive Redwood City, CA 94065

Phone: (415) 595-7703 FAX: (415) 595-4126 EMail: burt@rsa.com

📦 where this page comes from