SMIME Working Group Michael Myers (VeriSign) Internet Draft Xiaoyi Liu (Cisco) Barbara Fox (Microsoft) Hemma Prafullchandra (Sun) Jeff Weinstein (Netscape) expires in six months November 1997 Certificate Request Syntax 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups MAY also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six 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 an Internet PKI Certificate Request Syntax (CRS). It addresses a growing need within the Internet PKI community for an interface to public key certification products and services based on PKCS7 [PKCS7] and PKCS10 [PKCS10]. A small number of additional services are defined to supplement the core certificate request service. Current industry practice regarding the use of PKCS7 and PKCS10 is also documented for the benefit of the Internet community. In general, the use of PKCS7 in this document is aligned to the Cryptographic Message Syntax [CMS] which provides a superset of the PKCS7 syntax. Throughout this document, the term CMS should be taken to include the PKCS #7 document as defined in [PKCS7]. The term CRS refers to this specification. The chief differences between CRS and PKIXMGMT are: - Use of PKCS7 for security encapsulation and transaction framework - Use of PKCS10 as the certification request message content - Certification of Diffie-Hellman Public Keys based on PKCS10 requests - No assumption of reliable connectivity or persistent on-line operation - Single request/response transaction model The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119. Myers, Liu, Fox, Prafullchandra, Weinstein [Page 1] INTERNET DRAFT November, 1997 3. Protocol Overview This document identifies use of some CMS protocol elements. In the interests of brevity and syntactic alignment, readers interested in the full syntactic context should refer to that document. A transaction in this specification is composed of the exchange of request-response message pairs between a server and a client. Three transactions are defined: 1. Certification of a public key; 2. Certificate and CRL retrieval; and 3. Certificate revocation. A public key certification request is formed as a PKCS10 object. The corresponding response is CMS encapsulation of the requested certificate and its associated non-Root CA certificate(s). Within this draft, the latter construction is referred to as a certificate response, or CertRep. A CertRep is a CMS signedData object that only contains certificates. Both the PKCS10 content and the resulting CertRep SHOULD be encapsulated within a full CMS security envelope. Encapsulating the CertRep in a full CMS envelope enables Registration Authorities to assert a signature across a certificate request. Some existing implementations of these mechanisms utilize a simplified form of this exchange. In these implementations, an unencapsulated PKCS10 object is provided to the Certification Authority, which responds with an unencapsulated CertRep syntax. 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. Transactions MAY 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. Replay protection MAY be 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. Message bodies MAY be encrypted. Whether encrypted or cleartext, either are in turn included as the content of SignedData. The message digest of Myers, Liu, Fox, Prafullchandra, Weinstein [Page 2] INTERNET DRAFT November, 1997 message body is then signed together with the Service Indicators using the originator's private signing key, producing the message signature. The following figure illustrates the essential characteristics of fully- encapsulated transaction message structure. Many interior details and fields have been omitted for clarity. Not all of the indicated fields are present in every message type. The ORIGINATOR’S CERTIFICATES element may actually be composed of one or more non-root CA certificate together with the end-entity certificate needed to validate the message signature. |---------------------------------------| |SIGNED DATA | |---------------------------------------| | content | | DATA | | cleartext message body | | or | | ENCRYPTED DATA | | Message Encryption Key (MEK)| - encrypted MEK | encrypted message body | - encrypted under MEK |---------------------------------------| | ORIGINATOR'S CERTIFICATES | |---------------------------------------| | AUTHENTICATED ATTRIBUTES | | Hash of Content | | version | - protocol version number | message type | - indicates msg body syntax | transaction status | | transaction identifier | - optional | sender nonce | - optional | recipient nonce | - optional |---------------------------------------| | Message Signature | -produced by originator |---------------------------------------| 4. Protocol Elements 4.1 PKCS7 Interoperability CMS differs from PKCS7 in the following ways: - 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. Myers, Liu, Fox, Prafullchandra, Weinstein [Page 3] INTERNET DRAFT November, 1997 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 CRS 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. PKI clients and servers SHOULD also be capable of producing and processing RSA signatures as specified in section 7.2.1 of PKIXCERT. CRS 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. PKI 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. Two options exist with respect to the use of encryption. One usage produces an encrypted message body encapsulated by a signed, cleartext envelope. Organizations that wish to protect against the leakage of sensitive data via cleartext channels may chose instead to produce a cleartext message body which is placed with a signed envelope which is in turn encapsulated by an encrypted envelope. The following figure illustrates the options: Option 1 Option 2 -------- -------- SignedData EnvelopedData EnvelopedData SignedData Data Message bodies MAY be encrypted or transmitted in the clear. Support SHALL be provided for encryption option 1 and SHOULD be provided for both. Myers, Liu, Fox, Prafullchandra, Weinstein [Page 4] INTERNET DRAFT November, 1997 4.3 Message Construction A fully-encapsulated CRS message SHALL be constructed as follows. The contentInfo field of a signedData type is populated with the envelopedData content type if the content is encrypted or Data content type if the data is sent in cleartext form (see the Open Issues section at the end of this document regarding MIME agent interoperability). The content MAY contain one of the following message bodies: - PKCSReq -- Request for a certificate - CertRep -- Response to a certificate request - GetCert -- A means to query for others' certificates - GetCRL -- A means to query for a CA's CRL(s) - DualReq -- Separate signature and encryption certificates - DualRep -- Responses to a DualReq - RevReq -- Request to revoke a certificate - RevResp -- Response to a revocation request The presence of a particular message body type in either the encrypted- Content of an envelopedData content type or the content of a Data con- tent type SHALL be indicated by value of the messageType Service Indica- tor (see section 4.4) of the outermost SignedData. Successful responses are indicated by a value of SUCCESS for pkiStatus. All other responses are indicated by a value of FAILURE. A PKCSReq message consists of a PKCS10 certificate signing request. The request SHALL contain subject name and subject public key. The subject name MAY be NULL, but must be present. The request MAY contain a ChallengePassword attribute. 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. The ExtensionReq attribute is composed as a SEQUENCE OF X.509 extensions. When present in a PKCS10 certification request, this attribute SHALL be identified by the OID {pkcs-9 14} (This OID should be assiged off an SMIME WG arc?). A CertRep message is the CA's response to a PKCSReq, GetCert or GetCRL. It MAY contain a certificate but always contains one or more Service Indicators. The DualReq and DualRep message pair enables production and processing of separate signature and encryption certification request in a single message. The RevReq and RevRep message pair enables production and processing of certificate revocation requests. 4.3.1 Service Indicators The SignerInfos portion of SignedData carries one or more Service Indicators as authenticatedAttributes. As defined in CMS, the value of authenticatedAttributes is hashed using the algorithm specified by Myers, Liu, Fox, Prafullchandra, Weinstein [Page 5] INTERNET DRAFT November, 1997 digestAlgorithm, signed using the originator's private key corresponding to digestEncryptionAlgorithm, the result encoded as an OCTET STRING and assigned to the encryptedDigest field of SignedData. The following Service Indicators are defined: - version - messageType - pkiStatus - failinfo - transactionId - senderNonce - recipientNonce Each is uniquely identified by an Object Identifier (OID) that signals the syntax following the OID. Processing systems would first detect the OID and process the corresponding service indicator value prior to processing the message body. As noted, service indicators are encoded as AuthenticatedAttributes within SignedData. In accordance with CMS, when included in a CMS mes- sage, AuthenticatedAttributes must consist of at a minimum: - A PKCS #9 content-type attribute having as its value the content type of the ContentInfo value being signed. - A PKCS #9 message-digest attribute, having as its value the message digest of the content. CRS clients and servers SHALL include values for AuthenticatedAttributes in accordance. In addition to the required Attributes of content-type and message-digest, one or more of the following six authenticated attributes MUST be included as needed. Service Indicator OID Syntax ----------------- ------------- --------------- version smime-crs 1 INTEGER TransactionId smime-crs 2 INTEGER messageType smime-crs 3 INTEGER pkiStatus smime-crs 4 INTEGER failInfo smime-crs 5 INTEGER senderNonce smime-crs 6 OCTET STRING recipientNonce smime-crs 7 OCTET STRING DualStatus smime-crs 8 {as specified below} DualStatus ::= SEQUENCE OF { request_id INTEGER, status pkiStatus, failure failInfo OPTIONAL } The DualStatus syntax supports certificate request messages that con- tain request for more than one certificate. That is, an end-entity sub- Myers, Liu, Fox, Prafullchandra, Weinstein [Page 6] INTERNET DRAFT November, 1997 mits a DualReq request and receives a DualRep response containing a DualStatus service indicator. The version service indicator indicate CRS protocol version. If absent, a value of 0 SHALL be assumed. This draft specifies CRS version 1. The messageType service indicator identifies the syntax carried in the message body. Every CRS message SHALL include a value for messageType appropriate to the message. The messageType service indicator specifies the type of operation performed by the transaction. This attribute is required in all messages. The following values for messageType are defined: Message MessageType Value ------- ---------- PKCSReq (19) -- PKCS#10 certificate request CertRep (3) -- Response to certificate request GetCert (21) -- Retrieve a certificate GetCRL (22) -- Retrieve a CRL DualReq (23) -- Dual certificate requests in a single msg DualRep (24) -- Response to a DualReq The value given for messageType value is set in the messageType service indicator for messages of the indicated type. This service indicator SHALL be included in every message. The pkiStatus service indicator is used to convey information relevant to a requested operation. This service indicator SHALL be included in every message. Response messages SHALL include transaction status information which is defined as pkiStatus service indicator: Status pkiStatus value ------- --------------- SUCCESS (0) -- request successful FAILURE (2) -- request rejected This pKIStatus service indicator is required for all PKI messages. The value given for pkiStatus value is set in the pkiStatus service indica- tor for status of the indicated type. 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 following failure reasons: BADALG (0) -- Unrecognized or unsupported algorithm BADMESSAGECHECK (1) -- integrity check failed BADREQUEST (2) -- transaction not permitted or supported Myers, Liu, Fox, Prafullchandra, Weinstein [Page 7] INTERNET DRAFT November, 1997 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. Additional failure reasons MAY be defined for environments with a need. The messageType, pkiStatus, and failInfo service indicators are mandatory for all messages. 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 included the transmitted value. 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 include only a value for senderNonce. If included, 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. The recipient of a sender nonce reflects this value back to the originator as a recipientNonce and includes it's own senderNonce. Upon receipt by the transaction origina- tor of this message, 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. 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. If a transaction originator includes a value for the transaction-id service indicator in a service request, responses SHALL include this value as a value for transaction-id service indicator. 4.3.2 Messages Bodies The following message bodies SHALL be constructed in the method indi- cated. Some current implementations transmit a PKCS10 request and its corresponding response directly. These quantities SHOULD be CMS- encapsulated prior to transmission as described above. Myers, Liu, Fox, Prafullchandra, Weinstein [Page 8] INTERNET DRAFT November, 1997 4.3.3 PKCSReq Message Body A PKCSReq message body is composed of two elements. The first consists of the PKCS10 structure itself. The second consists of optional supplementary registration information. Syntactically, this message body is constructed as: PKCSReq ::= SEQUENCE { csr CertificationRequest, regInfo OCTET STRING OPTIONAL } CertificationRequest ::= SEQUENCE { certificationRequestInfo SEQUENCE { version INTEGER, subject Name, subjectPublicKeyInfo SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING } attributes [0] IMPLICIT SET OF Attribute } signatureAlgorithm AlgorithmIdentifier, signature BIT STRING } Clients SHALL produce a PKCS10 message body containing a subject name and public key. 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. CAs that receive a request 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 an ExtensionReq attribute. An ExtensionReq attribute is defined as ExtensionReq ::= SEQUENCE OF Extension where Extension is imported from PKIX Part 1 and ExtensionReq is identified by {pkcs-9 14} (OID should be off the SMIME WG arc?). 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 an UNSUPPORTEDEXT error as defined in section 4.3.1. 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 SHALL be set to NULL and zero, respectively. Myers, Liu, Fox, Prafullchandra, Weinstein [Page 9] INTERNET DRAFT November, 1997 Schematically, the relationship among the elements of a PKCSReq message are as follows: |---------------------------------------| |SIGNED DATA | |---------------------------------------| | DATA | | PKCSReq | - the PKCS10 |or ENVELOPED DATA | | MEK | - encrypted key exchange key | encrypted content: | - encrypted under MEK | PKCSReq | - the PKCS10 |---------------------------------------| | ORIGINATOR’S CERTIFICATES | |---------------------------------------| | AUTHENTICATED ATTRIBUTES | | Hash of Content | | version | - protocol version number | message type | - PKCSREQ | transaction status | | transaction identifier | - optional | sender nonce | - optional |---------------------------------------| | Message Signature | |---------------------------------------| 4.3.4 Production of Diffie-Hellman Public Key Certification Requests When a PKCSReq or DualReq message is used to produce a certified Diffie- Hellman public key, the means to establish proof of possession of the corresponding private key SHALL be performed using the methods described in Appendix A of this document. CAs that support this mechanism SHALL have produced and make available a D-H public key certificate. This certificate SHALL contain the parameters associated with the public key. Clients that support this mechanism SHALL generate a D-H key pair using the parameters contained in the CA’s certificate they wish to have certify their D-H public key. 4.3.5 CertRep A CertRep message is the response to a prior PKCSReq message. It is in- dicated by a value of CERTREP in the messageType service indicator. Successful responses are indicated by a value of SUCCESS for pkiStatus. All other responses are indicated by a value of FAILURE. Section 4.2 de- fines specific values for these constants. 4.3.5.1 FAILURE Servers transmit a CertRep messages with a pkiStatus of FAILURE if the certification request or its subsequent processing fails to meet the certification practices requirements of the entity operating the server. Myers, Liu, Fox, Prafullchandra, Weinstein [Page 10] INTERNET DRAFT November, 1997 The message is a SignedData content type with no ContentInfo block. The SignerInfo block contains the following Authenticated Attributes as in- dicated: |---------------------------------------| |SIGNED DATA | |---------------------------------------| |---------------------------------------| | ORIGINATOR’S CERTIFICATES | |---------------------------------------| | AUTHENTICATED ATTRIBUTES | | Hash of Content | | version | - protocol version number | message type | - CERTREP | transaction status | - FAILURE | failInfo | - reason code | transaction identifier | - from prior msg, if present | sender nonce | - prior msg, if present | recipient nonce | - current server nonce if | | prior client nonce present |---------------------------------------| | Message Signature | |---------------------------------------| Failure reason codes are specified in Section 4.2. 4.3.5.2 SUCCESS response The Client's certificate(s) SHALL be conveyed to the Client as a “certs-only” CMS SignedData message. To construct such a message, the certificates are made available to the CMS generating process which creates a CMS object of type signedData. The contentInfo and signerInfos fields must be empty. The message body SHALL include all non-root certificates needed to validate the signature on the end-entity's certificate(s). Myers, Liu, Fox, Prafullchandra, Weinstein [Page 11] INTERNET DRAFT November, 1997 Schematically, the general relationship among these elements is as follows: |---------------------------------------| |SIGNED DATA | |---------------------------------------| | DATA | | CA certificate(s) | - intermediate CA cert(s) | ee certificate | - end entity sig. certificate | ee certificate | - end entity enc. certificate |or ENVELOPED DATA | | MEK | - encrypted key exchange key | encrypted content: | - encrypted under MEK | CA certificate(s) | - intermediate CA cert(s) | ee certificate | - end entity sig. certificate | ee certificate | - end-entity enc. certificate |---------------------------------------| | ORIGINATOR’S CERTIFICATES | |---------------------------------------| | AUTHENTICATED ATTRIBUTES | | Hash of Content | | version | - protocol version number | message type | - CERTREP | transaction status | - SUCCESS | transaction identifier | - from prior msg, if present | sender nonce | - prior msg, if present | recipient nonce | - current server nonce if | | prior client nonce present |---------------------------------------| | Message Signature | |---------------------------------------| This schematic depicts the situation where an end-entity has requested separate signature and encryption certificates in a single message. Section 4.3.6 which follows specifies the means by which an end-entity can perform a single request that yields this result. 4.3.6 DualReq and DualRep This construct is used by a single end-entity to request signature and encryption certificates in a single message. For each certification, a request identifier is included. This identifier is needed to differentiate among the multiple CertRep data that will be returned in the resulting DualRep response. The optional transaction identifier and sender nonce, if included, apply to the message as a whole. Syntactically, DualReq ::= SEQUENCE OF { request PKCSReq, req_id INTEGER } Myers, Liu, Fox, Prafullchandra, Weinstein [Page 12] INTERNET DRAFT November, 1997 The values for req_id SHALL be relatively unique within a single DualReq content. A PKCSReq for key-usage differentiated certificates SHALL contain a value for KeyUsage extension identified and structured in accordance with PKIXCERT. This extension SHALL be conveyed as an ExtensionReq Attribute within the PKCS10 syntax. For end-entities requesting the production of a signature-only certificate, the keyUsage extension SHALL contain either a setting of DigitalSignature, NonRepudiation or both. For end-entities requesting the production of an encryption-only certificate, the keyUsage extension SHALL contain a setting of keyEncipherment, dataEncipherment, or keyAgreement. Schematically, the resulting message would appear as follows: |---------------------------------------| |SIGNED DATA | |---------------------------------------| | DATA | | PKCSReq, 1 | - first PKCS10 | PKCSReq, 2 | - second PKCS10 |or ENVELOPED DATA | | MEK | - encrypted key exchange key | encrypted content: | - encrypted under MEK | PKCSReq, 1 | - first PKCS10 | PKCSReq, 2 | - second PKCS10 |---------------------------------------| | ORIGINATOR’S CERTIFICATES | |---------------------------------------| | AUTHENTICATED ATTRIBUTES | | Hash of Content | | version | - protocol version number | message type | - DUALREQ | transaction status | | transaction identifier | - optional | sender nonce | - optional |---------------------------------------| | Message Signature | |---------------------------------------| The corresponding response to a DualReq message is composed of a similarly iterated construction: DualRep ::= SEQUENCE OF { req_id INTEGER, ee_certs SEQUENCE OF CertRep } Myers, Liu, Fox, Prafullchandra, Weinstein [Page 13] INTERNET DRAFT November, 1997 4.3.7 GetCRL This operation is used to retrieve CRLs from a CA's repository. It as- sumes the target CA maintains one and only one CRL relative to a given private signing key. 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 CRLDistri- butionPoints certificate extension. Alternatively, the Client MAY be pre-configured with the CRL's location. |---------------------------------------| |SIGNED DATA | |---------------------------------------| | DATA | | GetCRL message body | |---------------------------------------| | ORIGINATOR’S CERTIFICATES | |---------------------------------------| | AUTHENTICATED ATTRIBUTES | | Hash of Content | | version | - protocol version number | message type | - GETCRL | transaction status | | transaction identifier | - optional | sender nonce | - optional |---------------------------------------| | Message Signature | |---------------------------------------| The GetCRL message body SHALL consist of the following syntax: GetCRL ::= SEQUENCE { issuerName Name, time GeneralizedTime } The Name component is the value of the Issuer DN in the subject certifi- cate. The time component is used by the client to specify from among several issues of CRL that one whose thisUpdate value is less than but nearest to the specified time. 4.3.8 GetCert A certificate retrieval request MAY be used by resource-constrained clients to recover their public key in the event of a device reset. This MAY be the case, for example, within low-end IP routers which may not be capable of retaining their certificates in non-volatile memory. Myers, Liu, Fox, Prafullchandra, Weinstein [Page 14] INTERNET DRAFT November, 1997 |---------------------------------------| |SIGNED DATA | |---------------------------------------| | DATA | | GetCert message body | |---------------------------------------| | ORIGINATOR’S CERTIFICATES | |---------------------------------------| | AUTHENTICATED ATTRIBUTES | | Hash of Content | | version | - protocol version number | message type | - GETCERT | transaction status | | transaction identifier | - optional | sender nonce | - optional |---------------------------------------| | Message Signature | |---------------------------------------| The GetCert message body SHALL consist of the following syntax: GetCert ::= SEQUENCE { issuerName Name, serialNumber INTEGER } 4.3.9 Revocation Request and Response A revocation request is structured as follows. RevReq ::= SEQUENCE { issuerName Name, serialNumber INTEGER, reason ReasonFlags, -- from PKIXCERT passphrase OCTET STRING OPTIONAL, comment PrintableString OPTIONAL } 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 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. CRS clients SHALL provide the capability to produce a digitally signed RevReq message. CRS clients SHOULD provide the capability produce an unsigned revocation request containing the end-entity’s passphrase. If Myers, Liu, Fox, Prafullchandra, Weinstein [Page 15] INTERNET DRAFT November, 1997 a CRS client provides passphrase-based self-revocation, the client SHALL be capable of producing a PKCSReq containing a passphrase. A cleartext signed revocation request has the following basic structure: |---------------------------------------| |SIGNED DATA | |---------------------------------------| | DATA | | RevReq message body | |---------------------------------------| | ORIGINATOR’S CERTIFICATES | |---------------------------------------| | AUTHENTICATED ATTRIBUTES | | Hash of Content | | version | - protocol version number | message type | - REVREQ | transaction status | | transaction identifier | - optional | sender nonce | - optional |---------------------------------------| | Message Signature | |---------------------------------------| 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 revocation request, REVRESP, is a CRS message with no message body. The services indicators will convey the status of the processing of the message by the recipient CA service or server. Its basic structure is as follows: |---------------------------------------| |SIGNED DATA | |---------------------------------------| |---------------------------------------| | ORIGINATOR’S CERTIFICATES | |---------------------------------------| | AUTHENTICATED ATTRIBUTES | | Hash of Content | | version | - protocol version number | message type | - REVRESP | transaction status | - SUCCESS or FAILURE | failure | - present if status is FAILURE | transaction identifier | - optional | sender nonce | - optional |---------------------------------------| | Message Signature | |---------------------------------------| Myers, Liu, Fox, Prafullchandra, Weinstein [Page 16] INTERNET DRAFT November, 1997 6. 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 are strongly encouraged to incorporate the use of these service indicators. 7. Open Issues This draft specifies the essential characteristics of a protocol based on the CMS and PKCS7 security encapsulation syntaxes. Integration of this protocol to MIME needs to be performed to align it with generally accepted practices of MIME interoperability. In particular it is noted that current SMIME draft specifications integrate CMS syntax with MIME encapsulation to achieve SMIME interoperability. This draft also presents a number of optional constructions. Consensus needs to be established on a minimum interoperable profile. 8. References [CMS] R. Housley, "Cryptographic Message Syntax", draft-ietf-smime-cms-01.txt, October 1997 [DH] B. Kaliski, "PKCS 3: Diffie-Hellman Key Agreement v1.4" [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 [PKIXMGMT] C. Adams, S. Farrell, "Internet Public Key Infrastructure Certificate Management Protocols", draft-ietf-pkix-ipki3cmp-04.txt, September 1997 Myers, Liu, Fox, Prafullchandra, Weinstein [Page 17] INTERNET DRAFT November, 1997 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 Hemma Prafullchandra Sun Microsystems Inc 2550 Garcia Ave CUP01-102 Mountain View, CA 94043 (408) 343-1798 hemma@sun.com Appendix A A PROPOSAL FOR CERTIFICATION REQUEST OF DIFFIE-HELLMAN PUBLIC VALUES ==================================================================== Version 1.2 September 26, 1996 1.0 INTRODUCTION PKCS #10 [PKCS10]from RSA Labs defines a syntax for certification requests. In there it is assumed that the public key being requested for certification corresponds to an algorithm which is capable of signing/encrypting. Diffie-Hellman (DH) is a key agreement algorithm and thus cannot be used for signing/encrypting. Hence, the following enhancement to PKCS #10 is proposed for requesting certification for Diffie-Hellman public values. 2.0 SCOPE This proposal is primarily concerned with "signatureAlgorithm" and "signature". I believe there has been some discussions on extending/ revising PKCS #10 to allow for such things as validity period and optional fields supported in X.509 v3 certificates, none of these are addressed in this proposal. Also this proposal does not provide for identity authentication. However this can be achieved if the enrollee already possesses a valid signature key certificate and the corresponding private key to this is used to sign the certification request (as opposed the private corresponding to the public key in the certification request itself). 3.0 DEFINITIONS For the purposes of this proposal, the following definitions apply. DH certificate = a certificate whose SubjectPublicKey is a DH public value and is signed with any signature algorithm (e.g. rsa or dsa). 4.0 SPECIFICATION FOR DH CERTIFICATION >From PKCS #10, section 6.2 CertificationRequest, the following ASN.1 syntax is defined. CertificationRequest ::= SEQUENCE { certificationRequestInfo CertificationRequestInfo, signatureAlgorithm SignatureAlgorithmIdentifier, signature Signature } SignatureAlgorithmIdentifier ::= AlgorithmIdentifier Signature ::= BIT STRING 4.1 DH CERTIFICATION PROCESS The steps then for requesting certification of DH public values are: 1. An entity chooses a Certification Authority. It obtains the CAs' DH certificate. Other than trust, the selection has to take into account with which community/group of entities this entity wishes to use the certified DH public value (for interoperability a common set of DH parameters have to be used). [ Note: a CA MAY have more than one signature key, and thus is likely to have more than one certificate. This proposal requires that a CA which wishes to provide certification service for public key agreement algorithms makes available a certificate with a public key (and common parameters) for that algorithm. ] If the enrollee already possess a valid signature key certificate, then, the enrollee can select the group parameters g and P, and compute a DH public value, all this would be encoded as the SubjectPublicKeyInfo and the request signed by the signature key. The CA can then verify the request (it would need the enrollees signature key certificate to obtain the public key) and issue a certificate. 2. The entity generates a DH public/private key-pair. The DH parameters used to calculate the public should be those specified in the CAs' DH certificate. From CAs' DH certificate: CApub = g^x mod p (where g and p are the established DH parameters and x is the CAs' private DH component) For entity E: DH private value = y Epub = DH public value = g^y mod p 3. The entity selects a SignatureAlgorithmIdentifier. A number of these may be defined, the following is recommended. craWithHMACandSHA1 ::= { an oid needs to be assigned } [ certification request algorithm with HMAC-SHA1 as the message digest algorithm as specified in [HMAC-MD5]. ] 4. The signature process will then consist of: a) The value of the certificationRequestInfo field is DER encoded, yielding an octet string (as per PKCS #10). This will be the `text' referred to in [HMAC-MD5], the data to which HMAC-SHA1 is applied. b) A shared DH secret is computed, as follows, shared secret = Kec = g^xy mod p [ This is done by the entity E as g^(y.CApub) and by the CA as g^(x.Epub), where CApub is retrieved from the CA's DH certificate and Epub is retrieved from the actual certification request. ] c) A key K is derived from the shared secret Kec as follows: K = SHA1(DER-encoded-subjectName | Kec | DER-encoded-issuerName) where "|" means concatenation. d) Compute HMAC-SHA1 over the data `text' as per [HMAC-MD5] as: SHA1(K XOR opad, SHA1(K XOR ipad, text)) where, opad (outer pad) = the byte 0x36 repeated 64 times and ipad (inner pad) = the byte 0x5C repeated 64 times. Namely, (1) Append zeros to the end of K to create a 64 byte string (e.g., if K is of length 16 bytes it will be appended with 48 zero bytes 0x00). (2) XOR (bitwise exclusive-OR) the 64 byte string computed in step (1) with ipad. (3) Append the data stream `text' to the 64 byte string resulting from step (2). (4) Apply SHA1 to the stream generated in step (3). (5) XOR (bitwise exclusive-OR) the 64 byte string computed in step (1) with opad. (6) Append the SHA1 result from step (4) to the 64 byte string resulting from step (5). (7) Apply SHA1 to the stream generated in step (6) and output the result. Sample code is also provided in [HMAC-MD5]. e) The output of (d) is encoded as a BIT STRING (the Signature). 5. The signature verification process requires the CA to carry out steps (a) through (d) and then simply compare the result of step (d) with what it received as the signature component. If they match then the following can be concluded: 1) The Entity possesses the private key corresponding to the public key in the certification request because it needed the private key to calculate the shared secret; and 2) That only the CA, the entity sent the request to could actually verify the request because the CA would require its own private key to compute the same shared secret. This protects from rogue CAs. 5.0 ACKNOWLEDGEMENTS I would like to thank Peter Williams and Dave Solo for providing comments which resulted in making this proposal clear, succinct and complete. Also, Hugo Krawczyk, John Kennedy, Bob Jueneman and Carlisle Adams provided extremely important improvements. 6.0 AUTHOR INFORMATION Hemma Prafullchandra Sun Microsystems Inc 2550 Garcia Ave CUP01-102 Mountain View CA 94043 (408) 343-1798 hemma@sun.com 7.0 REFERENCES [PCKS10] RSA Data Security, Inc., Public-Key Cryptography Standards (PKCS) #10: Certification Request Syntax Standard, November 1, 1993 [RFC1423] D. Balenson, Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers, February, 1993 [HMAC-MD5] H. Krawczyk, M. Bellare, R. Canetti, HMAC-MD5: Keyed-MD5 for Message Authentication, , March, 1996