[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 rfc2797                                     
SMIME Working Group                            Michael Myers (VeriSign)
Internet Draft                                    Xiaoyi Liu (Cisco)
                                                 Barbara Fox (Microsoft)
                                              Jeff Weinstein (Netscape)

expires in six months                                     March 1998


                  Certificate Management Messages over CMS
                      <draft-ietf-pkix-cmc-00.txt>

1. 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.  Not that other groups MAY also distribut working
documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and MAY be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Di-
rectories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munari.oz.au
Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West
Coast).

2. Abstract

This document defines the means by which PKI clients and servers may
exchange PKI messages when using the Cryptographic Message Syntax [CMS]
as a transaction envelope.  It extends concepts established in the draft
[CRS] version of this material by accommodating external specification
of message bodies in the Certificate Management Message Formats [CMMF]
and Certificate Request Message Format [CRMF] documents.  Mandatory
requirements are established which facilitate automated interoperability
between a wide variety of PKI clients and servers or services.  Optional
features are defined to address more localized needs.

This draft is being discussed on the ''ietf-pkix'' mailing list. To
subscribe, send a message to ietf-pkix-request@tandem.com with the
single word “subscribe” in the body of the message.

3. Protocol Overview

A new CMS content type, PKIData, is defined within the more general CMS
security encapsulation framework.  CMMF message bodies secured by CMS
are encapsulated within the PKIData content type.  PKIData is in turn
ultimately encapsulated by a SignedData envelope.  The
authenticatedAttributes element of SignedData is used to carry
information useful to recipient processing of CMS-encapsulated CMMF
message bodies.  These are collectively referred to as “Service
Indicators”.

Myers, Liu, Fox, Weinstein                                      Page 1

INTERNET DRAFT                                                March 1998

Two such indicators are MessageType (an attribute unique to this
specification) and ContentType (defined by [CMS]).

Processing systems, whether client or server:

1)  Detect the presence of PKIData by examination of ContentType;
2)  Examine the value of MessageType;
3)  Locate the PKIData construct within the CMS message;
4)  Parse the content of PKIData in accordance with MessageType; and
5)  Take action as appropriate to the message body content.

Successful processing  of the message may depend in part upon other
authenticated attributes within the SignedData envelope.

3.1 Transactions

A transaction is composed of the exchange of request-response message
pairs between a server and a client.  This document establishes
requirements on four such transactions.  These are:

1.  Certification of a public key;
2.  Query on status of certificate request;
3.  Certificate and CRL retrieval;
4.  Certificate revocation.

A public key certification request is formed either as a PKCSReq object
or CRMF; the [CMMF] document identifies both.  PKCSReq enables use of
PKCS10-based certificate requests while CRMF anticipates a richer set of
requirements than can be met by PKCS10.  The corresponding response is
either by CertResponse or CertRepContent as defined in CMMF.  The
CertResponse message body incorporates the familiar PKCS7 degenerate
signedData mode of certificate delivery while CertRepContent provides
equivalent capability and enables CA generation of subscriber key pairs.

The certificate and CRL retrieval request mechanism is used to assist
state recovery within resource-constrained PKI clients.  This may be the
case, for example, within low-end IP routers implementing IPSEC which by
reasons of design do not retain such data in non-volatile memory.

The certificate request status query can be used as a simple means to
maintain synchronicity with a certificate server during the certificate
production process.  This message would typically be used in a situation
where the certificate requesting system holds itself in a wait state
during the processing of certificate request.

The revocation request transaction enables programmatic processing of
revocation requests.  It further provides for non-cryptographic
authentication of the requester in the event that the key being revoked
would otherwise be relied upon to authenticate the originator of a
revocation message.  This capability is useful in the event of a key
compromise.

3.2 PKIData


Myers, Liu, Fox, Weinstein                                      Page 2

INTERNET DRAFT                                                March 1998

PKIData is an inner-most content type used to encapsulate CMMF message
bodies. PKIData is used with SignedData to define a transaction-based
protocol.  EnvelopedData may be used in conjunction with SignedData to
provide privacy. The following figure illustrates the relationship
between PKIData and SignedData in the case of an unencrypted message
(section 4.3 discusses encryption options):

