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

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 01

Network Working Group                                         B. Kaliski
Request for Comments: 1424                              RSA Laboratories
                                                           February 1993

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

Status of this Memo

   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

Acknowledgements

   This document is the product of many discussions at RSA Data
   Security, at Trusted Information Systems, and on the <pem-
   dev@tis.com> mailing list.  Contributors include 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.  This
   document is the product of the Privacy-Enhanced Electronic Mail
   Working Group.

1. Executive Summary

   This document describes three types of service in support of Internet
   Privacy-Enhanced Mail (PEM) [1-3]: key certification, certificate-
   revocation list (CRL) storage, and CRL retrieval. Such services are
   among those required of an RFC 1422 [2] certification authority.
   Other services such as certificate revocation and certificate
   retrieval are left to the certification authority to define, although
   they may be based on the services described 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, thereby distinguishing it 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 that the new certificate or the
   retrieved CRLs can be inserted into the requestor's database during

Kaliski                                                         [Page 1]
RFC 1424        Key Certification and Related Services     February 1993

   normal privacy-enhanced mail processing.

   Certification authorities may also require non-electronic forms of
   request and may return non-electronic replies. It is expected that
   descriptions of such forms, which are outside the scope of this
   document, will 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 to which requests are sent is left to the
   certification authority to specify. It is expected that certification
   authorities will advertise their addresses as part of an
   "information" service. Replies are sent to the address in the
   "Reply-To:" field of the request, and if that field is omitted, 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
   constructed from the request, and returns a certification reply (see
   Section 3.2) containing the new certificate.

   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, both computed with the
   requestor's private key:

     1.   The signature on the self-signed certificate, having 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, having the
          practical purpose of allowing the certification authority
          to construct an ordinary RFC 1421 privacy-enhanced
          message as a reply, with user-friendly encapsulated text.
          (RFC 1421 does not provide for messages with
          certificates but no encapsulated text; and the self-
          signed certificate is not "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 do so after a

Kaliski                                                         [Page 2]
RFC 1424        Key Certification and Related Services     February 1993

   change in the requestor's distinguished name.