diff options
Diffstat (limited to 'doc/rfc/rfc1424.txt')
| -rw-r--r-- | doc/rfc/rfc1424.txt | 507 |
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc1424.txt b/doc/rfc/rfc1424.txt new file mode 100644 index 0000000..a10c3c4 --- /dev/null +++ b/doc/rfc/rfc1424.txt @@ -0,0 +1,507 @@ + + + + + + +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] +
\ No newline at end of file |