|---------------------------------------|
|SIGNED DATA                            |
|    -----------------------------------|
|    |PKIData                           |
|    |   message body                   | - as defined in CMMF
|---------------------------------------|
|    ORIGINATOR'S CERTIFICATES          |
|---------------------------------------|
|    AUTHENTICATED ATTRIBUTES           | - service indicators
|        Hash of Content                |
|        content type                   | - identifies PKIData
|        version                        | - version number
|        message type                   | - indicates msg body syntax
|        transaction status             | - general status
|        failure info                   | - failure context
|        transaction identifier         | - optional
|        sender nonce                   | - optional
|        recipient nonce                | - optional
|---------------------------------------|
|    Message Signature                  | - produced by originator
|---------------------------------------|


Section 3 of [CMS] establishes the following general syntax for CMS
content types:

ContentInfo ::= SEQUENCE {
        contentType ContentType,
        content [0] EXPLICIT ANY DEFINED BY contentType }

ContentType ::= OBJECT IDENTIFIER

The PKIData content type can be recognized using the following OID:

id-pkiData OBJECT IDENTIFER ::= id-pkix-crs  -- defined in [PKIXCERT]

The specific syntax contained within a PKIData is indicated by the
MessageType attribute in an encapsulated SignedData content type.

Transactions can be identified and tracked using a transaction
identifier.  If used, clients generate transaction identifiers and
retain their value until the server responds with a message that
completes the transaction. Servers correspondingly include received
transaction identifiers in the response.  Section 5.5 establishes
requirements on the use of TransactionID.



Myers, Liu, Fox, Weinstein                                      Page 3

INTERNET DRAFT                                                March 1998

Replay protection is supported through the use of sender and recipient
nonces.  If used, clients generate a nonce value and include it in the
request as a sender nonce.  Servers return this value as recipient nonce
along their own value for sender nonce.

This specification makes no assumptions about the underlying transport
mechanism.  The use of CMS is not meant to imply an email-based
transport.

Requests and responses are composed of a message body and one or more
Service Indicators. Service Indicators are encoded as a set of
authenticated attributes of a CMS SignedData construction.  The message
digest of message body is then signed together with the Service
Indicators using the message originator's private signing key, producing
the message signature.

4. Protocol Requirements

4.1 PKCS7 Interoperability

CMS differs from PKCS7 in that it:

- adds to EnvelopedData an OPTIONAL originatorInfo field preceding
  recipientInfo;
- replaces the issuerAndSerial field of recipientInfos with a CHOICE
  of alternative recipient key identification mechanisms.

Clients MAY include the optional OriginatorInfo field of the CMS
EnvelopedData syntax when submitting PKI transaction requests.  If the
intended recipient is unable to receive this optional syntax, an error
response message SHALL be generated per Section 4.3.1.

Clients SHALL be capable of receiving and servers SHALL be capable of
processing the issuerAndSerialNumber CHOICE of the rid (recipient
identifer) syntax for RecipientInfos. The corresponding
RecipientKeyIdentifier and  MailListKeyIdentifier are optional within
this specification.

As noted in [CMS], if either RecipientKeyIdentifier or
MailListKeyIdentifier are used, the value for version in EnvelopedData
SHALL be 2; if issuerAndSerialNumber CHOICE is used, the value for
version SHALL be 0.

The specification of CMS ensures that EnvelopedData productions with a
version of 0 will successfully interoperate with systems implemented in
accordance with PKCS7.

4.2 Mandatory and Optional Algorithms

Clients and servers SHALL be capable of producing and processing
message signatures using the Digital Signature Algorithm [DSA].  DSA
signatures SHALL be indicated by the DSA AlgorithmIdentifier value
specified in section 7.2.2 of PKIXCERT.  Clients and servers SHOULD


Myers, Liu, Fox, Weinstein                                      Page 4

INTERNET DRAFT                                                March 1998

also be capable of producing and processing RSA signatures as specified
in section 7.2.1 of PKIXCERT.

Clients and servers SHALL be capable of protecting and accessing
message encryption keys using the Diffie-Hellman (D-H) key exchange
algorithm.  D-H protection SHALL be indicated by the D-H
AlgorithmIdentifier value specified in CMS.  Clients and servers
SHOULD also be capable of producing and processing RSA key transport.
When used for PKI messages, RSA key transport SHALL be indicated as
specified in section 7.2.1 of PKIXCERT.

4.3 Use of EnvelopedData

