Skip to main content

Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services
draft-ietf-pem-forms-01

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 1424.
Author Burt Kaliski
Last updated 2013-03-02 (Latest revision 1992-09-01)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Additional resources pem-dev-request%40tis.com
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 1424 (Historic)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-pem-forms-01
Network Working Group                                         B. Kaliski
INTERNET-DRAFT [FORMS-ID]                               RSA Laboratories
                                                        1 September 1992

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

STATUS OF THIS MEMO

   This document is an Internet Draft. Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups. Note that other groups may also distribute
   working documents as Internet Drafts.
   
   Internet Drafts are draft documents valid for a maximum of six
   months. Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time. It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress."
   
   Please check the I-D abstract listing contained in each Internet
   Draft directory to learn the current status of this or any other
   Internet Draft.
   
   This draft document will be submitted to the RFC editor as a
   standards document. References within the text of this Internet Draft
   to this document as an RFC, or to related Internet Drafts cited as
   "RFC [1113+]", "RFC [1114+]", and "RFC [1115+]" are not intended to
   carry any connotation about the progression of these Internet Drafts
   through the IAB standards-track review cycle. Distribution of this
   memo is unlimited. Comments should be sent to <pem-dev@tis.com>.
   

ACKNOWLEDGEMENT

   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.
   

1. Executive Summary

   This document describes three types of service in support of Internet
   Privacy-Enhanced Mail (PEM) [1-3]: key certification, certificate-

Kaliski            Document Expiration: 1 March 1993            [Page 1]
Internet-Draft   Key Certification and Related Services 1 September 1992

   revocation list (CRL) storage, and CRL retrieval. Such services are
   among those required of an RFC [1114+] 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 [1113+] privacy-enhanced
   message or a message with a new syntax defined in this document. The
   new syntax follows the general RFC [1113+] syntax but has a different
   process type, thereby distinguishing it from ordinary privacy-
   enhanced messages. The reply is either an RFC [1113+] 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
   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

