Network Working Group B. Kaliski INTERNET-DRAFT RSA Data Security, Inc. 13 May 1991 Privacy Enhancement for Internet Electronic Mail: Part IV -- Notary, Co-Issuer, CRL-Storing and CRL-Retrieving Services STATUS OF THIS MEMO This draft document will be submitted to the RFC editor as a stan- dards document, and is submitted as a proposed fourth part of the Privacy-Enhanced Mail suite. References within the text of this In- ternet-Draft to this document as an RFC, or to related Internet- Drafts cited as "RFC [1113D]," "RFC [1114B]," and "RFC [1115B]" are not intended to carry any connotation about the progression of this Internet-Draft through the IAB standards-track review cycle. Distri- bution of this memo is unlimited. Comments should be sent to or to the author. This document may be referred to, unofficially, as RFC [FORMS-B]. ACKNOWLEDGEMENT This RFC is the product of many discussions at RSA Data Security, Inc., at Trusted Information Systems, Inc., and on the 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, Charles Wu, and several others. Table of Contents 1. Executive Summary 2 2. Terminology 2 3. Overview 3 4. Notary Service -- pem-notary 4 5. Co-Issuer Service -- pem-co-issuer 6 6. CRL-Storing Service -- pem-crl-archive 10 7. CRL-Retrieving Service -- pem-crl-server 11 8. Other Services -- pem-info and pem-bug-report 13 9. Areas for Further Study 13 10. Security Considerations 13 References 13 Author's Address 14 APPENDIX - Top-Level Certification Authorities 15 Kaliski [Page 1] INTERNET-DRAFT Mail Privacy: Services 13 May 1991 1. Executive Summary This RFC describes four services that top-level certification author- ities (TLCAs) may provide in support of Internet Privacy-Enhanced Mail [1-6]: notary certificate-signing services, co-issuer certifi- cate-signing and certificate revocation list (CRL)-signing services, CRL-storing services, and CRL-retrieving services. The RFC specifies the forms for interacting by electronic mail with TLCAs providing those services. It is intended as a reference for TLCAs and for implementors of privacy-enhanced mail software; it is not at the appropriate level for users, except for the CRL-retrieving service. The RFC also lists TLCAs. Certificate-signing services are provided on behalf of organizations registered with a TLCA and for users not affiliated with registered organizations; CRL-signing services are provided on behalf of regis- tered organizations. CRL-storing and CRL-retrieving services are pro- vided for all users. Registration of organizations, designation of RFC [1114B] organizational notaries, and the paper forms submitted in conjunction with electronic forms are outside the scope of this RFC. Nevertheless, such information should be available from TLCAs through the information service. 2. Terminology Most terms in this RFC are defined in RFCs [1113D], [1114B] and [1115B]. Three new ones are defined. 2.1 Prototype Certificate A prototype certificate has the same syntax as an RFC [1114B] cer- tificate but the following differences in semantics: 1. The outer algorithm identifier (the one in the SIGNED macro) identifies a hash algorithm. The hash algorithm can be based on the issuer's signature algorithm, but it need not be. For example, if the issuer's signature algo- rithm is "rsaWithMD2" then the issuer's hash algorithm can be "md2," but it need not be "md2." 2. The signature (the one in the SIGNED macro) is the hash of the "to-be-signed" field under the outer hash algo- rithm. 2.2 Prototype CRL A prototype CRL has the same syntax as an RFC [1114B] CRL with the differences in semantics outlined for prototype certificates. Kaliski [Page 2] INTERNET-DRAFT Mail Privacy: Services 13 May 1991 2.3 Prototype Privacy-Enhanced Message A prototype privacy-enhanced message is an RFC [1113D] privacy-en- hanced message that contains a prototype certificate or a prototype CRL where a "real" certificate or CRL would go. To be precise, a prototype privacy-enhanced message can have the MIC-CLEAR, MIC-ONLY, or CRL process type, as follows: MIC-CLEAR or MIC-ONLY: For these process types, the privacy- enhanced message should employ asymmetric cryptography; the message-integrity check (MIC) algorithm should be keyless (e.g., RSA-MD2, not MAC) so that the signature on that message can be verified by anyone; and there should be only one originator. The originator's "Certificate:" field should contain the prototype certificate, and there should not be any issuer certificates. CRL: For this process type, there should be one or more "CRL:" fields containing prototype CRLs. There should not be any certificates or issuer certificates. A prototype privacy-enhanced messages is almost "real," in the sense that once the prototype certificate or CRLs it contains are signed, the privacy-enhanced message can be processed in the ordinary way. 3. Overview The key management infrastructure defined in RFC [1114B] in support of Internet Privacy-Enhanced Mail implies that TLCAs support some of the following services: 1. Notary service, or certificate-signing service on behalf of users. The TLCA issues a certificate to a user under the TLCA's NOTARY organizational unit. 2. Co-issuer service, or certificate- and CRL-signing ser- vices on behalf of organizations. The TLCA holds an orga- nization's private key and issues a certificate or a CRL on behalf of the organization, as requested by an organi- zational notary. 3. CRL-storing and CRL-retrieving services. The TLCA stores and retrieves CRLs. A TLCA may choose to support the first service or the second service or both. A TLCA must support the third service as well as bug-report and information services. Support of the third service must cover at least those CRLs signed by the TLCA and by organizations to which the TLCA issues certificates. This RFC gives details on how TLCAs should implement these services. All the services are based on electronic mail, although TLCAs may re- Kaliski [Page 3] INTERNET-DRAFT Mail Privacy: Services 13 May 1991 quire paper forms in addition. Six electronic mail addresses are de- fined: pem-notary: for the notary service pem-co-issuer: for the co-issuer service pem-crl-archive: for the CRL-storing service pem-crl-server: for the CRL-retrieving service pem-bug-report: for bug reports pem-info: for information Replies to service requests are sent to the address identified in the "Reply-To:" field of the request, and if that field is omitted, to the address identified in the "From:" field. 4. Notary Service -- pem-notary The notary service (electronic mail address "pem-notary") signs cer- tificates on behalf of users not affiliated with registered organiza- tions. Notary service can be requested by any user. Such users are issued certificates under the TLCA's NOTARY organizational unit, in accordance with RFC [1114B]. The total process of accessing the notary service can be viewed in three parts: request preparation, request processing, and reply pro- cessing. This section describes those three parts, then gives exam- ples. 4.1 Request Preparation A user prepares a request for notary service by constructing a proto- type MIC-CLEAR or MIC-ONLY privacy-enhanced message with the user as originator, where the privacy-enhanced message contains a prototype certificate that the user wants the notary service to sign. There are three substeps to this step: 1. The user constructs a prototype certificate containing the user's distinguished name, the user's public key and prototype (not necessarily final) information in the other certificate fields. Here the issuer should be the TLCA's NOTARY organizational unit (see RFC [1114B]). This step can be done when the user generates a public- key/private-key pair, or at a later time. 2. The user prepares a prototype MIC-CLEAR or MIC-ONLY pri- vacy-enhanced message containing the prototype certifi- cate, some text, and the user's signature (with the Kaliski [Page 4] INTERNET-DRAFT Mail Privacy: Services 13 May 1991 user's newly generated private key) on the text. Some TLCAs may specify what the text of the message should be; in general, it should be something innocuous like "This is a certificate for ." 3. The user sends the result of step 2 to the notary ser- vice. The notary service may require that the user accompany a request with a paper form or contract, and may require notarization of the form or contract by a notary public or other trusted entity. Such procedures are outside the scope of this RFC, but should be available through the TLCA's information service. 4.2 Request Processing The notary service processes a request by replacing the prototype certificate in the request with a signed version, and adding some certificates. Thus the result of processing is an "ordinary" privacy- enhanced message with the user as originator. There are four substeps to this step: 1. The notary service checks the user's signature on the text of the message. If the signature check is unsuccessful, processing stops. 2. The notary service gives final values to fields of the prototype certificate such as serial number, issuer name, and validity period. The notary service does not change the user's name or the user's public key, however. 3. The notary service signs the revised prototype certifi- cate with the NOTARY organizational unit's private key and replaces the prototype certificate in the user's prototype privacy-enhanced message with the newly signed certificate. The notary service also adds the NOTARY unit's certificate to the message, and possibly some pairs of cross-certificates to expand the audience that can process the resulting message. 4. The notary service sends the result of step 3 to the user (or other party as indicated by the "Reply-To:" address). A separate error report, when necessary, is also sent to this address. The notary service may also send a paper reply to the user. 4.3 Reply Processing The recipient of the reply (typically the user) processes the reply like any other privacy-enhanced message, which results in the newly Kaliski [Page 5] INTERNET-DRAFT Mail Privacy: Services 13 May 1991 signed certificate and the other certificates being inserted into the recipient's database. The recipient can subsequently send the reply to other users as a means of disseminating the new certificate. 4.4 Examples Following are an example request to the notary service, and an example reply. Notice that the user's Originator-ID: field in both the request and the reply omits the issuer name and serial number subfields, since the values of those subfields are implied by the prototype certificate or certificate. Those subfields can be included or omitted, as RFC [1113D] allows. To: pem-notary@tlca.domain From: user@host.domain -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Originator-ID: user@host.domain:: Certificate: MIC-Info: -----END PRIVACY-ENHANCED MESSAGE----- Figure 1. Example request to notary service to sign a certificate. To: user@host.domain From: pem-notary@tlca.domain -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Originator-ID: user@host.domain:: Certificate: Issuer-Certificate: MIC-Info: -----END PRIVACY-ENHANCED MESSAGE----- Figure 2. Example reply from notary service including a newly signed certificate. 5. Co-Issuer Service -- pem-co-issuer The co-issuer service (electronic mail address "pem-co-issuer") signs certificates and CRLs on behalf of registered organizations whose private key the TLCA holds. Co-issuer service can be requested by any organizational notary authorized by the TLCA. A given organizational notary may be authorized to request co-issuer service for more than one organization, and more than one Kaliski [Page 6] INTERNET-DRAFT Mail Privacy: Services 13 May 1991 organizational notary may be authorized to request service for a given organization. The association of organizational notaries with organizations, and how a TLCA manages organizational notaries' authorization, is outside the scope of this RFC. The total process of accessing the co-issuer service can be viewed in three parts: request preparation, request processing, and reply pro- cessing. This section describes those three parts, then gives exam- ples. Note. To avoid ambiguity, an organizational notary is an individual in an organization authorized by that organization and the TLCA to request co-issuer service. The organizational notary is distinct from the TLCA's NOTARY unit. 5.1 Request Preparation An organizational notary prepares a request for co-issuer service by constructing a MIC-CLEAR or MIC-ONLY privacy-enhanced message with the organizational notary as originator, where the text of the pri- vacy-enhanced message contains one or more prototype privacy-enhanced messages. Each prototype privacy-enhanced message contains a prototype certificate or one or more prototype CRLs that the organizational notary wants signed. There are three substeps to this step: 1. The organizational notary constructs, or otherwise ob- tains, one or more prototype privacy-enhanced messages containing prototype certificates and prototype CRLs that are to be signed. Here the prototype certificates and CRLs specify as issuer a registered organization on whose behalf the organizational notary is authorized to request co-issuer service. It is intended that a prototype privacy-enhanced message containing a prototype certificate follow the same conventions as one a user sends to the notary service (Section 4.1). A user's steps, consequently, are essentially the same whether the user is affiliated with a registered organization or not. The primary difference, however, is that the co-issuer service does not change any fields of the prototype certificate, whereas the notary service may. Thus the organizational notary must give final values to fields of the user's prototype certificate. Similarly, the organizational notary must give final values to fields of a prototype CRL. 2. The organizational notary "notarizes" the prototype pri- vacy-enhanced messages by encapsulating them in a MIC- CLEAR or MIC-ONLY privacy-enhanced message, with the or- ganizational notary as originator. Kaliski [Page 7] INTERNET-DRAFT Mail Privacy: Services 13 May 1991 3. The organizational notary sends the result of step 2 to the co-issuer service. 5.2 Request Processing The co-issuer service processes a request by replacing the prototype certificates and CRLs in the request with signed versions, and adding some certificates. The result of processing is one or more privacy- enhanced messages, "back to back." There are four substeps to this step: 1. The co-issuer service checks the organizational notary's signature on the prototype privacy-enhanced message. If the signature check is unsuccessful, processing stops. 2. For each prototype private-enhanced message, the co- issuer service does the following: a. If the prototype privacy-enhanced message contains a prototype certificate, the co-issuer service checks the user's signature on the text of the message. If the signature check is unsuccessful, processing of the particular privacy-enhanced message stops. b. The co-issuer service signs the prototype certificate or CRLs contained in the privacy- enhanced message with the appropriate issuer's private key and replaces the prototype certificate or CRLs in the prototype privacy-enhanced messages with the newly signed certificate or CRLs. The notary service also adds the organization's certificate to the messages, and possibly some pairs of cross-certificates to expand the audience that can process the resulting message. The co-issuer service does not change any fields of a prototype certificate or CRL before signing it. The co-issuer service either signs a prototype certificate or CRL verbatim, or, if any values are erroneous, rejects the particular certificate or CRL. 3. The co-issuer service sends the result of step 2 to the organizational notary (or other party as indicated by "Reply-To:" address.) A separate error report, when nec- essary, is also sent to this address. 4. The co-issuer service sends newly signed CRLs resulting from step 2 to the CRL-storing service described in Section 6.) Kaliski [Page 8] INTERNET-DRAFT Mail Privacy: Services 13 May 1991 5.3 Reply Processing The recipient of the reply (typically the organizational notary) processes the reply like any other set of "back to back" privacy- enhanced messages, which results in the newly signed certificates and CRLs being inserted into the recipient's database. The recipient can subsequently send the reply to other users as a means of disseminating the new certificates and CRLs. 5.4 Examples Following are example requests to the co-issuer service (one to sign a certificate, the other to sign a CRL), and example replies. Notice that the user's Originator-ID: field encapsulated in the request and the reply omits the issuer name and serial number subfields, as in Section 4.4. The organizational notary's Originator-ID: field, on the other hand, includes both subfields, since the organizational notary does not include a certificate. The subfields can be included or omitted, as RFC [1113D] allows. To: pem-co-issuer@tlca.domain From: organizational-notary@host.domain Reply-To: user@host.domain -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Originator-ID: organizational-notary@host.domain: : MIC-Info: - -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Originator-ID: user@host.domain:: Certificate: MIC-Info: - -----END PRIVACY-ENHANCED-MESSAGE----- -----END PRIVACY-ENHANCED MESSAGE----- Figure 3. Example request to co-issuer service to sign a certificate. To: user@host.domain From: pem-co-issuer@tlca.domain -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Originator-ID: user@host.domain:: Certificate: Issuer-Certificate: MIC-Info: Kaliski [Page 9] INTERNET-DRAFT Mail Privacy: Services 13 May 1991 -----END PRIVACY-ENHANCED MESSAGE----- Figure 4. Example reply from co-issuer service, including a newly signed certificate. To: pem-co-issuer@tlca.domain From: organizational-notary@host.domain -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Originator-ID: organizational-notary@host.domain: : MIC-Info: - -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,CRL CRL: - -----END PRIVACY-ENHANCED MESSAGE----- -----END PRIVACY-ENHANCED MESSAGE----- Figure 5. Example request to co-issuer service to sign a CRL. To: organizational-notary@host.domain Cc: pem-crl-archive@tlca.domain From: pem-co-issuer@tlca.domain -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,CRL CRL: Certificate: -----END PRIVACY-ENHANCED MESSAGE----- Figure 6. Example reply from co-issuer service, including a newly signed CRL. 6. CRL-Storing Service -- pem-crl-archive The CRL-storing service (electronic mail address "pem-crl-archive") stores CRLs. CRL-storing service can be requested by any user, al- though it is expected that CRL-storing service will be requested pri- marily by organizational notaries of organizations for which the TLCA is not a co-issuer. The co-issuer service automatically sends newly signed CRLs to the CRL-storing service, so organizational notaries of organizations for which the TLCA is a co-issuer need not use the CRL- storing service directly. The total process of accessing the CRL-storing service can be viewed in two parts: request preparation and request processing. There is no significant reply processing, since a reply is just an acknowledge- ment. This section describes those two parts, then gives an example. Kaliski [Page 10] INTERNET-DRAFT Mail Privacy: Services 13 May 1991 6.1 Request Preparation A user or organizational notary prepares a request for CRL-storing service by constructing a CRL-type privacy-enhanced message, where the privacy-enhanced message contains CRLs that the user or orga- nizational notary wants stored. The user or organizational notary sends the result to the CRL-storing service. 6.2 Request Processing The CRL-storing service stores the CRLs in the request, provided they are valid, and replies with an acknowledgement (or an error report). 6.3 Example Following is an example request to the CRL-storing service and an example reply. To: pem-crl-archive@tlca.domain From: organizational-notary@host.domain -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,CRL CRL: -----END PRIVACY-ENHANCED MESSAGE----- Figure 7. Example request to CRL-storing service to store a CRL. To: organizational-notary@host.domain From: pem-crl-archive@tlca.domain Your request to store a CRL for organizationalUnitName=Widgets Division, XYZ Inc., US has been processed successfully. Figure 8. Example reply from CRL-storing service. 7. CRL-Retrieving Service -- pem-crl-server The CRL-retrieving service (electronic mail address "pem-crl-server") retrieves CRLs. CRL-retrieving service can be requested by any user. A side-effect of this service is that current cross-certificate pairs, and relevant current CRLs other than those requested, are made available. The total process of accessing the CRL-retrieving service can be viewed in three parts: request preparation, request processing, and Kaliski [Page 11] INTERNET-DRAFT Mail Privacy: Services 13 May 1991 reply processing. This section describes those three parts, then gives examples. 7.1 Request Preparation A user prepares a request for CRL-retrieving service by constructing a message that contains distinguished names of one or more issuers, separated by blank lines. The names are represented according to the User-Friendly Name syntax [7]. The names identify the issuers whose latest CRLs the user wants. 7.2 Request Processing The CRL-retrieving service processes a request by replacing the is- suer distinguished names in the request with the latest CRLs for the issuers, and adding some certificates. The result of processing is a CRL-type privacy-enhanced message containing one or more CRLs. The CRL-retrieving service also adds the requested issuers' certificates, possibly some pairs of cross-certificates, and other relevant CRLs to expand the audience that can process the resulting message. The CRL-retrieving service sends a separate error report if necessary. 7.3 Reply Processing The recipient of the reply processes the reply like any other CRL- type privacy-enhanced message, which results in the CRLs being inserted into the recipient's database. The recipient can subsequently send the reply to other users as a means of disseminating the CRLs. 7.4 Examples Following are an example request and an example reply. The request is for the latest CRLs issued by RSA Data Security, Inc.'s TLCA and NO- TARY organizational units. To: pem-crl-server@tlca.domain From: user@host.domain organizationalUnitName=TLCA, "RSA Data Security, Inc.", US organizationalUnitName=NOTARY, "RSA Data Security, Inc.", US Figure 9. Example request to CRL-retrieving service to retrieve two CRLs. To: user@host.domain From: pem-crl-server@tlca.domain Kaliski [Page 12] INTERNET-DRAFT Mail Privacy: Services 13 May 1991 -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,CRL CRL: CRL: Certificate: -----END PRIVACY-ENHANCED MESSAGE----- Figure 10. Example reply from CRL-retrieving service, including two CRLs. 8. Other Services -- pem-info and pem-bug-report The information service (electronic mail address: pem-info) provides information about the TLCA's services, and the bug-report service (electronic mail address: pem-bug-report) receives reports on bugs in the services. 9. Areas for Further Study One important area for further study is what services are needed for certifying organizations for which the TLCA is not a co-issuer (in particular, other TLCAs). 10. Security Considerations Some of the services described in this memo rely on the security of Privacy-Enhanced Mail. In particular, the co-issuer service relies on the trustworthiness of Privacy-Enhanced Mail purportedly signed by an organizational notary. References [1] Linn, J., Privacy Enhancement for Internet Electronic Mail: Part I -- Message Encipherment and Authentication Procedures (RFC 1113), August 1989. [2] Kent, S., and J. Linn, Privacy Enhancement for Internet Electronic Mail: Part II -- Certificate-Based Key Manage- ment (RFC 1114), August 1989. [3] Linn, J., Privacy Enhancement for Internet Electronic Mail: Part III -- Algorithms, Modes, and Identifiers (RFC 1115), August 1989. [4] Linn, J., Privacy Enhancement for Internet Electronic Mail: Part I -- Message Encryption and Authentication Procedures (RFC [1113D]), March 1991. Kaliski [Page 13] INTERNET-DRAFT Mail Privacy: Services 13 May 1991 [5] Kent, S., Privacy Enhancement for Internet Electronic Mail: Part II -- Certificate-Based Key Management (RFC [1114B]), February 1991. [6] Balenson, D., Privacy Enhancement for Internet Electronic Mail: Part III -- Algorithms, Modes, and Identifiers (RFC [1115B]), February 1991. [7] Kille, S.E., Using the OSI Directory to Achieve User Friendly Naming (Internet Draft), January 1991. Author's Address Burton S. Kaliski Jr. RSA Data Security, Inc. 10 Twin Dolphin Drive Redwood City, CA 94065 Phone: (415) 595-8782 FAX: (415) 595-1873 EMail: kaliski@rsa.com Kaliski [Page 14] INTERNET-DRAFT Mail Privacy: Services 13 May 1991 APPENDIX - Top-Level Certification Authorities This appendix lists TLCAs providing services described in this RFC. A.1 RSA Data Security, Inc. RSA Data Security, Inc. provides all six services described in this document ("pem-notary," "pem-co-issuer," "pem-crl-archive," "pem-crl- server," "pem-info," and "pem-bug-report") at the host "rsa.com." For more information, including organizational contracts and paper re- quest forms, write or call: RSA Data Security, Inc. 10 Twin Dolphin Drive Redwood City, CA 94065 Phone: (415) 595-8782 FAX: (415) 595-1873 EMail: pem-info@rsa.com RSA Data Security, Inc. has both TLCA and NOTARY organizational units. They are: organizationalUnitName=TLCA, "RSA Data Security, Inc.", US and organizationalUnitName=NOTARY, "RSA Data Security, Inc.", US Their public keys, respectively, are: (to be supplied) and (to be supplied) As of this writing, these services are NOT YET ACTIVE. Kaliski [Page 15]