draft-ietf-pem-forms-01.txt   rfc1424.txt 
Network Working Group B. Kaliski Network Working Group B. Kaliski
INTERNET-DRAFT [FORMS-ID] RSA Laboratories Request for Comments: 1424 RSA Laboratories
1 September 1992 February 1993
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 Privacy Enhancement for Internet Electronic Mail:
months. Internet Drafts may be updated, replaced, or obsoleted by Part IV: Key Certification and Related Services
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 Status of this Memo
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 This RFC specifies an IAB standards track protocol for the Internet
standards document. References within the text of this Internet Draft community, and requests discussion and suggestions for improvements.
to this document as an RFC, or to related Internet Drafts cited as Please refer to the current edition of the "IAB Official Protocol
"RFC [1113+]", "RFC [1114+]", and "RFC [1115+]" are not intended to Standards" for the standardization state and status of this protocol.
carry any connotation about the progression of these Internet Drafts Distribution of this memo is unlimited.
through the IAB standards-track review cycle. Distribution of this
memo is unlimited. Comments should be sent to <pem-dev@tis.com>.
ACKNOWLEDGEMENT Acknowledgements
This document is the product of many discussions at RSA Data This document is the product of many discussions at RSA Data
Security, at Trusted Information Systems, and on the <pem- Security, at Trusted Information Systems, and on the <pem-
dev@tis.com> mailing list. Contributors include Dave Balenson, Jim dev@tis.com> mailing list. Contributors include Dave Balenson, Jim
Bidzos, Pat Cain, Vint Cerf, Pam Cochrane, Steve Dusse, Jeff Fassett, Bidzos, Pat Cain, Vint Cerf, Pam Cochrane, Steve Dusse, Jeff Fassett,
Craig Finseth, Jim Galvin, Mike Indovina, Bob Jueneman, Steve Kent, Craig Finseth, Jim Galvin, Mike Indovina, Bob Jueneman, Steve Kent,
John Lowry, Paul McKenney, Jeff Thompson, and Charles Wu. 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 1. Executive Summary
This document describes three types of service in support of Internet This document describes three types of service in support of Internet
Privacy-Enhanced Mail (PEM) [1-3]: key certification, certificate- Privacy-Enhanced Mail (PEM) [1-3]: key certification, certificate-
revocation list (CRL) storage, and CRL retrieval. Such services are revocation list (CRL) storage, and CRL retrieval. Such services are
among those required of an RFC [1114+] certification authority. Other among those required of an RFC 1422 [2] certification authority.
services such as certificate revocation and certificate retrieval are Other services such as certificate revocation and certificate
left to the certification authority to define, although they may be retrieval are left to the certification authority to define, although
based on the services described in this document. they may be based on the services described in this document.
Each service involves an electronic-mail request and an electronic- Each service involves an electronic-mail request and an electronic-
mail reply. The request is either an RFC [1113+] privacy-enhanced 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 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 new syntax follows the general RFC 1421 syntax but has a different
process type, thereby distinguishing it from ordinary privacy- process type, thereby distinguishing it from ordinary privacy-
enhanced messages. The reply is either an RFC [1113+] privacy- enhanced messages. The reply is either an RFC 1421 privacy-enhanced
enhanced message, or an ordinary unstructured message. message, or an ordinary unstructured message.
Replies that are privacy-enhanced messages can be processed like any Replies that are privacy-enhanced messages can be processed like any
other privacy-enhanced message, so that the new certificate or the other privacy-enhanced message, so that the new certificate or the
retrieved CRLs can be inserted into the requestor's database during retrieved CRLs can be inserted into the requestor's database during
normal privacy-enhanced mail processing. normal privacy-enhanced mail processing.
Certification authorities may also require non-electronic forms of Certification authorities may also require non-electronic forms of
request and may return non-electronic replies. It is expected that request and may return non-electronic replies. It is expected that
descriptions of such forms, which are outside the scope of this descriptions of such forms, which are outside the scope of this
document, will be available through a certification authority's document, will be available through a certification authority's
"information" service. "information" service.
2. Overview of Services 2. Overview of Services
This section describes the three services in general terms. This section describes the three services in general terms.
The electronic-mail address to which requests are sent is left to the The electronic-mail address to which requests are sent is left to the
certification authority to specify. It is expected that certification certification authority to specify. It is expected that certification
authorities will advertise their addresses as part of an authorities will advertise their addresses as part of an
"information" service. Replies are sent to the address in the "Reply- "information" service. Replies are sent to the address in the
To:" field of the request, and if that field is omitted, to the "Reply-To:" field of the request, and if that field is omitted, to
address in the "From:" field. the address in the "From:" field.
2.1 Key Certification 2.1 Key Certification
The key-certification service signs a certificate containing a The key-certification service signs a certificate containing a
specified subject name and public key. The service takes a specified subject name and public key. The service takes a
certification request (see Section 3.1), signs a certificate certification request (see Section 3.1), signs a certificate
constructed from the request, and returns a certification reply (see constructed from the request, and returns a certification reply (see
Section 3.2) containing the new certificate. Section 3.2) containing the new certificate.
The certification request specifies the requestor's subject name and The certification request specifies the requestor's subject name and
skipping to change at page 3, line 14 skipping to change at page 2, line 43
certification request contains two signatures, both computed with the certification request contains two signatures, both computed with the
requestor's private key: requestor's private key:
1. The signature on the self-signed certificate, having the 1. The signature on the self-signed certificate, having the
cryptographic purpose of preventing a requestor from cryptographic purpose of preventing a requestor from
requesting a certificate with another party's public key. requesting a certificate with another party's public key.
(See Section 4.) (See Section 4.)
2. A signature on some encapsulated text, having the 2. A signature on some encapsulated text, having the
practical purpose of allowing the certification authority practical purpose of allowing the certification authority
to construct an ordinary RFC [1113+] privacy-enhanced to construct an ordinary RFC 1421 privacy-enhanced
message as a reply, with user-friendly encapsulated text. message as a reply, with user-friendly encapsulated text.
(RFC [1113+] does not provide for messages with (RFC 1421 does not provide for messages with
certificates but no encapsulated text; and the self- certificates but no encapsulated text; and the self-
signed certificate is not "user friendly" text.) The text signed certificate is not "user friendly" text.) The text
should be something innocuous like "Hello world!" should be something innocuous like "Hello world!"
A requestor would typically send a certification request after A requestor would typically send a certification request after
generating a public-key/private-key pair, but may also do so after a generating a public-key/private-key pair, but may also do so after a
change in the requestor's distinguished name. change in the requestor's distinguished name.
A certification authority signs a certificate only if both signatures A certification authority signs a certificate only if both signatures
in the certification request are valid. in the certification request are valid.
The new certificate contains the subject name and public key from the The new certificate contains the subject name and public key from the
self-signed certificate, and an issuer name, serial number, validity self-signed certificate, and an issuer name, serial number, validity
period, and signature algorithm of the certification authority's period, and signature algorithm of the certification authority's
choice. (The validity period may be derived from the self-signed choice. (The validity period may be derived from the self-signed
certificate.) Following RFC [1114+], the issuer may be any whose certificate.) Following RFC 1422, the issuer may be any whose
distinguished name is superior to the subject's distinguished name, distinguished name is superior to the subject's distinguished name,
typically the one closest to the subject. The certification authority typically the one closest to the subject. The certification authority
signs the certificate with the issuer's private key, then transforms signs the certificate with the issuer's private key, then transforms
the request into a reply containing the new certificate (see Section the request into a reply containing the new certificate (see Section
3.2 for details). 3.2 for details).
The certification reply includes a certification path from the new The certification reply includes a certification path from the new
certificate to the RFC [1114+] Internet certification authority. It certificate to the RFC 1422 Internet certification authority. It may
may also include other certificates such as cross-certificates that also include other certificates such as cross-certificates that the
the certification authority considers helpful to the requestor. certification authority considers helpful to the requestor.
2.2 CRL Storage 2.2 CRL Storage
The CRL storage service stores CRLs. The service takes a 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 request (see Section 3.3) specifying the CRLs to be stored, stores
the CRLs, and returns a CRL-storage reply (see Section 3.4) the CRLs, and returns a CRL-storage reply (see Section 3.4)
acknowledging the request. acknowledging the request.
The certification authority stores a CRL only if its signature and The certification authority stores a CRL only if its signature and
certification path are valid, following concepts in RFC [1114+]. certification path are valid, following concepts in RFC 1422
(Although a certification path is not required in a CRL-storage (Although a certification path is not required in a CRL-storage
request, it may help the certification authority validate the CRL.) request, it may help the certification authority validate the CRL.)
2.3 CRL Retrieval 2.3 CRL Retrieval
The CRL retrieval service retrieves the latest CRLs of specified The CRL retrieval service retrieves the latest CRLs of specified
certificate issuers. The service takes a CRL-retrieval request (see certificate issuers. The service takes a CRL-retrieval request (see
Section 3.5), retrieves the latest CRLs the request specifies, and Section 3.5), retrieves the latest CRLs the request specifies, and
returns a CRL-retrieval reply (see Section 3.6) containing the CRLs. 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 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). issuer has more than one public key (see RFC 1422 for details).
The CRL-retrieval reply includes a certification path from each The CRL-retrieval reply includes a certification path from each
retrieved CRL to the RFC [1114+] Internet certification authority. It retrieved CRL to the RFC 1422 Internet certification authority. It
may also include other certificates such as cross-certificates that may also include other certificates such as cross-certificates that
the certification authority considers helpful to the requestor. the certification authority considers helpful to the requestor.
3. Syntax 3. Syntax
This section describes the syntax of requests and replies for the This section describes the syntax of requests and replies for the
three services, giving simple examples. three services, giving simple examples.
3.1 Certification request 3.1 Certification request
A certification request is an RFC [1113+] MIC-ONLY or MIC-CLEAR A certification request is an RFC 1421 MIC-ONLY or MIC-CLEAR
privacy-enhanced message containing a self-signed certificate. There privacy-enhanced message containing a self-signed certificate. There
is only one signer. is only one signer.
The fields of the self-signed certificate (which has type The fields of the self-signed certificate (which has type
Certificate, as in RFC [1114+]) are as follows: Certificate, as in RFC 1422) are as follows:
version is 0 version is 0
serialNumber is arbitrary; the value 0 is suggested unless the serialNumber is arbitrary; the value 0 is suggested unless the
certification authority specifies otherwise certification authority specifies otherwise
signature is the algorithm by which the self-signed signature is the algorithm by which the self-signed
certificate is signed; it need not be the same as the certificate is signed; it need not be the same as the
algorithm by which the requested certificate is to be algorithm by which the requested certificate is to be
signed signed
skipping to change at page 5, line 32 skipping to change at page 5, line 21
Proc-Type: 4,MIC-ONLY Proc-Type: 4,MIC-ONLY
Content-Domain: RFC822 Content-Domain: RFC822
Originator-Certificate: <requestor's self-signed certificate> Originator-Certificate: <requestor's self-signed certificate>
MIC-Info: RSA,RSA-MD2,<requestor's signature on text> MIC-Info: RSA,RSA-MD2,<requestor's signature on text>
<text> <text>
-----END PRIVACY-ENHANCED MESSAGE----- -----END PRIVACY-ENHANCED MESSAGE-----
3.2 Certification reply 3.2 Certification reply
A certification reply is an RFC [1113+] MIC-ONLY or MIC-CLEAR privacy- A certification reply is an RFC 1421 MIC-ONLY or MIC-CLEAR privacy-
enhanced message containing a new certificate, its certification path enhanced message containing a new certificate, its certification path
to the RFC [1114+] Internet certification authority, and possibly to the RFC 1422 Internet certification authority, and possibly other
other certificates. There is only one signer. The "MIC-Info:" field certificates. There is only one signer. The "MIC-Info:" field and
and encapsulated text are taken directly from the certification encapsulated text are taken directly from the certification request.
request. The reply has the same process type (MIC-ONLY or MIC-CLEAR) The reply has the same process type (MIC-ONLY or MIC-CLEAR) as the
as the request. request.
Since the reply is an ordinary privacy-enhanced message, the new Since the reply is an ordinary privacy-enhanced message, the new
certificate can be inserted into the requestor's database during certificate can be inserted into the requestor's database during
normal privacy-enhanced mail processing. The requestor can forward normal privacy-enhanced mail processing. The requestor can forward
the reply to other requestors to disseminate the certificate. the reply to other requestors to disseminate the certificate.
Example: Example:
To: requestor@host.domain To: requestor@host.domain
From: cert-service@ca.domain From: cert-service@ca.domain
skipping to change at page 6, line 14 skipping to change at page 6, line 7
Content-Domain: RFC822 Content-Domain: RFC822
Originator-Certificate: <requestor's new certificate> Originator-Certificate: <requestor's new certificate>
Issuer-Certificate: <issuer's certificate> Issuer-Certificate: <issuer's certificate>
MIC-Info: RSA,RSA-MD2,<requestor's signature on text> MIC-Info: RSA,RSA-MD2,<requestor's signature on text>
<text> <text>
-----END PRIVACY-ENHANCED MESSAGE----- -----END PRIVACY-ENHANCED MESSAGE-----
3.3 CRL-storage request 3.3 CRL-storage request
A CRL-storage request is an RFC [1113+] CRL-type privacy-enhanced A CRL-storage request is an RFC 1421 CRL-type privacy-enhanced
message containing the CRLs to be stored and optionally their message containing the CRLs to be stored and optionally their
certification paths to the RFC [1114+] Internet certification certification paths to the RFC 1422 Internet certification authority.
authority.
Example: Example:
To: cert-service@ca.domain To: cert-service@ca.domain
From: requestor@host.domain From: requestor@host.domain
-----BEGIN PRIVACY-ENHANCED MESSAGE----- -----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,CRL Proc-Type: 4,CRL
CRL: <CRL to be stored> CRL: <CRL to be stored>
Originator-Certificate: <CRL issuer's certificate> Originator-Certificate: <CRL issuer's certificate>
skipping to change at page 6, line 40 skipping to change at page 6, line 32
-----END PRIVACY-ENHANCED MESSAGE----- -----END PRIVACY-ENHANCED MESSAGE-----
3.4 CRL-storage reply 3.4 CRL-storage reply
A CRL-storage reply is an ordinary message acknowledging the storage A CRL-storage reply is an ordinary message acknowledging the storage
of CRLs. No particular syntax is specified. of CRLs. No particular syntax is specified.
3.5 CRL-retrieval request 3.5 CRL-retrieval request
A CRL-retrieval request is a new type of privacy-enhanced message, A CRL-retrieval request is a new type of privacy-enhanced message,
distinguished from RFC [1113+] privacy-enhanced messages by the distinguished from RFC 1421 privacy-enhanced messages by the process
process type CRL-RETRIEVAL-REQUEST. type CRL-RETRIEVAL-REQUEST.
The request has two or more encapsulated header fields: the required The request has two or more encapsulated header fields: the required
"Proc-Type:" field and one or more "Issuer:" fields. The fields must "Proc-Type:" field and one or more "Issuer:" fields. The fields must
appear in the order just described. There is no encapsulated text, so appear in the order just described. There is no encapsulated text, so
there is no blank line separating the fields from encapsulated text. there is no blank line separating the fields from encapsulated text.
Each "Issuer:" field specifies an issuer whose latest CRL is to be Each "Issuer:" field specifies an issuer whose latest CRL is to be
retrieved. The field contains a value of type Name specifying the retrieved. The field contains a value of type Name specifying the
issuer's distinguished name. The value is encoded as in an RFC issuer's distinguished name. The value is encoded as in an RFC 1421
[1113+] "Originator-ID-Asymmetric:" field (i.e., according to the "Originator-ID-Asymmetric:" field (i.e., according to the Basic
Basic Encoding Rules, then in ASCII). Encoding Rules, then in ASCII).
Example: Example:
To: cert-service@ca.domain To: cert-service@ca.domain
From: requestor@host.domain From: requestor@host.domain
-----BEGIN PRIVACY-ENHANCED MESSAGE----- -----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,CRL-RETRIEVAL-REQUEST Proc-Type: 4,CRL-RETRIEVAL-REQUEST
Issuer: <issuer whose latest CRL is to be retrieved> Issuer: <issuer whose latest CRL is to be retrieved>
Issuer: <another issuer whose latest CRL is to be retrieved> Issuer: <another issuer whose latest CRL is to be retrieved>
-----END PRIVACY-ENHANCED MESSAGE----- -----END PRIVACY-ENHANCED MESSAGE-----
3.6 CRL-retrieval reply 3.6 CRL-retrieval reply
A CRL-retrieval reply is an RFC [1113+] CRL-type privacy-enhanced A CRL-retrieval reply is an RFC 1421 CRL-type privacy-enhanced
message containing retrieved CRLs, their certification paths to the message containing retrieved CRLs, their certification paths to the
RFC [1114+] Internet certification authority, and possibly other RFC 1422 Internet certification authority, and possibly other
certificates. certificates.
Since the reply is an ordinary privacy-enhanced message, the Since the reply is an ordinary privacy-enhanced message, the
retrieved CRLs can be inserted into the requestor's database during retrieved CRLs can be inserted into the requestor's database during
normal privacy-enhanced mail processing. The requestor can forward normal privacy-enhanced mail processing. The requestor can forward
the reply to other requestors to disseminate the CRLs. the reply to other requestors to disseminate the CRLs.
Example: Example:
To: requestor@host.domain To: requestor@host.domain
From: cert-service@ca.domain From: cert-service@ca.domain
-----BEGIN PRIVACY-ENHANCED MESSAGE----- -----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,CRL Proc-Type: 4,CRL
CRL: <issuer's latest CRL> CRL: <issuer's latest CRL>
Originator-Certificate: <issuer's certificate> Originator-Certificate: <issuer's certificate>
CRL: <other issuer's latest CRL> CRL: <other issuer's latest CRL>
Originator-Certificate: <other issuer's certificate> Originator-Certificate: <other issuer's certificate>
-----END PRIVACY-ENHANCED MESSAGE----- -----END PRIVACY-ENHANCED MESSAGE-----
4. Security Considerations 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.
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 The self-signed certificate (Section 3.1) prevents a requestor from
requesting a certificate with another party's public key. Such an requesting a certificate with another party's public key. Such an
attack would give the requestor the minor ability to pretend to be attack would give the requestor the minor ability to pretend to be
the originator of any message signed by the other party. This attack the originator of any message signed by the other party. This attack
is significant only if the requestor does not know the message being is significant only if the requestor does not know the message being
signed, and the signed part of the message does not identify the signed, and the signed part of the message does not identify the
signer. The requestor would still not be able to decrypt messages signer. The requestor would still not be able to decrypt messages
intended for the other party, of course. intended for the other party, of course.
References References
[1] RFC [1113+], Privacy Enhancement for Internet Electronic Mail: [1] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part
Part I: Message Encryption and Authentication Procedures, J. I: Message Encryption and Authentication Procedures", RFC 1421,
Linn, ?, 1992. DEC, February 1993.
[2] RFC [1114+], Privacy Enhancement for Internet Electronic Mail: [2] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part
Part II: Certificate-Based Key Management, S. Kent, ?, 1992. II: Certificate-Based Key Management", RFC 1422, BBN, February
1993.
[3] RFC [1115+], Privacy Enhancement for Internet Electronic Mail: [3] Balenson, D., "Privacy Enhancement for Internet Electronic Mail:
Part III: Algorithms, Modes, and Identifiers, D. Balenson, ?, Part III: Algorithms, Modes, and Identifiers", RFC 1423, TIS,
1992. February 1993.
Author's Address Author's Address
Burton S. Kaliski Jr. Burton S. Kaliski, Jr.
RSA Laboratories (a division of RSA Data Security, Inc.) RSA Laboratories (a division of RSA Data Security, Inc.)
10 Twin Dolphin Drive 10 Twin Dolphin Drive
Redwood City, CA 94065 Redwood City, CA 94065
Phone: (415) 595-7703 Phone: (415) 595-7703
FAX: (415) 595-4126 FAX: (415) 595-4126
EMail: burt@rsa.com EMail: burt@rsa.com
 End of changes. 35 change blocks. 
81 lines changed or deleted 115 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/