Two options exist with respect to the use of EnvelopedData.  One usage
produces an encrypted message body encapsulated by SignedData.  The
other option is the inverse of this relationship, as the following
figure illustrates.

Option 1                         Option 2
--------                         --------
SignedData                       EnvelopedData
   EnvelopedData                    SignedData
      PKIData                          PKIData
         <PKI message body>               <PKI message body>


The second option benefits organizations that wish to protect against
the leakage of sensitive data via the cleartext SignedData envelope.

Message bodies MAY be encrypted or transmitted in the clear.  Support
SHALL be provided for encryption option 1 and SHOULD be provided for
both.

4.4 Requirements on Message Construction

The exact processing sequence used to construct a message could vary by
application.  The results SHALL however be structurally equivalent to
the following procedure:

A [CMMF] message body is constructed in accordance with this
specification and any additional requirements asserted in [CMMF]
regarding a given message body.  This message body is then enveloped as
id-pKIData as defined in section 4.3, yielding PKIData.

If PKIData is to be encrypted, then either an EnvelopedData content type
is constructed which contains the PKIData--which is in turn enveloped by
SignedData as an outermost CMS envelope--or a SignedData content type is
constructed which is subsequently encapsulated by EnvelopedData as the
outermost CMS envelope.  The decision on which to use is optional to the
implementor, although section 5.3 establishes the requirement that all
implementors shall at least enable the former (i.e. SignedData <-
Enveloped Data <- PKIData).



Myers, Liu, Fox, Weinstein                                      Page 5

INTERNET DRAFT                                                March 1998

If PKIData is to be transmitted in cleartext form, then a SignedData is
contructed with PKIData as the content and id-signedData as the
contentType of the outermost CMS envelope.

The SignerInfos portion of SignedData carries one or more Service
Indicators as authenticatedAttributes. In all cases the presence of a
particular message body type SHALL be indicated by value of the
messageType Service Indicator.

The value of authenticatedAttributes is hashed using the algorithm
specified by digestAlgorithm, signed using the message originator's
private key corresponding to digestEncryptionAlgorithm, the result
encoded as an OCTET STRING and assigned to the encryptedDigest field of
SignedData.

The following pseudocode fragment illustrates the intended relationship
between the relevant syntactic elements:

Encryption 0ption 1: (signedData <- envelopedData < pkiData )

signedData.encapContentInfo.eContentType            <- id-envelopedData
signedData.authenticatedAttributes.contentType      <- id-pkiData
signedData.authenticatedAttributes.messageType      <- CMMF message type
envelopedData.encryptedContentInfo.contentType      <- id-pkiData
envelopedData.encryptedContentInfo.encryptedContent <- encrypted CMMF
                                                         message body

Encryption option 2: (envelopedData <- signedData <- pkiData )

envelopedData.encryptedContentInfo.contentType      <- id-signedData
envelopedData.encryptedContentInfo.encryptedContent <- encr. signedData
signedData.authenticatedAttributes.contentType      <- id-pkiData
signedData.authenticatedAttributes.messageType      <- CMMF message type
signedData.encapContentInfo.eContentType            <- id-pkiData
signedData.encapContentInfo.eContent                <- CMMF message body

The cleartext version is: (signedData <- pkiData)

signedData.authenticatedAttributes.contentType      <- id-pkiData
signedData.authenticatedAttributes.messageType      <- CMMF message type
signedData.encapContentInfo.eContentType            <- id-pkiData
signedData.encapContentInfo.eContent                <- CMMF message body

4.5 Service Indicators

The following Service Indicators are defined by this specification.

- version
- messageType
- pkiStatus
- failinfo
- transactionId
- senderNonce
- recipientNonce

Myers, Liu, Fox, Weinstein                                      Page 6

INTERNET DRAFT                                                March 1998

In addition to the above, [CMS] requires inclusion of the following:

- A content-type attribute having as its value the content type
of the ContentInfo value being signed.  With respect to this
specification, this value SHALL be id-pkiData regardless of the use of
EnvelopedData.

- A message-digest attribute, having as its value the message
digest of the content.

In addition, clients MAY include provisions for SigningTime and
counterSignature attributes.  Servers SHOULD be capable of accepting
PKIData messages containing such attributes.

Each Service Indicator is uniquely identified by an Object Identifier.
Processing systems would first detect the OID and process the
corresponding service indicator value prior to processing the message
body. PKIXCERT establishes a registration arc for objects associated
with certificate management protocols.  The value of id-it is imported
from that reference.  This specification extends id-it as follows:

