Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services
RFC 1424
Document | Type |
RFC - Historic
(February 1993; No errata)
Was draft-ietf-pem-forms (pem WG)
|
|
---|---|---|---|
Author | Burt Kaliski | ||
Last updated | 2013-03-02 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 1424 (Historic) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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.Show full document text