idnits 2.17.1 draft-ietf-pkix-cmc-01.txt: ** The Abstract section seems to be numbered -(637): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(695): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 6 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 3) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([CRMF], [CRS], [CMS], [CMMF]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 15: '...hat other groups MAY also distribut wo...' RFC 2119 keyword, line 19: '...and MAY be updated, replaced, or obsol...' RFC 2119 keyword, line 151: '...ntaining PKIData SHALL be constrained ...' RFC 2119 keyword, line 153: '...handling logic SHOULD use the value id...' RFC 2119 keyword, line 154: '...s not used, id-data SHALL be used. In...' (72 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The first octets (the first characters of the first line) of this draft are 'PK', which can make Internet Explorer erroneously think that it is a zip file. It is recommended that you change this, for instance by inserting a blank line before the line starting with 'PK'. == Line 67 has weird spacing: '...cessing of th...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1998) is 9384 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CRS' is mentioned on line 34, but not defined == Missing Reference: 'CMMF' is mentioned on line 670, but not defined -- Looks like a reference, but probably isn't: '0' on line 145 == Missing Reference: 'DSA' is mentioned on line 213, but not defined == Missing Reference: 'ESS' is mentioned on line 277, but not defined == Unused Reference: 'PKCS7' is defined on line 750, but no explicit reference was found in the text == Unused Reference: 'PKCS10' is defined on line 753, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-smime-cms-01 -- Unexpected draft version: The latest known version of draft-hoffman-pkcs-crypt-msg is -02, but you're referring to -03. ** Downref: Normative reference to an Informational draft: draft-hoffman-pkcs-crypt-msg (ref. 'PKCS7') -- Unexpected draft version: The latest known version of draft-hoffman-pkcs-certif-req is -02, but you're referring to -03. ** Downref: Normative reference to an Informational draft: draft-hoffman-pkcs-certif-req (ref. 'PKCS10') == Outdated reference: A later version (-11) exists of draft-ietf-pkix-ipki-part1-09 -- Possible downref: Non-RFC (?) normative reference: ref. 'CRMF' Summary: 16 errors (**), 0 flaws (~~), 13 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PKIX Working Group Michael Myers (VeriSign) 2 Internet Draft Xiaoyi Liu (Cisco) 3 Barbara Fox (Microsoft) 4 Jeff Weinstein (Netscape) 6 expires in six months August 1998 8 Internet X.509 Certificate Management Messages over CMS 9 11 1. Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, and 15 its working groups. Not that other groups MAY also distribut working 16 documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and MAY be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference material 21 or to cite them other than as "work in progress." 23 To learn the current status of any Internet-Draft, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Di- 25 rectories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munari.oz.au 26 Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West 27 Coast). 29 2. Abstract 31 This document defines the means by which PKI clients and servers may 32 exchange PKI messages when using the Cryptographic Message Syntax [CMS] 33 as a transaction envelope. It extends concepts established in the draft 34 [CRS] version of this material by accommodating external specification 35 of message bodies in the Certificate Management Message Formats [CMMF] 36 and Certificate Request Message Format [CRMF] documents. Mandatory 37 requirements are established which facilitate automated interoperability 38 between a wide variety of PKI clients and servers or services. Optional 39 features are defined to address more localized needs. 41 This draft is being discussed on the ''ietf-pkix'' mailing list. To 42 subscribe, send a message to ietf-pkix-request@tandem.com with the 43 single word "subscribe" in the body of the message. 45 3. Protocol Overview 47 This document defines a protocol by which PKI-specific messages can be 48 encapulsated within the CMS security framework. CMMF message bodies 49 secured by CMS are encapsulated either as PKIData content type or Data 50 content type. This encapsulation is in turn ultimately encapsulated by 51 a SignedData envelope. The authenticatedAttributes element of 52 SignedData is used to carry information useful to recipient processing 53 of CMS-encapsulated CMMF message bodies. These are collectively 54 referred to as "Service Indicators". 56 Two such indicators are MessageType (an attribute unique to this 57 specification) and ContentType (defined by [CMS]). 59 Processing systems, whether client or server: 61 1) Detects the presence of a PKI message. 62 2) Examines the value of MessageType; 63 3) Locates the PKI message within the CMS envelope; 64 4) Parses the content of PKI message in accordance with MessageType; and 65 5) Take action as appropriate to the message body content. 67 Successful processing of the message may depend in part upon other 68 authenticated attributes within the SignedData envelope. 70 3.1 Transactions 72 A transaction is composed of the exchange of request-response message 73 pairs between a server and a client. This document establishes 74 requirements on four such transactions. These are: 76 1. Certification of a public key; 77 2. Query on status of certificate request; 78 3. Certificate and CRL retrieval; 79 4. Certificate revocation. 81 A public key certification request is formed either as a PKCSReq object 82 or CRMF; the [CMMF] document identifies both. PKCSReq enables use of 83 PKCS10-based certificate requests while CRMF anticipates a richer set of 84 requirements than can be met by PKCS10. The corresponding response is 85 either by CertResponse or CertRepContent as defined in CMMF. The 86 CertResponse message body incorporates the familiar PKCS7 degenerate 87 signedData mode of certificate delivery while CertRepContent provides 88 equivalent capability and enables CA generation of subscriber key pairs. 90 The certificate and CRL retrieval request mechanism is used to assist 91 state recovery within resource-constrained PKI clients. This may be the 92 case, for example, within low-end IP routers implementing IPSEC which by 93 reasons of design do not retain such data in non-volatile memory. 95 The certificate request status query can be used as a simple means to 96 maintain synchronicity with a certificate server during the certificate 97 production process. This message would typically be used in a situation 98 where the certificate requesting system holds itself in a wait state 99 during the processing of certificate request. 101 The revocation request transaction enables programmatic processing of 102 revocation requests. It further provides for non-cryptographic 103 authentication of the requester in the event that the key being revoked 104 would otherwise be relied upon to authenticate the originator of a 105 revocation message. This capability is useful in the event of a key 106 compromise. 108 3.2 Interior Encapsulation of PKI Messages 110 The inner-most content type used encapsulate PKIData (i.e. CRMF or CMMF 111 message bodies) is either id-pkix-crs or id-data. PKIData is used with 112 SignedData to define a transaction-based protocol. EnvelopedData may be 113 used in conjunction with SignedData to provide privacy. The following 114 figure illustrates the relationship between PKIData and SignedData in 115 the case of an unencrypted message (section 4.3 discusses encryption 116 options): 118 |---------------------------------------| 119 |SIGNED DATA | 120 | -----------------------------------| 121 | |id-pkix-crs or id-data | - content type value 122 | | message body | - as defined in CMMF 123 |---------------------------------------| 124 | ORIGINATOR'S CERTIFICATES | 125 |---------------------------------------| 126 | AUTHENTICATED ATTRIBUTES | - service indicators 127 | Hash of Content | 128 | content hint | - id-pkix-crs 129 | version | - version number 130 | message type | - indicates msg body syntax 131 | transaction status | - general status 132 | failure info | - failure context 133 | transaction identifier | - optional 134 | sender nonce | - optional 135 | recipient nonce | - optional 136 |---------------------------------------| 137 | Message Signature | - produced by originator 138 |---------------------------------------| 140 Section 3 of [CMS] establishes the following general syntax for CMS 141 content types: 143 ContentInfo ::= SEQUENCE { 144 contentType ContentType, 145 content [0] EXPLICIT ANY DEFINED BY contentType } 147 ContentType ::= OBJECT IDENTIFIER 149 For the purposes of the CMC protocol, the content field of ContentInfo 150 will contain PKIData. The value of contentType of a ContentInfo 151 containing PKIData SHALL be constrained as follows. Applications that 152 use CMS content types to detect and route content to appropriate 153 handling logic SHOULD use the value id-pkix-crs to identify the presence 154 of PKIData. If id-pkix-crs is not used, id-data SHALL be used. In 155 either case, the specific syntax contained within PKIData is indicated 156 by the MessageType attribute in an encapsulated SignedData content type. 158 Transactions can be identified and tracked using a transaction 159 identifier. If used, clients generate transaction identifiers and 160 retain their value until the server responds with a message that 161 completes the transaction. Servers correspondingly include received 162 transaction identifiers in the response. Section 5.5 establishes 163 requirements on the use of TransactionID. 165 Replay protection is supported through the use of sender and recipient 166 nonces. If used, clients generate a nonce value and include it in the 167 request as a sender nonce. Servers return this value as recipient nonce 168 along their own value for sender nonce. 170 This specification makes no assumptions about the underlying transport 171 mechanism. The use of CMS is not meant to imply an email-based 172 transport. 174 Requests and responses are composed of a message body and one or more 175 Service Indicators. Service Indicators are encoded as a set of 176 authenticated attributes of a CMS SignedData construction. The message 177 digest of message body is then signed together with the Service 178 Indicators using the message originator's private signing key, producing 179 the message signature. 181 4. Protocol Requirements 183 4.1 PKCS7 Interoperability 185 CMS differs from PKCS7 in that it: 187 - adds to EnvelopedData an OPTIONAL originatorInfo field preceding 188 recipientInfo; 189 - replaces the issuerAndSerial field of recipientInfos with a CHOICE 190 of alternative recipient key identification mechanisms. 192 Clients MAY include the optional OriginatorInfo field of the CMS 193 EnvelopedData syntax when submitting PKI transaction requests. If the 194 intended recipient is unable to receive this optional syntax, an error 195 response message SHALL be generated per Section 4.3.1. 197 Clients SHALL be capable of receiving and servers SHALL be capable of 198 processing the issuerAndSerialNumber CHOICE of the rid (recipient 199 identifer) syntax for RecipientInfos. The corresponding 200 RecipientKeyIdentifier is optional within this specification. 202 As noted in [CMS], if RecipientKeyIdentifier is used, the value for 203 version in EnvelopedData SHALL be 2; if issuerAndSerialNumber CHOICE is 204 used, the value for version SHALL be 0. 206 The specification of CMS ensures that EnvelopedData productions with a 207 version of 0 will successfully interoperate with systems implemented in 208 accordance with PKCS7. 210 4.2 Mandatory and Optional Algorithms 212 Clients and servers SHALL be capable of producing and processing 213 message signatures using the Digital Signature Algorithm [DSA]. DSA 214 signatures SHALL be indicated by the DSA AlgorithmIdentifier value 215 specified in section 7.2.2 of PKIXCERT. Clients and servers SHOULD 216 also be capable of producing and processing RSA signatures as specified 217 in section 7.2.1 of PKIXCERT. 219 Clients and servers SHALL be capable of protecting and accessing 220 message encryption keys using the Diffie-Hellman (D-H) key exchange 221 algorithm. D-H protection SHALL be indicated by the D-H 222 AlgorithmIdentifier value specified in CMS. Clients and servers 223 SHOULD also be capable of producing and processing RSA key transport. 224 When used for PKI messages, RSA key transport SHALL be indicated as 225 specified in section 7.2.1 of PKIXCERT. 227 4.3 Use of EnvelopedData 229 Two options exist with respect to the use of EnvelopedData. One usage 230 produces an encrypted message body encapsulated by SignedData. The 231 other option is the inverse of this relationship, as the following 232 figure illustrates. 234 Option 1 Option 2 235 -------- -------- 236 SignedData EnvelopedData 237 EnvelopedData SignedData 238 PKIData PKIData 239 241 The second option benefits organizations that wish to protect against 242 the leakage of sensitive data via the cleartext SignedData envelope. 244 Message bodies MAY be encrypted or transmitted in the clear. Support 245 SHALL be provided for encryption option 1 and SHOULD be provided for 246 both. 248 4.4 Requirements on Message Construction 250 The exact processing sequence used to construct a message could vary by 251 application. The results SHALL however be structurally equivalent to 252 the following procedure: 254 A [CMMF] message body is constructed in accordance with this 255 specification and any additional requirements asserted in [CMMF] 256 regarding a given message body. This message body is then identified as 257 a contentType as defined in section 4.3, yielding PKIData. 259 If PKIData is to be encrypted, then either an EnvelopedData content type 260 is constructed which contains the PKIData--which is in turn enveloped by 261 SignedData as an outermost CMS envelope--or a SignedData content type is 262 constructed which is subsequently encapsulated by EnvelopedData as the 263 outermost CMS envelope. The decision on which to use is optional to the 264 implementor, although section 5.3 establishes the requirement that all 265 implementors shall at least enable the former (i.e. SignedData <- 266 Enveloped Data <- PKIData). 268 If PKIData is to be transmitted in cleartext form, then a SignedData is 269 contructed with PKIData as the content and id-signedData as the 270 contentType of the outermost CMS envelope. 272 The SignerInfos portion of SignedData carries one or more Service 273 Indicators as authenticatedAttributes. In all cases the presence of a 274 particular message body type SHALL be indicated by value of the 275 messageType Service Indicator. In addition, a value of id-pkix-crs as 276 defined in [PKIXCERT] MAY be assigned to a contentHint authenticated 277 attribute as defined in [ESS]. 279 The value of authenticatedAttributes is hashed using the algorithm 280 specified by digestAlgorithm, signed using the message originator's 281 private key corresponding to digestEncryptionAlgorithm, the result 282 encoded as an OCTET STRING and assigned to the encryptedDigest field of 283 SignedData. 285 The following illustrates the intended relationship between the relevant 286 syntactic elements: 288 Encryption 0ption 1: (signedData <- envelopedData <- pkiData ) 290 signedData.encapContentInfo.eContentType <- id-envelopedData 291 signedData.authenticatedAttributes.contentHint <- id-pkix-crs 292 signedData.authenticatedAttributes.messageType <- CMMF message type 293 envelopedData.encryptedContentInfo.contentType <- id-pkiData 294 envelopedData.encryptedContentInfo.encryptedContent <- encrypted CMMF 295 message body 297 Encryption option 2: (envelopedData <- signedData <- pkiData ) 299 envelopedData.encryptedContentInfo.contentType <- id-signedData 300 envelopedData.encryptedContentInfo.encryptedContent <- encr. signedData 301 signedData.authenticatedAttributes.contentHint <- id-pkix-crs 302 signedData.authenticatedAttributes.messageType <- CMMF message type 303 signedData.encapContentInfo.eContentType <- id-pkiData 304 signedData.encapContentInfo.eContent <- CMMF message body 306 The cleartext version is: (signedData <- pkiData) 308 signedData.authenticatedAttributes.contentHint <- id-pkix-crs 309 signedData.authenticatedAttributes.messageType <- CMMF message type 310 signedData.encapContentInfo.eContentType <- id-pkiData 311 signedData.encapContentInfo.eContent <- CMMF message body 313 4.5 Service Indicators 315 The following Service Indicators are defined by this specification. 317 - version 318 - messageType 319 - pkiStatus 320 - failinfo 321 - transactionId 322 - senderNonce 323 - recipientNonce 325 In addition to the above, [CMS] requires inclusion of the following: 327 - A content-type attribute having as its value the content type 328 of the ContentInfo value being signed. 330 - A message-digest attribute, having as its value the message 331 digest of the content. 333 In addition, clients MAY include provisions for SigningTime, 334 counterSignature and contentHint attributes. Servers SHOULD be capable 335 of accepting PKIData messages containing such attributes. 337 Each Service Indicator is uniquely identified by an Object Identifier. 338 Processing systems would first detect the OID and process the 339 corresponding service indicator value prior to processing the message 340 body. PKIXCERT establishes a registration arc for objects associated 341 with certificate management protocols. The value of id-it is imported 342 from that reference. This specification extends id-it as follows: 344 id-it OBJECT IDENTIFIER ::= { id-pkix 4 } -- imported from PKIX 345 id-si OBJECT IDENTIFIER ::= { id-it 1 } -- cmc service indicators 347 -- service indicators 349 id-si-version OBJECT IDENTIFIER ::= { id-si 1 } 350 id-si-transactionID OBJECT IDENTIFIER ::= { id-si 2 } 351 id-si-messageType OBJECT IDENTIFIER ::= { id-si 3 } 352 id-si-pkiStatus OBJECT IDENTIFIER ::= { id-si 4 } 353 id-si-failInfo OBJECT IDENTIFIER ::= { id-si 5 } 354 id-si-senderNonce OBJECT IDENTIFIER ::= { id-si 6 } 355 id-si-recipientNonce OBJECT IDENTIFIER ::= { id-si 7 } 357 The corresponding value syntax for each is: 359 Service Indicator Syntax 360 ----------------- ------- 361 version INTEGER 362 messageType INTEGER 363 pkiStatus INTEGER 364 failInfo INTEGER 365 TransactionId INTEGER 366 senderNonce OCTET STRING 367 recipientNonce OCTET STRING 369 If version is absent, a value of 0 SHALL be assumed. This draft 370 specifies version 1. 372 The messageType service indicator identifies the syntax carried in the 373 message body. Every message SHALL include a value for messageType 374 appropriate to the message. 376 The pkiStatus service indicator is used to convey information relevant 377 to a requested operation. This service indicator SHALL be included in 378 every message. 380 The failInfo service indicator conveys information relevant to the in- 381 terpretation of a failure condition. This service indicator is mandatory 382 in every message. 384 If the status in the response is FAILURE, then the failinfo service in- 385 dicator SHALL contain one of the failure reasons defined in Section 386 5.4.1 "Specific Values". Additional failure reasons MAY be defined for 387 environments with a need. 389 If additional transaction management or replay protection is desired, 390 transactionID, senderNonce and recipientNonce MAY be implemented. 392 The transactionId service indicator identifies a given transaction. It 393 is used between client and server to manage the state of an operation. 394 It MAY be included in service request messages. If included, responses 395 SHALL include the transmitted value. Correspondingly, clients SHOULD 396 implement and recognize transactionID while servers or services SHALL 397 implement and recognize transactionID. 399 The senderNonce and recipientNonce service indicator can be used to 400 provide application-level replay prevention. They MAY be included in 401 service request messages. Originating messages SHALL include only a 402 value for senderNonce. If included in originating messages, responses 403 SHALL include the transmitted value of the previously received 404 senderNonce as recipientNonce and include a value for senderNonce. 406 If nonces are used, in the first message of a transaction, no recipient- 407 Nonce is transmitted; a senderNonce is instantiated by the message 408 originator and retained for later reference. 410 If a transaction originator includes a value for the senderNonce service 411 indicator, responses SHALL include this value as a value for recipient- 412 Nonce AND include a value for the SenderNonce service indicator. 414 Upon receipt by the transaction originator of response containing a 415 value for recipientNonce, the originator compares the value of 416 recipientNonce to its retained value. If the values match, the message 417 can be accepted for further security processing. The received value for 418 senderNonce is also retained for inclusion in the next message 419 associated with the same transaction. 421 4.5.1 Specific Values 423 This specification establishes requirements regarding the implementation 424 of message formats defined in [CMMF]. The following values for 425 MessageType service indicator SHALL be used to identify the indicated 426 message body type: 428 Message MessageType Value Legacy Value 429 ------- ----------------- ------------ 430 PKCSReq 1 19 431 CertReqMessages 2 432 CertRep 3 433 CertRepContent 4 434 GetCert 5 21 435 GetCertInitial 6 436 GetCRL 7 22 437 RevRequest 8 438 RevReqContent 9 439 RevRepContent 10 440 CAKeyUpdAnnContent 11 441 CertAnnContent 12 442 CRLAnnContent 13 443 RevAnnContent 14 444 KeyRecRepContent 15 446 The pkiStatus field may take on any one of the following values: 448 Status pkiStatus value 449 ------- --------------- 450 SUCCESS 0 451 PENDING 1 452 FAILURE 2 454 The following values for failInfo are defined for the identified 455 context. 457 BADALG 0 -- Unrecognized or unsupported algorithm 458 BADMESSAGECHECK 1 -- integrity check failed 459 BADREQUEST 2 -- transaction not permitted or supported 460 BADTIME 3 -- Message time field was not sufficiently close 461 -- to the system time 462 BADCERTID 4 -- No certificate could be identified matching 463 -- the provided criteria 464 UNSUPPORTEDEXT 5 -- A requested X.509 extension is not supported 465 -- by the recipient CA. 466 BADTRANSID 6 -- Unrecognized transactionID 468 Additional contextual information regarding failure modes and reasons 469 may be provided within specific message bodies. 471 4.6 Additional Requirements on Use of Transaction ID 473 Upon receipt at a server or service of an initiating message containing 474 a TransactionID authenticated attribute, the value of TransactionID is 475 retained during message processing and included in the response message. 476 In general, the server may at that point delete retention of the 477 TransactionID from local memory. However, when a server issues a 478 PENDING status against a request, the server SHALL retain the value of 479 TransactionID until the transaction completes, at which point either a 480 SUCCESS or FAILURE message is returned to the requestor. The PENDING 481 status SHALL contain the value of TransactionID supplied in the request 482 if one exists. If the requestor did not supply a transactionID, the 483 server SHALL produce a TransactionID value and return this value in the 484 PENDING response. 486 During the PENDING interval, the server may receive a query against the 487 status of the transaction (see, for example, Section 5.7.4 489 GetCertInitial). If the identified transaction is still pending, the 490 server SHALL respond with another PENDING response containing the 491 previously stored value for TransactionID. If however no transaction is 492 in a PENDING state that matches the TransactionID specified in a status 493 query, the server SHALL respond with an empty PKIData envelope (i.e. no 494 message body) containing the value of FAILURE for pkiStatus and 495 BADTRANSID for failInfo. 497 4.7 Requirements on Data Origin Authenticity 499 All messages SHALL be digitally signed. 501 Prior to accepting a message as valid, clients, servers or services 502 SHALL confirm that: 504 1. The signature on the request is valid; and 505 2. The certificate used to validate the signature is not revoked. 507 In the instance when the request is a certification request of a 508 signature public key originating directly from an end-entity, the 509 signature should not be relied upon as an assertion of authenticity of 510 the attributes contained in the request. This authentication is 511 function of the CA�s role upon receipt of a certification request. 513 Prior to accepting a response as valid, clients SHALL confirm that: 515 1. The response corresponds to a former request; and 516 2. The identity of the response originator matches the intended 517 recipient of the prior request. 519 4.8 Requirements on Use of CRMF and CMMF 521 The following table establishes implementation requirements on the 522 implementation of message bodies as defined in [CRMF] and [CMMF]. 523 Unless otherwise identified in the table, CMC implementations MAY 524 implement additional CMMF messages to meet the needs of specific 525 environments. 527 Message SHALL SHOULD 528 ------- ----- ------ 529 PKCSReq X 530 CertReqMessages X 531 CertRep X 532 GetCert X 533 GetCertInitial X 534 GetCRL X 535 RevRequest X 536 The following sections establish additional requirements on the use of 537 some message bodies. 539 4.8.1 PKCSReq 541 As defined in [CMMF], a PKCSReq message consists of a PKCS10 certificate 542 signing request and additional registration information. The PKCS10 543 field SHOULD contain a ChallengePassword attribute generated by the 544 owner of the private key. It MAY contain an optional ExtensionReq 545 attribute used to indicate to the server one or more PKIXCERT 546 certificate extensions. It MAY contain additional attributes as 547 specified by PKCS9. 549 Some products are operated in a fashion that assigns subject names from 550 a central repository of information upon receipt of a public key for 551 certification. To accommodate this mode, the value of subject name in a 552 PKCSReq MAY be zero length but the field MUST be present. 554 CMS requires that the signerInfo contain a issuerNameSerialNumber value; 555 however for this transaction, the certificate has yet to be issued and 556 therefore the serialNumber has not yet been assigned. Thus the 557 issuerName and SerialNumber value in the signerInfo element of PKCSReq 558 SHALL be set to NULL and zero, respectively. 560 4.8.2 Use of RegInfo in PKCSReq 562 The RegInfo field of a PKCSReq request MAY contain additional 563 information relevant to the request. This information is supplied 564 external to the PKCS10 object and as such is not a component of the 565 proof of possession calculation (see [CMMF]). 567 The RegInfo field is intended to consist of name-value pairs. Appendix 568 B.1 of [CRMF] defines some standard name-value pairs and associated 569 encoding mechanisms. Clients SHALL use those mechanisms when using the 570 RegInfo field of PKCSReq to address the requirements met by the elements 571 defined in CRMF Appendix B.1. Additional name-value pairs MAY be 572 defined for environments with a need. 574 4.8.3 CertRep 576 A CertRep message is the response to a CertReqMessages, PKCSReq, GetCert 577 or GetCRL. It is defined in [CMMF]. 579 The following requirements pertain to the construction of CertRep 580 message in response to receipt of PKCSReq message: 582 CertRep message consists of one or more certificates and an associated 583 RspInfo field. The certificate(s) are contained in the response field. 584 This field is a SignedData CMS content type with no ContentInfo or 585 SignerInfos fields. Section 5.1 of CMS further describes this 586 particular construction. In particular, although the SignedData 587 construct is used, no signature is produced. 589 If the value of pkiStatus service indicator in a CertRep message is 590 SUCCESS, the response field SHALL contain the requested certificate(s) 591 and MAY contain additional non-root CA certificates related to the 592 validation of the requested certificate(s). 594 If the value of pkiStatus service indicator in a CertRep message is 595 PENDING or FALURE, the response field SHALL be excluded. 597 In all cases, the rspInfo field of CertRep MAY contain additional 598 information useful to the application receiving the message in the form 599 of name-value pairs. Other additional data could include detailed error 600 information that uniquely identifies an information field supplied in 601 the original regInfo field of a PKCSReq; e.g. the Zip Code was incorrect 602 for the specified address or locale or billing failed because credit 603 card information was in error. 605 CAs that receive a PKCSReq with a null subject name MAY reject such 606 requests. If rejected, the CA SHALL respond with a CertRep message with 607 pkiStatus of FAILURE and failInfo value of BADREQUEST. 609 The client MAY incorporate one or more standard X.509 v3 extensions in 610 the request as defined in [CMMF]. Servers are not required to be able to 611 process every v3 X.509 extension transmitted using this protocol, nor 612 are they required to be able to process other, private extensions. 613 However, in the circumstance when a certification request is denied due 614 to the inability to handle a requested extension, the server SHALL 615 respond with a CertRep message indicating FAILURE and a corresponding 616 FailureInfo field with the value of UNSUPPORTEDEXT. 618 4.8.4 GetCertInitial 620 The GetCertInitial message is used to poll for the certificate 621 associated with prior PKCSReq request if the response to that prior 622 request was a CertRep message with a status of PENDING. 624 Certificates are normally referenced using the CA DN and the certificate 625 serial number. In this case however a certificate has not yet been 626 issued. Thus the CA and Subject DNs are present in the message as a 627 means to identify the requested certification. [CMMF] defines this 628 syntax. 630 Clients that implement GetCertInitial SHALL conform to the requirements 631 on use of the TransactionID service indicator as defined in Section 632 5.4.2. 634 4.8.5 GetCert 636 This operation is used to retrieve certificates from a certificate 637 server or service�s repository. This message is useful in circumstances 638 where a fully-deployed Directory is either infeasible or undesired. 639 Additionally, certificate retrieval requests may be used by resource- 640 constrained clients to recover their public key in the event of a device 641 reset. This could be the case within low-end IP routers that do not 642 retain their certificates in non-volatile memory. 644 The GetCert message body consists of the CertID syntax defined in 645 [CMMF]. For reference, this syntax is: 647 CertID ::= SEQUENCE { 648 issuerName GeneralName, 649 serialNumber INTEGER } 651 The response to a GetCert message SHALL consist of CertRep message 652 containing a signedData response containing the requested certificate as 653 defined in [CMMF]. 655 4.8.6 GetCRL 657 This operation is used to retrieve CRLs from a CA's repository. In order 658 to provide clients a convenient means of determining the network address 659 needed to acquire a CA's CRL, servers and clients SHOULD be capable of 660 producing and processing the CRLDistributionPoints certificate extension 661 as defined in [PKIXCERT]. 663 The response to a GetCRL message SHALL consist of CertRep message 664 containing only a value for CRLs as a component of a �degenerate� 665 SignedData rather than the certificates component. Contents for the 666 rspInfo field of CertRep MAY be included. 668 4.8.7 RevReq 670 [CMMF] defines the syntax of a RevReq (revocation request). For 671 reference, a RevReq message body consists of: 673 - name of the certificate issuer 674 - serial number of the certificate to be revoked 675 - a reason code 676 - an optional passphrase 677 - an optional comment field 679 For a revocation request to become a reliable object in the event of a 680 dispute, a strong proof of originator authenticity is required. A 681 Registration Authority�s digital signature on the request can provide 682 this proof for certificates within the scope of the RA�s revocation 683 authority. The means by which an RA is delegated this authority is a 684 matter of operational policy. 686 However, in the instance when an end-entity has lost use of their 687 signature private key, it is impossible to produce a reliable digital 688 signature. The PKCSReq message provides for the optional transmission 689 from the CA to the end-entity of a passphrase which may be used as an 690 alternative authenticator in the instance of loss of use. The 691 acceptability of this practice is a matter of local security policy. 693 Clients SHALL provide the capability to produce a digitally signed 694 RevReq message. Clients SHOULD provide the capability produce an 695 unsigned revocation request containing the end-entity�s passphrase. If 696 a client provides passphrase-based self-revocation, the client SHALL be 697 capable of producing a PKCSReq containing a passphrase. 699 The structure of an unsigned, passphrase-based RevReq is a matter of 700 local implementation. Since such a message has no relationship to the 701 use of cryptography, the use of CMS to convey this message is not 702 required. 704 The response to a RevReq message SHALL consist of CertRep message with 705 the following characteristics: 707 Success: 708 1. The pkiStatus service indicator SHALL contain a value of SUCCESS. 709 2. The response field of the CertRep message body MAY be included. If 710 so, it SHALL contain the updated CRL relevant to the subject 711 certificate. 713 Failure: 714 1. The pkiStatus service indicator SHALL contain a value of FAILURE. 715 2. The failInfo service indicator shall be set to the appropriate reason 716 code. 717 3. The response field of the CertRep message body SHALL be excluded. 719 In either case, the rspInfo field of CertRep message body MAY be 720 included. If so, it SHALL contain additional information relevant to 721 the interpretation of the failure. 723 5. Security Considerations 725 Initiation of a secure communications channel between an end-entity and 726 a CA necessarily requires an out-of-band trust initiation mechanism. For 727 example, a secure channel may be constructed between the end-entity and 728 the CA via IPSEC or TLS. Many such schemes exist and the choice of any 729 particular scheme for trust initiation is outside the scope of this 730 document. Implementors of this protocol are strongly encouraged to 731 consider generally accepted principles of secure key management when 732 integrating this capability within an overall security architecture. 734 Mechanisms for thwarting replay attacks may be required in particular 735 implementations of this protocol depending on the operational 736 environment. In cases where CAs maintain significant state information 737 themselves, replay attacks may be detectable without the inclusion of 738 the optional nonce mechanisms. Implementors of this protocol need to 739 carefully consider environmental conditions before choosing whether or 740 not to implement the senderNonce and recipientNonce service indicators 741 described in section 4.3.1. Developers of state-constrained PKI clients 742 are strongly encouraged to incorporate the use of these service 743 indicators. 745 6. References 747 [CMS] R. Housley, "Cryptographic Message Syntax", 748 draft-ietf-smime-cms-01.txt, October 1997 750 [PKCS7] B. Kaliski, "PKCS #7: Cryptographic Message Syntax v1.5", 751 draft-hoffman-pkcs-crypt-msg-03.txt, October 1997 753 [PKCS10] B. Kaliski, "PKCS #10: Certification Request Syntax v1.5", 754 draft-hoffman-pkcs-certif-req-03.txt, October 1997 755 [PKIXCERT] R. Housley, W. Ford, W. Polk, D. Solo "Internet Public 756 Key Infrastructure X.509 Certificate and CRL Profile", 757 draft-ietf-pkix-ipki-part1-09.txt, July, 1998 759 [CRMF] M. Myers, C. Adams, D. Solo, D. Kemp, 760 Certificate Request Message Format, 761 , May, 1998 763 9. Author's Addresses 765 Michael Myers 766 VeriSign, Inc. 767 1390 Shorebird Way 768 Mountain View, CA, 94019 769 (650) 429-3402 770 mmyers@verisign.com 772 Xiaoyi Liu 773 Cisco Systems 774 170 West Tasman Drive 775 San Jose, CA 95134 776 (480) 526-7430 777 xliu@cisco.com 779 Barbara Fox 780 Microsoft Corporation 781 One Microsoft Way 782 Redmond, WA 98052 783 (425) 936-9542 784 bfox@microsoft.com 786 Jeff Weinstein 787 Netscape Communications Corporation 788 501 Middlefield Road 789 Mountain View, CA 94043 790 jsw@netscape.com