id-it OBJECT IDENTIFIER  ::= { id-pkix 4 }   -- imported from PKIX
id-si OBJECT IDENTIFIER  ::= { id-it 1   }   -- cmc service indicators

-- service indicators

id-si-version          OBJECT IDENTIFIER ::= { id-si 1 }
id-si-transactionID    OBJECT IDENTIFIER ::= { id-si 2 }
id-si-messageType      OBJECT IDENTIFIER ::= { id-si 3 }
id-si-pkiStatus        OBJECT IDENTIFIER ::= { id-si 4 }
id-si-failInfo         OBJECT IDENTIFIER ::= { id-si 5 }
id-si-senderNonce      OBJECT IDENTIFIER ::= { id-si 6 }
id-si-recipientNonce   OBJECT IDENTIFIER ::= { id-si 7 }

The corresponding value syntax for each is:

Service Indicator      Syntax
-----------------      -------
version                INTEGER
messageType            INTEGER
pkiStatus              INTEGER
failInfo               INTEGER
TransactionId          INTEGER
senderNonce            OCTET STRING
recipientNonce         OCTET STRING

If version is absent, a value of 0 SHALL be assumed.  This draft
specifies version 1.

The messageType service indicator identifies the syntax carried in the
message body.  Every message SHALL include a value for messageType
appropriate to the message.



Myers, Liu, Fox, Weinstein                                      Page 7

INTERNET DRAFT                                                March 1998

The pkiStatus service indicator is used to convey information relevant
to a requested operation. This service indicator SHALL be included in
every message.

The failInfo service indicator conveys information relevant to the in-
terpretation of a failure condition. This service indicator is mandatory
in every message.

If the status in the response is FAILURE, then the failinfo service in-
dicator SHALL contain one of the failure reasons defined in Section
5.4.1 “Specific Values”.  Additional failure reasons MAY be defined for
environments with a need.

If additional transaction management or replay protection is desired,
transactionID, senderNonce and recipientNonce MAY be implemented.

The transactionId service indicator identifies a given transaction.  It
is used between client and server to manage the state of an operation.
It MAY be included in service request messages.  If included, responses
SHALL include the transmitted value.  Correspondingly, clients SHOULD
implement and recognize transactionID while servers or services SHALL
implement and recognize transactionID.

The senderNonce and recipientNonce service indicator can be used to
provide application-level replay prevention. They MAY be included in
service request messages.  Originating messages SHALL include only a
value for senderNonce. If included in originating messages, responses
SHALL include the transmitted value of the previously received
senderNonce as recipientNonce and include a value for senderNonce.

If nonces are used, in the first message of a transaction, no recipient-
Nonce is transmitted; a senderNonce is instantiated by the message
originator and retained for later reference.

If a transaction originator includes a value for the senderNonce service
indicator, responses SHALL include this value as a value for recipient-
Nonce AND include a value for the SenderNonce service indicator.

Upon receipt by the transaction originator of response containing a
value for recipientNonce, the originator compares the value of
recipientNonce to its retained value.  If the values match, the message
can be accepted for further security processing.  The received value for
senderNonce is also retained for inclusion in the next message
associated with the same transaction.

4.5.1 Specific Values

This specification establishes requirements regarding the implementation
of message formats defined in [CMMF].  The following values for
MessageType service indicator SHALL be used to identify the indicated
message body type:




Myers, Liu, Fox, Weinstein                                      Page 8

INTERNET DRAFT                                                March 1998

Message                MessageType Value    Legacy Value
-------                -----------------    ------------
PKCSReq                1                     19
CertReqMessages        2
CertRep                3
CertRepContent         4
GetCert                5                     21
GetCertInitial         6
GetCRL                 7                     22
RevRequest             8
RevReqContent          9
RevRepContent          10
CAKeyUpdAnnContent     11
CertAnnContent         12
CRLAnnContent          13
RevAnnContent          14
KeyRecRepContent       15

The pkiStatus field may take on any one of the following values:

Status                 pkiStatus value
-------                ---------------
SUCCESS                0
PENDING                1
FAILURE                2

The following values for failInfo are defined for the identified
context.

