idnits 2.17.1 draft-ietf-pkix-cmc-00.txt: ** The Abstract section seems to be numbered -(383): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(642): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(700): 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-26) 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 9 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 is 1 instance 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 183: '...EnvelopedData an OPTIONAL originatorIn...' RFC 2119 keyword, line 188: '...Clients MAY include the optional Origi...' RFC 2119 keyword, line 191: '...response message SHALL be generated pe...' (69 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 (March 1998) is 9539 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 675, but not defined -- Looks like a reference, but probably isn't: '0' on line 143 == Missing Reference: 'DSA' is mentioned on line 211, but not defined == Unused Reference: 'PKCS7' is defined on line 755, but no explicit reference was found in the text == Unused Reference: 'PKCS10' is defined on line 758, 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-06 -- Possible downref: Non-RFC (?) normative reference: ref. 'CRMF' Summary: 17 errors (**), 0 flaws (~~), 10 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SMIME Working Group Michael Myers (VeriSign) 2 Internet Draft Xiaoyi Liu (Cisco) 3 Barbara Fox (Microsoft) 4 Jeff Weinstein (Netscape) 6 expires in six months March 1998 8 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), ds.internic.net (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 A new CMS content type, PKIData, is defined within the more general CMS 48 security encapsulation framework. CMMF message bodies secured by CMS 49 are encapsulated within the PKIData content type. PKIData is in turn 50 ultimately encapsulated by a SignedData envelope. The 51 authenticatedAttributes element of SignedData is used to carry 52 information useful to recipient processing of CMS-encapsulated CMMF 53 message bodies. These are collectively referred to as �Service 54 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) Detect the presence of PKIData by examination of ContentType; 62 2) Examine the value of MessageType; 63 3) Locate the PKIData construct within the CMS message; 64 4) Parse the content of PKIData 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 PKIData 109 PKIData is an inner-most content type used to encapsulate CMMF message 110 bodies. PKIData is used with SignedData to define a transaction-based 111 protocol. EnvelopedData may be used in conjunction with SignedData to 112 provide privacy. The following figure illustrates the relationship 113 between PKIData and SignedData in the case of an unencrypted message 114 (section 4.3 discusses encryption options): 116 |---------------------------------------| 117 |SIGNED DATA | 118 | -----------------------------------| 119 | |PKIData | 120 | | message body | - as defined in CMMF 121 |---------------------------------------| 122 | ORIGINATOR'S CERTIFICATES | 123 |---------------------------------------| 124 | AUTHENTICATED ATTRIBUTES | - service indicators 125 | Hash of Content | 126 | content type | - identifies PKIData 127 | version | - version number 128 | message type | - indicates msg body syntax 129 | transaction status | - general status 130 | failure info | - failure context 131 | transaction identifier | - optional 132 | sender nonce | - optional 133 | recipient nonce | - optional 134 |---------------------------------------| 135 | Message Signature | - produced by originator 136 |---------------------------------------| 138 Section 3 of [CMS] establishes the following general syntax for CMS 139 content types: 141 ContentInfo ::= SEQUENCE { 142 contentType ContentType, 143 content [0] EXPLICIT ANY DEFINED BY contentType } 145 ContentType ::= OBJECT IDENTIFIER 147 The PKIData content type can be recognized using the following OID: 149 id-pkiData OBJECT IDENTIFER ::= id-pkix-crs -- defined in [PKIXCERT] 151 The specific syntax contained within a PKIData is indicated by the 152 MessageType attribute in an encapsulated SignedData content type. 154 Transactions can be identified and tracked using a transaction 155 identifier. If used, clients generate transaction identifiers and 156 retain their value until the server responds with a message that 157 completes the transaction. Servers correspondingly include received 158 transaction identifiers in the response. Section 5.5 establishes 159 requirements on the use of TransactionID. 161 Replay protection is supported through the use of sender and recipient 162 nonces. If used, clients generate a nonce value and include it in the 163 request as a sender nonce. Servers return this value as recipient nonce 164 along their own value for sender nonce. 166 This specification makes no assumptions about the underlying transport 167 mechanism. The use of CMS is not meant to imply an email-based 168 transport. 170 Requests and responses are composed of a message body and one or more 171 Service Indicators. Service Indicators are encoded as a set of 172 authenticated attributes of a CMS SignedData construction. The message 173 digest of message body is then signed together with the Service 174 Indicators using the message originator's private signing key, producing 175 the message signature. 177 4. Protocol Requirements 179 4.1 PKCS7 Interoperability 181 CMS differs from PKCS7 in that it: 183 - adds to EnvelopedData an OPTIONAL originatorInfo field preceding 184 recipientInfo; 185 - replaces the issuerAndSerial field of recipientInfos with a CHOICE 186 of alternative recipient key identification mechanisms. 188 Clients MAY include the optional OriginatorInfo field of the CMS 189 EnvelopedData syntax when submitting PKI transaction requests. If the 190 intended recipient is unable to receive this optional syntax, an error 191 response message SHALL be generated per Section 4.3.1. 193 Clients SHALL be capable of receiving and servers SHALL be capable of 194 processing the issuerAndSerialNumber CHOICE of the rid (recipient 195 identifer) syntax for RecipientInfos. The corresponding 196 RecipientKeyIdentifier and MailListKeyIdentifier are optional within 197 this specification. 199 As noted in [CMS], if either RecipientKeyIdentifier or 200 MailListKeyIdentifier are used, the value for version in EnvelopedData 201 SHALL be 2; if issuerAndSerialNumber CHOICE is used, the value for 202 version SHALL be 0. 204 The specification of CMS ensures that EnvelopedData productions with a 205 version of 0 will successfully interoperate with systems implemented in 206 accordance with PKCS7. 208 4.2 Mandatory and Optional Algorithms 210 Clients and servers SHALL be capable of producing and processing 211 message signatures using the Digital Signature Algorithm [DSA]. DSA 212 signatures SHALL be indicated by the DSA AlgorithmIdentifier value 213 specified in section 7.2.2 of PKIXCERT. Clients and servers SHOULD 214 also be capable of producing and processing RSA signatures as specified 215 in section 7.2.1 of PKIXCERT. 217 Clients and servers SHALL be capable of protecting and accessing 218 message encryption keys using the Diffie-Hellman (D-H) key exchange 219 algorithm. D-H protection SHALL be indicated by the D-H 220 AlgorithmIdentifier value specified in CMS. Clients and servers 221 SHOULD also be capable of producing and processing RSA key transport. 222 When used for PKI messages, RSA key transport SHALL be indicated as 223 specified in section 7.2.1 of PKIXCERT. 225 4.3 Use of EnvelopedData 227 Two options exist with respect to the use of EnvelopedData. One usage 228 produces an encrypted message body encapsulated by SignedData. The 229 other option is the inverse of this relationship, as the following 230 figure illustrates. 232 Option 1 Option 2 233 -------- -------- 234 SignedData EnvelopedData 235 EnvelopedData SignedData 236 PKIData PKIData 237 239 The second option benefits organizations that wish to protect against 240 the leakage of sensitive data via the cleartext SignedData envelope. 242 Message bodies MAY be encrypted or transmitted in the clear. Support 243 SHALL be provided for encryption option 1 and SHOULD be provided for 244 both. 246 4.4 Requirements on Message Construction 248 The exact processing sequence used to construct a message could vary by 249 application. The results SHALL however be structurally equivalent to 250 the following procedure: 252 A [CMMF] message body is constructed in accordance with this 253 specification and any additional requirements asserted in [CMMF] 254 regarding a given message body. This message body is then enveloped as 255 id-pKIData as defined in section 4.3, yielding PKIData. 257 If PKIData is to be encrypted, then either an EnvelopedData content type 258 is constructed which contains the PKIData--which is in turn enveloped by 259 SignedData as an outermost CMS envelope--or a SignedData content type is 260 constructed which is subsequently encapsulated by EnvelopedData as the 261 outermost CMS envelope. The decision on which to use is optional to the 262 implementor, although section 5.3 establishes the requirement that all 263 implementors shall at least enable the former (i.e. SignedData <- 264 Enveloped Data <- PKIData). 266 If PKIData is to be transmitted in cleartext form, then a SignedData is 267 contructed with PKIData as the content and id-signedData as the 268 contentType of the outermost CMS envelope. 270 The SignerInfos portion of SignedData carries one or more Service 271 Indicators as authenticatedAttributes. In all cases the presence of a 272 particular message body type SHALL be indicated by value of the 273 messageType Service Indicator. 275 The value of authenticatedAttributes is hashed using the algorithm 276 specified by digestAlgorithm, signed using the message originator's 277 private key corresponding to digestEncryptionAlgorithm, the result 278 encoded as an OCTET STRING and assigned to the encryptedDigest field of 279 SignedData. 281 The following pseudocode fragment illustrates the intended relationship 282 between the relevant syntactic elements: 284 Encryption 0ption 1: (signedData <- envelopedData < pkiData ) 286 signedData.encapContentInfo.eContentType <- id-envelopedData 287 signedData.authenticatedAttributes.contentType <- id-pkiData 288 signedData.authenticatedAttributes.messageType <- CMMF message type 289 envelopedData.encryptedContentInfo.contentType <- id-pkiData 290 envelopedData.encryptedContentInfo.encryptedContent <- encrypted CMMF 291 message body 293 Encryption option 2: (envelopedData <- signedData <- pkiData ) 295 envelopedData.encryptedContentInfo.contentType <- id-signedData 296 envelopedData.encryptedContentInfo.encryptedContent <- encr. signedData 297 signedData.authenticatedAttributes.contentType <- id-pkiData 298 signedData.authenticatedAttributes.messageType <- CMMF message type 299 signedData.encapContentInfo.eContentType <- id-pkiData 300 signedData.encapContentInfo.eContent <- CMMF message body 302 The cleartext version is: (signedData <- pkiData) 304 signedData.authenticatedAttributes.contentType <- id-pkiData 305 signedData.authenticatedAttributes.messageType <- CMMF message type 306 signedData.encapContentInfo.eContentType <- id-pkiData 307 signedData.encapContentInfo.eContent <- CMMF message body 309 4.5 Service Indicators 311 The following Service Indicators are defined by this specification. 313 - version 314 - messageType 315 - pkiStatus 316 - failinfo 317 - transactionId 318 - senderNonce 319 - recipientNonce 320 In addition to the above, [CMS] requires inclusion of the following: 322 - A content-type attribute having as its value the content type 323 of the ContentInfo value being signed. With respect to this 324 specification, this value SHALL be id-pkiData regardless of the use of 325 EnvelopedData. 327 - A message-digest attribute, having as its value the message 328 digest of the content. 330 In addition, clients MAY include provisions for SigningTime and 331 counterSignature attributes. Servers SHOULD be capable of accepting 332 PKIData messages containing such attributes. 334 Each Service Indicator is uniquely identified by an Object Identifier. 335 Processing systems would first detect the OID and process the 336 corresponding service indicator value prior to processing the message 337 body. PKIXCERT establishes a registration arc for objects associated 338 with certificate management protocols. The value of id-it is imported 339 from that reference. This specification extends id-it as follows: 341 id-it OBJECT IDENTIFIER ::= { id-pkix 4 } -- imported from PKIX 342 id-si OBJECT IDENTIFIER ::= { id-it 1 } -- cmc service indicators 344 -- service indicators 346 id-si-version OBJECT IDENTIFIER ::= { id-si 1 } 347 id-si-transactionID OBJECT IDENTIFIER ::= { id-si 2 } 348 id-si-messageType OBJECT IDENTIFIER ::= { id-si 3 } 349 id-si-pkiStatus OBJECT IDENTIFIER ::= { id-si 4 } 350 id-si-failInfo OBJECT IDENTIFIER ::= { id-si 5 } 351 id-si-senderNonce OBJECT IDENTIFIER ::= { id-si 6 } 352 id-si-recipientNonce OBJECT IDENTIFIER ::= { id-si 7 } 354 The corresponding value syntax for each is: 356 Service Indicator Syntax 357 ----------------- ------- 358 version INTEGER 359 messageType INTEGER 360 pkiStatus INTEGER 361 failInfo INTEGER 362 TransactionId INTEGER 363 senderNonce OCTET STRING 364 recipientNonce OCTET STRING 366 If version is absent, a value of 0 SHALL be assumed. This draft 367 specifies version 1. 369 The messageType service indicator identifies the syntax carried in the 370 message body. Every message SHALL include a value for messageType 371 appropriate to the message. 373 The pkiStatus service indicator is used to convey information relevant 374 to a requested operation. This service indicator SHALL be included in 375 every message. 377 The failInfo service indicator conveys information relevant to the in- 378 terpretation of a failure condition. This service indicator is mandatory 379 in every message. 381 If the status in the response is FAILURE, then the failinfo service in- 382 dicator SHALL contain one of the failure reasons defined in Section 383 5.4.1 �Specific Values�. Additional failure reasons MAY be defined for 384 environments with a need. 386 If additional transaction management or replay protection is desired, 387 transactionID, senderNonce and recipientNonce MAY be implemented. 389 The transactionId service indicator identifies a given transaction. It 390 is used between client and server to manage the state of an operation. 391 It MAY be included in service request messages. If included, responses 392 SHALL include the transmitted value. Correspondingly, clients SHOULD 393 implement and recognize transactionID while servers or services SHALL 394 implement and recognize transactionID. 396 The senderNonce and recipientNonce service indicator can be used to 397 provide application-level replay prevention. They MAY be included in 398 service request messages. Originating messages SHALL include only a 399 value for senderNonce. If included in originating messages, responses 400 SHALL include the transmitted value of the previously received 401 senderNonce as recipientNonce and include a value for senderNonce. 403 If nonces are used, in the first message of a transaction, no recipient- 404 Nonce is transmitted; a senderNonce is instantiated by the message 405 originator and retained for later reference. 407 If a transaction originator includes a value for the senderNonce service 408 indicator, responses SHALL include this value as a value for recipient- 409 Nonce AND include a value for the SenderNonce service indicator. 411 Upon receipt by the transaction originator of response containing a 412 value for recipientNonce, the originator compares the value of 413 recipientNonce to its retained value. If the values match, the message 414 can be accepted for further security processing. The received value for 415 senderNonce is also retained for inclusion in the next message 416 associated with the same transaction. 418 4.5.1 Specific Values 420 This specification establishes requirements regarding the implementation 421 of message formats defined in [CMMF]. The following values for 422 MessageType service indicator SHALL be used to identify the indicated 423 message body type: 425 Message MessageType Value Legacy Value 426 ------- ----------------- ------------ 427 PKCSReq 1 19 428 CertReqMessages 2 429 CertRep 3 430 CertRepContent 4 431 GetCert 5 21 432 GetCertInitial 6 433 GetCRL 7 22 434 RevRequest 8 435 RevReqContent 9 436 RevRepContent 10 437 CAKeyUpdAnnContent 11 438 CertAnnContent 12 439 CRLAnnContent 13 440 RevAnnContent 14 441 KeyRecRepContent 15 443 The pkiStatus field may take on any one of the following values: 445 Status pkiStatus value 446 ------- --------------- 447 SUCCESS 0 448 PENDING 1 449 FAILURE 2 451 The following values for failInfo are defined for the identified 452 context. 454 BADALG 0 -- Unrecognized or unsupported algorithm 455 BADMESSAGECHECK 1 -- integrity check failed 456 BADREQUEST 2 -- transaction not permitted or supported 457 BADTIME 3 -- Message time field was not sufficiently close 458 -- to the system time 459 BADCERTID 4 -- No certificate could be identified matching 460 -- the provided criteria 461 UNSUPPORTEDEXT 5 -- A requested X.509 extension is not supported 462 -- by the recipient CA. 463 BADTRANSID 6 -- Unrecognized transactionID 465 Additional contextual information regarding failure modes and reasons 466 may be provided within specific message bodies. 468 4.6 Additional Requirements on Use of Transaction ID 470 As state earlier, servers or services are required to support use of 471 TransactionID by clients. Upon receipt of an initiating message at a 472 server or service, the value of TransactionID is retained during message 473 processing and included in the response message. In general, the server 474 may at that point delete retention of the TransactionID from local 475 memory. 477 However, when a server issues a PENDING status against a request, the 478 server SHALL retain the value of TransactionID until the transaction 479 completes, at which point either a SUCCESS or FAILURE message is 480 returned to the requestor. The PENDING status SHALL contain the value 481 of TransactionID supplied in the request if one exists. If the 482 requestor did not supply a transactionID, the server SHALL produce a 483 TransactionID value and return this value in the PENDING response. 485 During the PENDING interval, the server may receive a query against the 486 status of the transaction (see, for example, Section 5.7.4 487 GetCertInitial). If the identified transaction is still pending, the 488 server SHALL respond with another PENDING response containing the 489 previously stored value for TransactionID. If however no transaction is 490 in a PENDING state that matches the TransactionID specified in a status 491 query, the server SHALL respond with an empty PKIData envelope (i.e. no 492 message body) containing the value of FAILURE for pkiStatus and 493 BADTRANSID for failInfo. 495 4.7 Requirements on Data Origin Authenticity 497 All messages SHALL be digitally signed. 499 Prior to accepting a message as valid, clients, servers or services 500 SHALL confirm that: 502 1. The signature on the request is valid; and 503 2. The certificate used to validate the signature is not revoked. 505 In the instance when the request is a certification request of a 506 signature public key originating directly from an end-entity, the 507 signature SHOULD be presumed valid until such time as the recipient CA 508 determines the authenticity of the attributes claimed in the 509 certification request. 511 Prior to accepting a response as valid, clients SHALL confirm that: 513 1. The response corresponds to a former request; and 514 2. The identity of the response originator matches the intended 515 recipient of the prior request. 517 4.8 Requirements on Use of CRMF and CMMF 519 Clients and servers SHALL implement the following subset of message 520 bodies as defined in [CRMF] and [CMMF]. They MAY implement additional 521 messages to meet the needs of specific environments. 523 Message Mandatory 524 ------- --------- 525 PKCSReq X 526 CertReqMessages 527 CertRep X 528 CertRepContent 529 GetCert X 530 GetCertInitial X 531 GetCRL X 532 RevRequest X 533 RevReqContent 534 RevRepContent 535 CAKeyUpdAnnContent 536 CertAnnContent 537 CRLAnnContent 538 RevAnnContent 539 KeyRecRepContent 541 The following sections establish additional requirements on the use of 542 these messages. 544 4.8.1 PKCSReq 546 As defined in [CMMF], a PKCSReq message consists of a PKCS10 certificate 547 signing request and additional registration information. The PKCS10 548 field SHOULD contain a ChallengePassword attribute generated by the 549 owner of the private key. It MAY contain an optional ExtensionReq 550 attribute used to indicate to the server one or more PKIXCERT 551 certificate extensions. It MAY contain additional attributes as 552 specified by PKCS9. 554 Some certification products are operated in a fashion that assigns 555 subject names from a central repository of information upon receipt of a 556 public key for certification. To accommodate this mode of operation, 557 the subject name in a PKCSReq MAY be NULL, but MUST be present. 559 CMS requires that the signerInfo contain a issuerNameSerialNumber value; 560 however for this transaction, the certificate has yet to be issued and 561 therefore the serialNumber has not yet been assigned. Thus the 562 issuerName and SerialNumber value in the signerInfo element of PKCSReq 563 SHALL be set to NULL and zero, respectively. 565 4.8.2 Use of RegInfo in PKCSReq 567 The RegInfo field of a PKCSReq request MAY contain additional 568 information relevant to the request. This information is supplied 569 external to the PKCS10 object and as such is not a component of the 570 proof of possession calculation (see [CMMF]). 572 The RegInfo field is intended to consist of name-value pairs. Appendix 573 B.1 of [CRMF] defines some standard name-value pairs and associated 574 encoding mechanisms. Clients SHALL use those mechanisms when using the 575 RegInfo field of PKCSReq to address the requirements met by the elements 576 defined in CRMF Appendix B.1. Additional name-value pairs MAY be 577 defined for environments with a need. 579 4.8.3 CertRep 581 A CertRep message is the response to a PKCSReq, GetCert or GetCRL. It 582 is defined in [CMMF]. 584 The following requirements pertain to the construction of CertRep 585 message in response to receipt of PKCSReq message: 587 CertRep message consists of one or more certificates and an associated 588 RspInfo field. The certificate(s) are contained in the response field. 589 This field is a SignedData CMS content type with no ContentInfo or 590 SignerInfos fields. Section 5.1 of CMS further describes this 591 particular construction. In particular, although the SignedData 592 construct is used, no signature is produced. 594 If the value of pkiStatus service indicator in a CertRep message is 595 SUCCESS, the response field SHALL contain the requested certificate(s) 596 and MAY contain additional non-root CA certificates related to the 597 validation of the requested certificate(s). 599 If the value of pkiStatus service indicator in a CertRep message is 600 PENDING or FALURE, the response field SHALL be excluded. 602 In all cases, the rspInfo field of CertRep MAY contain additional 603 information useful to the application receiving the message in the form 604 of name-value pairs. Other additional data could include detailed error 605 information that uniquely identifies an information field supplied in 606 the original regInfo field of a PKCSReq; e.g. the Zip Code was incorrect 607 for the specified address or locale or billing failed because credit 608 card information was in error. 610 CAs that receive a PKCSReq with a null subject name MAY reject such 611 requests. If rejected, the CA SHALL respond with a CertRep message with 612 pkiStatus of FAILURE and failInfo value of BADREQUEST. 614 The client MAY incorporate one or more standard X.509 v3 extensions in 615 the request as defined in [CMMF]. Servers are not required to be able to 616 process every v3 X.509 extension transmitted using this protocol, nor 617 are they required to be able to process other, private extensions. 618 However, in the circumstance when a certification request is denied due 619 to the inability to handle a requested extension, the server SHALL 620 respond with a CertRep message indicating FAILURE and a corresponding 621 FailureInfo field with the value of UNSUPPORTEDEXT. 623 4.8.4 GetCertInitial 625 The GetCertInitial message is used to poll for the certificate 626 associated with prior PKCSReq request if the response to that prior 627 request was a CertRep message with a status of PENDING. 629 Certificates are normally referenced using the CA DN and the certificate 630 serial number. In this case however a certificate has not yet been 631 issued. Thus the CA and Subject DNs are present in the message as a 632 means to identify the requested certification. [CMMF] defines this 633 syntax. 635 Clients that implement GetCertInitial SHALL conform to the requirements 636 on use of the TransactionID service indicator as defined in Section 637 5.4.2. 639 4.8.5 GetCert 641 This operation is used to retrieve certificates from a certificate 642 server or service�s repository. This message is useful in circumstances 643 where a fully-deployed Directory is either infeasible or undesired. 644 Additionally, certificate retrieval requests may be used by resource- 645 constrained clients to recover their public key in the event of a device 646 reset. This could be the case within low-end IP routers that do not 647 retain their certificates in non-volatile memory. 649 The GetCert message body consists of the CertID syntax defined in 650 [CMMF]. For reference, this syntax is: 652 CertID ::= SEQUENCE { 653 issuerName GeneralName, 654 serialNumber INTEGER } 656 The response to a GetCert message SHALL consist of CertRep message 657 containing a signedData response containing the requested certificate as 658 defined in [CMMF]. 660 4.8.6 GetCRL 662 This operation is used to retrieve CRLs from a CA's repository. In order 663 to provide clients a convenient means of determining the network address 664 needed to acquire a CA's CRL, servers and clients SHOULD be capable of 665 producing and processing the CRLDistributionPoints certificate extension 666 as defined in [PKIXCERT]. 668 The response to a GetCRL message SHALL consist of CertRep message 669 containing only a value for CRLs as a component of a �degenerate� 670 SignedData rather than the certificates component. Contents for the 671 rspInfo field of CertRep MAY be included. 673 4.8.7 RevReq 675 [CMMF] defines the syntax of a RevReq (revocation request). For 676 reference, a RevReq message body consists of: 678 - name of the certificate issuer 679 - serial number of the certificate to be revoked 680 - a reason code 681 - an optional passphrase 682 - an optional comment field 684 For a revocation request to become a reliable object in the event of a 685 dispute, a strong proof of originator authenticity is required. A 686 Registration Authority�s digital signature on the request can provide 687 this proof for certificates within the scope of the RA�s revocation 688 authority. The means by which an RA is delegated this authority is a 689 matter of operational policy. 691 However, in the instance when an end-entity has lost use of their 692 signature private key, it is impossible to produce a reliable digital 693 signature. The PKCSReq message provides for the optional transmission 694 from the CA to the end-entity of a passphrase which may be used as an 695 alternative authenticator in the instance of loss of use. The 696 acceptability of this practice is a matter of local security policy. 698 Clients SHALL provide the capability to produce a digitally signed 699 RevReq message. Clients SHOULD provide the capability produce an 700 unsigned revocation request containing the end-entity�s passphrase. If 701 a client provides passphrase-based self-revocation, the client SHALL be 702 capable of producing a PKCSReq containing a passphrase. 704 The structure of an unsigned, passphrase-based RevReq is a matter of 705 local implementation. Since such a message has no relationship to the 706 use of cryptography, the use of CMS to convey this message is not 707 required. 709 The response to a RevReq message SHALL consist of CertRep message with 710 the following characteristics: 712 Success: 713 1. The pkiStatus service indicator SHALL contain a value of SUCCESS. 714 2. The response field of the CertRep message body MAY be included. If 715 so, it SHALL contain the updated CRL relevant to the subject 716 certificate. 718 Failure: 719 1. The pkiStatus service indicator SHALL contain a value of FAILURE. 720 2. The failInfo service indicator shall be set to the appropriate reason 721 code. 722 3. The response field of the CertRep message body SHALL be excluded. 724 In either case, the rspInfo field of CertRep message body MAY be 725 included. If so, it SHALL contain additional information relevant to 726 the interpretation of the failure. 728 5. Security Considerations 730 Initiation of a secure communications channel between an end-entity and 731 a CA necessarily requires an out-of-band trust initiation mechanism. For 732 example, a secure channel may be constructed between the end-entity and 733 the CA via IPSEC or TLS. Many such schemes exist and the choice of any 734 particular scheme for trust initiation is outside the scope of this 735 document. Implementors of this protocol are strongly encouraged to 736 consider generally accepted principles of secure key management when 737 integrating this capability within an overall security architecture. 739 Mechanisms for thwarting replay attacks may be required in particular 740 implementations of this protocol depending on the operational 741 environment. In cases where CAs maintain significant state information 742 themselves, replay attacks may be detectable without the inclusion of 743 the optional nonce mechanisms. Implementors of this protocol need to 744 carefully consider environmental conditions before choosing whether or 745 not to implement the senderNonce and recipientNonce service indicators 746 described in section 4.3.1. Developers of state-constrained PKI clients 747 are strongly encouraged to incorporate the use of these service 748 indicators. 750 6. References 752 [CMS] R. Housley, "Cryptographic Message Syntax", 753 draft-ietf-smime-cms-01.txt, October 1997 755 [PKCS7] B. Kaliski, "PKCS #7: Cryptographic Message Syntax v1.5", 756 draft-hoffman-pkcs-crypt-msg-03.txt, October 1997 758 [PKCS10] B. Kaliski, "PKCS #10: Certification Request Syntax v1.5", 759 draft-hoffman-pkcs-certif-req-03.txt, October 1997 761 [PKIXCERT] R. Housley, W. Ford, W. Polk, D. Solo "Internet Public 762 Key Infrastructure X.509 Certificate and CRL Profile", 763 draft-ietf-pkix-ipki-part1-06.txt, October, 1997 765 [CRMF] M. Myers, C. Adams, D. Solo, D. Kemp, 766 Certificate Request Message Format, 767 , February, 1998 769 9. Author's Addresses 771 Michael Myers 772 VeriSign, Inc. 773 1390 Shorebird Way 774 Mountain View, CA, 94019 775 (650) 429-3402 776 mmyers@verisign.com 778 Xiaoyi Liu 779 Cisco Systems 780 170 West Tasman Drive 781 San Jose, CA 95134 782 (480) 526-7430 783 xliu@cisco.com 785 Barbara Fox 786 Microsoft Corporation 787 One Microsoft Way 788 Redmond, WA 98052 789 (425) 936-9542 790 bfox@microsoft.com 792 Jeff Weinstein 793 Netscape Communications Corporation 794 501 Middlefield Road 795 Mountain View, CA 94043 796 jsw@netscape.com