Kaliski            Document Expiration: 1 March 1993            [Page 2]
Internet-Draft   Key Certification and Related Services 1 September 1992

   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 [1113+] privacy-enhanced
          message as a reply, with user-friendly encapsulated text.
          (RFC [1113+] 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
   change in the requestor's distinguished name.
   
   A certification authority signs a certificate only if both signatures
   in the certification request are valid.
   
   The new certificate contains the subject name and public key from the
   self-signed certificate, and an issuer name, serial number, validity
   period, and signature algorithm of the certification authority's
   choice. (The validity period may be derived from the self-signed
   certificate.) Following RFC [1114+], the issuer may be any 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 [1114+] 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. The service takes a CRL-storage
   request (see Section 3.3) specifying the CRLs to be stored, stores
   the CRLs, and returns a CRL-storage reply (see Section 3.4)
   acknowledging the request.
   

Kaliski            Document Expiration: 1 March 1993            [Page 3]
Internet-Draft   Key Certification and Related Services 1 September 1992

   The certification authority stores a CRL only if its signature and
   certification path are valid, following concepts in RFC [1114+].
   (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. The service takes a CRL-retrieval request (see
   Section 3.5), retrieves the latest CRLs the request specifies, and
   returns a CRL-retrieval reply (see Section 3.6) containing the CRLs.
   
   There may be more than one "latest" CRL for a given issuer, if that
   issuer has more than one public key (see RFC [1114+] for details).
   
   The CRL-retrieval reply includes a certification path from each
   retrieved CRL to the RFC [1114+] 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, giving simple examples.
   

3.1 Certification request

   A certification request is an RFC [1113+] 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 [1114+]) 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

Kaliski            Document Expiration: 1 March 1993            [Page 4]
Internet-Draft   Key Certification and Related Services 1 September 1992

     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 [1113+] MIC-ONLY or MIC-CLEAR privacy-
   enhanced message containing a new certificate, its certification path
   to the RFC [1114+] 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 disseminate the certificate.
   
   Example:
   
   To: requestor@host.domain
   From: cert-service@ca.domain
   
   -----BEGIN PRIVACY-ENHANCED MESSAGE-----
   Proc-Type: 4,MIC-ONLY

Kaliski            Document Expiration: 1 March 1993            [Page 5]
Internet-Draft   Key Certification and Related Services 1 September 1992

   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-----
   

3.3 CRL-storage request

   A CRL-storage request is an RFC [1113+] CRL-type privacy-enhanced
   message containing the CRLs to be stored and optionally their
   certification paths to the RFC [1114+] Internet certification
   authority.
   
   Example:
   
   To: cert-service@ca.domain
   From: requestor@host.domain
   
   -----BEGIN PRIVACY-ENHANCED MESSAGE-----
   Proc-Type: 4,CRL
   CRL: <CRL to be stored>
   Originator-Certificate: <CRL issuer's certificate>
   CRL: <another CRL to be stored>
   Originator-Certificate: <other CRL issuer's certificate>
   -----END PRIVACY-ENHANCED MESSAGE-----
   

3.4 CRL-storage reply

   A CRL-storage reply is an ordinary message acknowledging the storage
   of CRLs. No particular syntax is specified.
   

3.5 CRL-retrieval request

   A CRL-retrieval request is a new type of privacy-enhanced message,
   distinguished from RFC [1113+] privacy-enhanced messages by the
   process type CRL-RETRIEVAL-REQUEST.
   
   The request has two or more encapsulated header fields: the required
   "Proc-Type:" field and one or more "Issuer:" fields. The fields must
   appear in the order just described. There is no encapsulated text, so
   there is no blank line separating the fields from encapsulated text.
   
   Each "Issuer:" field specifies an issuer whose latest CRL is to be
   retrieved. The field contains a value of type Name specifying the

Kaliski            Document Expiration: 1 March 1993            [Page 6]
Internet-Draft   Key Certification and Related Services 1 September 1992

   issuer's distinguished name. The value is encoded as in an RFC
   [1113+] "Originator-ID-Asymmetric:" field (i.e., according to the
   Basic Encoding Rules, then in ASCII).
   
   Example:
   
   To: cert-service@ca.domain
   From: requestor@host.domain
   
   -----BEGIN PRIVACY-ENHANCED MESSAGE-----
   Proc-Type: 4,CRL-RETRIEVAL-REQUEST
   Issuer: <issuer whose latest CRL is to be retrieved>
   Issuer: <another issuer whose latest CRL is to be retrieved>
   -----END PRIVACY-ENHANCED MESSAGE-----
   

3.6 CRL-retrieval reply

   A CRL-retrieval reply is an RFC [1113+] CRL-type privacy-enhanced
   message containing retrieved CRLs, their certification paths to the
   RFC [1114+] Internet certification authority, and possibly other
   certificates.
   
   Since the reply is an ordinary privacy-enhanced message, the
   retrieved CRLs can be inserted into the requestor's database during
   normal privacy-enhanced mail processing. The requestor can forward
   the reply to other requestors to disseminate the CRLs.
   
   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-----
   

4. Security Considerations

   The self-signed certificate (Section 3.1) prevents a requestor from
   requesting a certificate with another party's public key. Such an
   attack would give the requestor the minor ability to pretend to be
   the originator of any message signed by the other party. This attack
   is significant only if the requestor does not know the message being

Kaliski            Document Expiration: 1 March 1993            [Page 7]
Internet-Draft   Key Certification and Related Services 1 September 1992

   signed, and the signed part of the message does not identify the
   signer. The requestor would still not be able to decrypt messages
   intended for the other party, of course.
   

References

     [1]  RFC [1113+], Privacy Enhancement for Internet Electronic Mail:
          Part I: Message Encryption and Authentication Procedures, J.
          Linn, ?, 1992.
          
     [2]  RFC [1114+], Privacy Enhancement for Internet Electronic Mail:
          Part II: Certificate-Based Key Management, S. Kent, ?, 1992.
          
     [3]  RFC [1115+], Privacy Enhancement for Internet Electronic Mail:
          Part III: Algorithms, Modes, and Identifiers, D. Balenson, ?,
          1992.
          

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