BADALG            0  -- Unrecognized or unsupported algorithm
BADMESSAGECHECK   1  -- integrity check failed
BADREQUEST        2  -- transaction not permitted or supported
BADTIME           3  -- Message time field was not sufficiently close
                       -- to the system time
BADCERTID         4  -- No certificate could be identified matching
                       -- the provided criteria
UNSUPPORTEDEXT    5  -- A requested X.509 extension is not supported
                       -- by the recipient CA.
BADTRANSID        6  -- Unrecognized transactionID

Additional contextual information regarding failure modes and reasons
may be provided within specific message bodies.

4.6 Additional Requirements on Use of Transaction ID

As state earlier, servers or services are required to support use of
TransactionID by clients.  Upon receipt of an initiating message at a
server or service, the value of TransactionID is retained during message
processing and included in the response message.  In general, the server
may at that point delete retention of the TransactionID from local
memory.

However, when a server issues a PENDING status against a request, the
server SHALL retain the value of TransactionID until the transaction

Myers, Liu, Fox, Weinstein                                      Page 9

INTERNET DRAFT                                                March 1998

completes, at which point either a SUCCESS or FAILURE message is
returned to the requestor.  The PENDING status SHALL contain the value
of TransactionID supplied in the request if one exists.  If the
requestor did not supply a transactionID, the server SHALL produce a
TransactionID value and return this value in the PENDING response.

During the PENDING interval, the server may receive a query against the
status of the transaction (see, for example, Section 5.7.4
GetCertInitial).  If the identified transaction is still pending, the
server SHALL respond with another PENDING response containing the
previously stored value for TransactionID.  If however no transaction is
in a PENDING state that matches the TransactionID specified in a status
query, the server SHALL respond with an empty PKIData envelope (i.e. no
message body) containing the value of FAILURE for pkiStatus and
BADTRANSID for failInfo.

4.7 Requirements on Data Origin Authenticity

All messages SHALL be digitally signed.

Prior to accepting a message as valid, clients, servers or services
SHALL confirm that:

1. The signature on the request is valid; and
2.  The certificate used to validate the signature is not revoked.

In the instance when the request is a certification request of a
signature public key originating directly from an end-entity, the
signature SHOULD be presumed valid until such time as the recipient CA
determines the authenticity of the attributes claimed in the
certification request.

Prior to accepting a response as valid, clients SHALL confirm that:

1.  The response corresponds to a former request; and
2.  The identity of the response originator matches the intended
recipient of the prior request.

4.8 Requirements on Use of CRMF and CMMF

Clients and servers SHALL implement the following subset of message
bodies as defined in [CRMF] and [CMMF].  They MAY implement additional
messages to meet the needs of specific environments.

Message                Mandatory
-------                ---------
PKCSReq                X
CertReqMessages
CertRep                X
CertRepContent
GetCert                X
GetCertInitial         X
GetCRL                 X
RevRequest             X

Myers, Liu, Fox, Weinstein                                     Page 10

INTERNET DRAFT                                                March 1998

RevReqContent
RevRepContent
CAKeyUpdAnnContent
CertAnnContent
CRLAnnContent
RevAnnContent
KeyRecRepContent

The following sections establish additional requirements on the use of
these messages.

4.8.1 PKCSReq

As defined in [CMMF], a PKCSReq message consists of a PKCS10 certificate
signing request and additional registration information. The PKCS10
field SHOULD contain a ChallengePassword attribute generated by the
owner of the private key.  It MAY contain an optional ExtensionReq
attribute used to indicate to the server one or more PKIXCERT
certificate extensions.  It MAY contain additional attributes as
specified by PKCS9.

Some certification products are operated in a fashion that assigns
subject names from a central repository of information upon receipt of a
public key for certification.  To accommodate this mode of operation,
the subject name in a PKCSReq MAY be NULL, but MUST be present.

CMS requires that the signerInfo contain a issuerNameSerialNumber value;
however for this transaction, the certificate has yet to be issued and
therefore the serialNumber has not yet been assigned.  Thus the
issuerName and SerialNumber value in the signerInfo element of PKCSReq
SHALL be set to NULL and zero, respectively.

4.8.2 Use of RegInfo in PKCSReq

The RegInfo field of a PKCSReq request MAY contain additional
information relevant to the request.  This information is supplied
external to the PKCS10 object and as such is not a component of the
proof of possession calculation (see [CMMF]).

