GENWiki

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.

 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 1422, 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 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. 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.

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

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

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

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

 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 disseminate the certificate.

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

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

3.3 CRL-storage request

 A CRL-storage request is an RFC 1421 CRL-type privacy-enhanced
 message containing the CRLs to be stored and optionally their
 certification paths to the RFC 1422 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 1421 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
 issuer's distinguished name. The value is encoded as in an RFC 1421
 "Originator-ID-Asymmetric:" field (i.e., according to the Basic
 Encoding Rules, then in ASCII).

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

 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 1421 CRL-type privacy-enhanced
 message containing retrieved CRLs, their certification paths to the
 RFC 1422 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-----

Patent Statement

 This version of Privacy Enhanced Mail (PEM) relies on the use of
 patented public key encryption technology for authentication and
 encryption.  The Internet Standards Process as defined in RFC 1310
 requires a written statement from the Patent holder that a license
 will be made available to applicants under reasonable terms and
 conditions prior to approving a specification as a Proposed, Draft or
 Internet Standard.

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

 The Massachusetts Institute of Technology and the Board of Trustees
 of the Leland Stanford Junior University have granted Public Key
 Partners (PKP) exclusive sub-licensing rights to the following
 patents issued in the United States, and all of their corresponding
 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

 These patents are stated by PKP to cover all known methods of
 practicing the art of Public Key encryption, including the variations
 collectively known as El Gamal.

 Public Key Partners has provided written assurance to the Internet
 Society that parties will be able to obtain, under reasonable,
 nondiscriminatory terms, the right to use the technology covered by
 these patents.  This assurance is documented in RFC 1170 titled
 "Public Key Standards and Licenses".  A copy of the written assurance
 dated April 20, 1990, may 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 the appropriateness of the terms of
 the assurance.  The Internet Society and other groups mentioned above
 have not made any determination as to any other intellectual property
 rights which may apply to the practice of this standard. Any further
 consideration of these matters is the user's own responsibility.

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
 signed, and the signed part of the message does not identify the
 signer. The requestor would still not be able to decrypt messages

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

 intended for the other party, of course.

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

Kaliski [Page 9]