Attached is a revised draft of the "RFC [FORMS]" document now titled
"Key Certification and Related Services." This is the fourth part of
the PEM suite. The draft will be submitted as an Internet-Draft
shortly, and comments are welcome.
This document describes three types of service in support of Internet
Privacy-Enhanced Mail: key certification, certificate-revocation
list (CRL) storage, and CRL retrieval. Such services are among those
required of an RFC [1114F] certification authority.
The document has the following substantive changes from earlier
drafts:
1. "Notary" and "co-issuer" certificate-signing services are removed,
since they are a policy certification authority (PCA) matter.
2. "Prototype certificates" (certificates with a digest in place of a
signature) are replaced with a simple type consisting of the
requestor's distinguished name, public key, and signature on the
two. "Prototype certificates" were a carryover from the "co-issuer"
service. With that service removed, the simpler type is sufficient.
The signature on the name and public key prevents a requestor from
requesting a certificate with another party's public key.
3. CRLs to be retrieved are identified by an issuer name encoded in
printable ASCII (as in RFC [1113E] messages), rather than a
"user-friendly name," to simplify implementation. (No other part of
the PEM suite supports "user-friendly names.")
4. Syntax for the requests and replies generally follows RFC [1113F],
with the introduction of two new process types, "CERT-REQUEST" and
"CRL-RETRIEVAL-REQUEST."
-- Burt Kaliski
------------------------------------------------------------------------
Network Working Group B. Kaliski
INTERNET-DRAFT [FORMS-D] RSA Laboratories
7 April 1992
Privacy Enhancement for Internet Electronic Mail:
Part IV: Key Certification and Related Services
STATUS OF THIS MEMO
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 [1113E]", "RFC [1114F]", and "RFC [1115C]" 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(_at_)tis(_dot_)com>.
ACKNOWLEDGEMENT
This document is the product of many discussions at RSA Data
Security, at Trusted Information Systems, and on the <pem-
dev(_at_)tis(_dot_)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.
Table of Contents
1. Executive Summary 1
2. Overview of Services 2
3. Syntax 4
4. Security Considerations 7
References 7
Author's Address 7
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 [1114F] 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 reply is either an RFC [1113E] privacy-enhanced
Kaliski [Page 1]
INTERNET-DRAFT Key Certification and Related Services 7 April 1992
message, or an ordinary unstructured message. The request is either
an RFC [1113E] privacy-enhanced message or a message with a new
syntax defined in this document. The new syntax follows the general
RFC [1113E] syntax but has a different process type, thereby
distinguishing it from ordinary privacy-enhanced messages.
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 policy 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 a RFC [1114F]
policy certification authority's "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 request specifies the requestor's subject name and public key,
and also contains two signatures, both computed with the requestor's
private key:
1. A signature on the subject name and public key, 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 [1113E] privacy-enhanced
message as a reply, with user-friendly encapsulated text.
(RFC [1113E] does not provide for messages with
Kaliski [Page 2]
INTERNET-DRAFT Key Certification and Related Services 7 April 1992
certificates but no encapsulated text; and the subject
name/public key combination is not "user friendly.") 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.
The certificate should contain the subject name and public key from
the certification request, and an issuer name, serial number,
validity period, and signature algorithm of the certification
authority's choice. Following RFC [1114F], 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 should include a certification path from the
new certificate to the RFC [1114F] 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 should store a CRL only if its signature
and certification path are valid, following concepts in RFC [1114F].
(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 [1114F] for details).
The CRL-retrieval reply should include a certification path from each
retrieved CRL to the RFC [1114F] 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]
INTERNET-DRAFT Key Certification and Related Services 7 April 1992
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 a new type of privacy-enhanced message,
distinguished from RFC [1113E] privacy-enhanced messages by the
process type "CERT-REQUEST".
The request has three encapsulated header fields: the required "Proc-
Type:" field, a "Cert-Request:" field, and an RFC [1113E] "MIC-Info:"
field. The fields must appear in the order just described. As in RFC
[1113E], a blank line separates the fields from encapsulated text.
The encapsulated text is encoded as for RFC [1113E] "MIC-ONLY"
messages, i.e., there is no support for "MIC-CLEAR".
The "Cert-Request:" field contains a value of type
CertificationRequest specifying the requestor's distinguished name
and public key:
CertificationRequest ::= SIGNED SEQUENCE {
version INTEGER, -- 0 for this version
subject Name, -- requestor's distinguished name
subjectPublicKeyInfo SubjectPublicKeyInfo -- requestor's public key
}
The value is encoded as a certificate is in an RFC [1113E]
"Originator-Certificate:" field (i.e., according to the Basic
Encoding Rules, then in ASCII).
The "MIC-Info:" field contains the requestor's signature on the
encapsulated text. 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(_at_)ca(_dot_)domain
From: requestor(_at_)host(_dot_)domain
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,CERT-REQUEST
Cert-Request: <requestor's name and public key, signed by requestor>
MIC-Info: RSA,RSA-MD2,<requestor's signature on text>
<text>
-----END PRIVACY-ENHANCED MESSAGE-----
Kaliski [Page 4]
INTERNET-DRAFT Key Certification and Related Services 7 April 1992
3.2 Certification reply
A certification reply is an RFC [1113E] MIC-ONLY privacy-enhanced
message containing a new certificate, its certification path to the
RFC [1114F] 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.
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(_at_)host(_dot_)domain
From: cert-service(_at_)ca(_dot_)domain
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-ONLY
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 [1113E] CRL-type privacy-enhanced
message containing the CRLs to be stored and optionally their
certification paths to the RFC [1114F] Internet certification
authority.
Example:
To: cert-service(_at_)ca(_dot_)domain
From: requestor(_at_)host(_dot_)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-----
Kaliski [Page 5]
INTERNET-DRAFT Key Certification and Related Services 7 April 1992
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 [1113E] 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
[1113E] "Originator-ID-Asymmetric:" field (i.e., according to the
Basic Encoding Rules, then in ASCII).
Example:
To: cert-service(_at_)ca(_dot_)domain
From: requestor(_at_)host(_dot_)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 [1113E] CRL-type privacy-enhanced
message containing retrieved CRLs, their certification paths to the
RFC [1114F] 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(_at_)host(_dot_)domain
From: cert-service(_at_)ca(_dot_)domain
Kaliski [Page 6]
INTERNET-DRAFT Key Certification and Related Services 7 April 1992
-----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 signature on the subject name and public key in a certification
request (Sections 2.1 and 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 intended for
the other party, of course.
References
[1] RFC [1113E], Privacy Enhancement for Internet Electronic Mail:
Part I: Message Encryption and Authentication Procedures, J.
Linn, ?, 1992.
[2] RFC [1114F], Privacy Enhancement for Internet Electronic Mail:
Part II: Certificate-Based Key Management, S. Kent, ?, 1992.
[3] RFC [1115C], 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-8782
FAX: (415) 595-4126
EMail: burt(_at_)rsa(_dot_)com
Kaliski [Page 7]