The RegInfo field is intended to consist of name-value pairs. Appendix
B.1 of [CRMF] defines some standard name-value pairs and associated
encoding mechanisms.  Clients SHALL use those mechanisms when using the
RegInfo field of PKCSReq to address the requirements met by the elements
defined in CRMF Appendix B.1.  Additional name-value pairs MAY be
defined for environments with a need.

4.8.3 CertRep

A CertRep message is the response to a PKCSReq, GetCert or GetCRL.  It
is defined in [CMMF].

The following requirements pertain to the construction of CertRep
message in response to receipt of PKCSReq message:


Myers, Liu, Fox, Weinstein                                     Page 11

INTERNET DRAFT                                                March 1998

CertRep message consists of one or more certificates and an associated
RspInfo field.  The certificate(s) are contained in the response field.
This field is a SignedData CMS content type with no ContentInfo or
SignerInfos fields.  Section 5.1 of CMS further describes this
particular construction.  In particular, although the SignedData
construct is used, no signature is produced.

If the value of pkiStatus service indicator in a CertRep message is
SUCCESS, the response field SHALL contain the requested certificate(s)
and MAY contain additional non-root CA certificates related to the
validation of the requested certificate(s).

If the value of pkiStatus service indicator in a CertRep message is
PENDING or FALURE, the response field SHALL be excluded.

In all cases, the rspInfo field of CertRep MAY contain additional
information useful to the application receiving the message in the form
of name-value pairs. Other additional data could include detailed error
information that uniquely identifies an information field supplied in
the original regInfo field of a PKCSReq; e.g. the Zip Code was incorrect
for the specified address or locale or billing failed because credit
card information was in error.

CAs that receive a PKCSReq with a null subject name MAY reject such
requests.  If rejected, the CA SHALL respond with a CertRep message with
pkiStatus of FAILURE and failInfo value of BADREQUEST.

The client MAY incorporate one or more standard X.509 v3 extensions in
the request as defined in [CMMF]. Servers are not required to be able to
process every v3 X.509 extension transmitted using this protocol, nor
are they required to be able to process other, private extensions.
However, in the circumstance when a certification request is denied due
to the inability to handle a requested extension, the server SHALL
respond with a CertRep message indicating FAILURE and a corresponding
FailureInfo field with the value of UNSUPPORTEDEXT.

4.8.4 GetCertInitial

The GetCertInitial message is used to poll for the certificate
associated with prior PKCSReq request if the response to that prior
request was a CertRep message with a status of PENDING.

Certificates are normally referenced using the CA DN and the certificate
serial number.  In this case however a certificate has not yet been
issued.  Thus the CA and Subject DNs are present in the message as a
means to identify the requested certification. [CMMF] defines this
syntax.

Clients that implement GetCertInitial SHALL conform to the requirements
on use of the TransactionID service indicator as defined in Section
5.4.2.




Myers, Liu, Fox, Weinstein                                     Page 12

INTERNET DRAFT                                                March 1998

4.8.5 GetCert

This operation is used to retrieve certificates from a certificate
server or service’s repository. This message is useful in circumstances
where a fully-deployed Directory is either infeasible or undesired.
Additionally, certificate retrieval requests may be used by resource-
constrained clients to recover their public key in the event of a device
reset.  This could be the case within low-end IP routers that do not
retain their certificates in non-volatile memory.

The GetCert message body consists of the CertID syntax defined in
[CMMF].  For reference, this syntax is:

CertID ::= SEQUENCE {
    issuerName  GeneralName,
    serialNumber  INTEGER }

The response to a GetCert message SHALL consist of CertRep message
containing a signedData response containing the requested certificate as
defined in [CMMF].

4.8.6 GetCRL

This operation is used to retrieve CRLs from a CA's repository. In order
to provide clients a convenient means of determining the network address
needed to acquire a CA's CRL, servers and clients SHOULD be capable of
producing and processing the CRLDistributionPoints certificate extension
as defined in [PKIXCERT].

The response to a GetCRL message SHALL consist of CertRep message
containing only a value for CRLs as a component of a “degenerate”
SignedData rather than the certificates component.  Contents for the
rspInfo field of CertRep MAY be included.

4.8.7 RevReq

[CMMF] defines the syntax of a RevReq (revocation request).  For
reference, a RevReq message body consists of:

- name of the certificate issuer
- serial number of the certificate to be revoked
- a reason code
- an optional passphrase
- an optional comment field

For a revocation request to become a reliable object in the event of a
dispute, a strong proof of originator authenticity is required. A
Registration Authority’s digital signature on the request can provide
this proof for certificates within the scope of the RA’s revocation
authority.  The means by which an RA is delegated this authority is a
matter of operational policy.

However, in the instance when an end-entity has lost use of their
signature private key, it is impossible to produce a reliable digital

Myers, Liu, Fox, Weinstein                                     Page 13

INTERNET DRAFT                                                March 1998

signature. The PKCSReq message provides for the optional transmission
from the CA to the end-entity of a passphrase which may be used as an
alternative authenticator in the instance of loss of use. The
acceptability of this practice is a matter of local security policy.

Clients SHALL provide the capability to produce a digitally signed
RevReq message.  Clients SHOULD provide the capability produce an
unsigned revocation request containing the end-entity’s passphrase.  If
a client provides passphrase-based self-revocation, the client SHALL be
capable of producing a PKCSReq containing a passphrase.

The structure of an unsigned, passphrase-based RevReq is a matter of
local implementation.  Since such a message has no relationship to the
use of cryptography, the use of CMS to convey this message is not
required.

The response to a RevReq message SHALL consist of CertRep message with
the following characteristics:

Success:
1.  The pkiStatus service indicator SHALL contain a value of SUCCESS.
2.  The response field of the CertRep message body MAY be included. If
so, it SHALL contain the updated CRL relevant to the subject
certificate.

Failure:
1.  The pkiStatus service indicator SHALL contain a value of FAILURE.
2.  The failInfo service indicator shall be set to the appropriate reason
code.
3.  The response field of the CertRep message body SHALL be excluded.

In either case, the rspInfo field of CertRep message body MAY be
included.  If so, it SHALL contain additional information relevant to
the interpretation of the failure.

5. Security Considerations

Initiation of a secure communications channel between an end-entity and
a CA necessarily requires an out-of-band trust initiation mechanism. For
example, a secure channel may be constructed between the end-entity and
the CA via IPSEC or TLS. Many such schemes exist and the choice of any
particular scheme for trust initiation is outside the scope of this
document.  Implementors of this protocol are strongly encouraged to
consider generally accepted principles of secure key management when
integrating this capability within an overall security architecture.

Mechanisms for thwarting replay attacks may be required in particular
implementations of this protocol depending on the operational
environment. In cases where CAs maintain significant state information
themselves, replay attacks may be detectable without the inclusion of
the optional nonce mechanisms. Implementors of this protocol need to
carefully consider environmental conditions before choosing whether or
not to implement the senderNonce and recipientNonce service indicators
described in section 4.3.1.  Developers of state-constrained PKI clients

Myers, Liu, Fox, Weinstein                                     Page 14

INTERNET DRAFT                                                March 1998

are strongly encouraged to incorporate the use of these service
indicators.

6. References

[CMS]      R. Housley, "Cryptographic Message Syntax",
           draft-ietf-smime-cms-01.txt, October 1997

[PKCS7]    B. Kaliski, "PKCS #7: Cryptographic Message Syntax v1.5",
           draft-hoffman-pkcs-crypt-msg-03.txt, October 1997

[PKCS10]   B. Kaliski, "PKCS #10: Certification Request Syntax v1.5",
           draft-hoffman-pkcs-certif-req-03.txt, October 1997

[PKIXCERT] R. Housley, W. Ford, W. Polk, D. Solo "Internet Public
           Key Infrastructure X.509 Certificate and CRL Profile",
           draft-ietf-pkix-ipki-part1-06.txt, October, 1997

[CRMF]     M. Myers, C. Adams, D. Solo, D. Kemp,
           Certificate Request Message Format,
           <draft-ietf-pkix-crmf-00.txt>, February, 1998



9.  Author's Addresses

Michael Myers
VeriSign, Inc.
1390 Shorebird Way
Mountain View, CA, 94019
(650)  429-3402
mmyers@verisign.com

Xiaoyi Liu
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
(480) 526-7430
xliu@cisco.com

Barbara Fox
Microsoft Corporation
One Microsoft Way
Redmond, WA  98052
(425) 936-9542
bfox@microsoft.com

Jeff Weinstein
Netscape Communications Corporation
501 Middlefield Road
Mountain View, CA 94043
jsw@netscape.com