idnits 2.17.1 draft-ietf-pkix-cmmf-00.txt: ** The Abstract section seems to be numbered 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. == There are 8 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 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 lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 441 has weird spacing: '...4], for detai...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (February 1998) is 9567 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) -- Looks like a reference, but probably isn't: '0' on line 586 -- Looks like a reference, but probably isn't: '1' on line 587 -- Looks like a reference, but probably isn't: '2' on line 589 -- Looks like a reference, but probably isn't: '3' on line 177 == Unused Reference: 'COR95' is defined on line 663, but no explicit reference was found in the text == Unused Reference: 'MvOV97' is defined on line 666, but no explicit reference was found in the text == Unused Reference: 'PKCS7' is defined on line 669, but no explicit reference was found in the text == Unused Reference: 'PKCS10' is defined on line 673, but no explicit reference was found in the text == Unused Reference: 'PKCS11' is defined on line 677, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 682, but no explicit reference was found in the text == Unused Reference: 'X509-AM' is defined on line 690, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'COR95' -- Possible downref: Non-RFC (?) normative reference: ref. 'MvOV97' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS7' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS10' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS11' ** Downref: Normative reference to an Informational RFC: RFC 2104 -- Possible downref: Non-RFC (?) normative reference: ref. 'X509-AM' -- Possible downref: Non-RFC (?) normative reference: ref. 'CRMF' -- Possible downref: Non-RFC (?) normative reference: ref. 'CMS' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS8' Summary: 11 errors (**), 0 flaws (~~), 11 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft C. Adams (Entrust Technologies) 2 PKIX Working Group M. Myers (VeriSign) 3 draft-ietf-pkix-cmmf-00.txt 4 Expires in 6 months February 1998 6 Internet X.509 Public Key Infrastructure 7 Certificate Management Message Formats 8 10 1. Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups may also distribute working 15 documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of 6 months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 To learn the current status of any Internet-Draft, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za(Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 2. Abstract 30 This is a draft of the Internet X.509 Public Key Infrastructure (PKI) 31 Certificate Management Messages Formats (CMMF). It establishes 32 harmonized message formats to be used in conjunction with security 33 protocol implementations that require interaction with a Public Key 34 Infrastructure (PKI). 36 This draft is being discussed on the ''ietf-pkix'' mailing list. To 37 subscribe, send a message to ietf-pkix-request@tandem.com with the 38 single word �subscribe� in the body of the message. 40 3. Introduction 42 This document defines message formats to be used between a PKI client 43 and a PKI server or service(where a PKI is defined to encompass the 44 roles of Registration Authority and Certification Authority). Using 45 these message formats, a PKI client may: 46 - Request public key certification 47 - Responses may include CA-generated key pairs 48 - Request revocation of a certificate 49 - Receive announcements directly from a PKI on: 50 - CA Key Update 51 - Renewed Certificates 52 - Subscriber Revocation notices 53 - CRL refresh 55 - Request data of a PKI, including: 56 - One�s own or others� certificate 57 - CRL download 59 The specification of a transaction protocol using these message formats 60 is beyond the scope of this document. It is expected that such protocols 61 will be defined with a view towards localized interoperability needs. 62 Where requirements exist to exchange information which is substantially 63 aligned with the message content in this document, such protocols should 64 reference these message formats. 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 67 "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, 68 as shown) are to be interpreted as described in [RFC2119]. 69 4. Common Data Structures 71 Several structures are common to more than one message format. These 72 are: 74 - Status information 75 - Failure information 76 - Certificate identification 77 - Encrypted values 79 4.1 Status Information 81 Responses may include status information pertaining to a prior request. 82 The following values are defined: 84 PKIStatus ::= INTEGER { 85 granted (0), 86 -- you got exactly what you asked for 87 grantedWithMods (1), 88 -- you got something like what you asked for; the 89 -- requester is responsible for ascertaining the differences 90 rejection (2), 91 -- you don't get it, more information elsewhere in the message 92 waiting (3), 93 -- the request body part has not yet been processed, 94 -- expect to hear more later 95 revocationWarning (4), 96 -- this message contains a warning that a revocation is 97 -- imminent 98 revocationNotification (5), 99 -- notification that a revocation has occurred 100 keyUpdateWarning (6) 101 -- update already done for the oldCertId specified in 102 -- FullCertTemplate 103 } 105 4.2 Failure Information 107 The following values may be used to provide more information about 108 failure cases. 110 PKIFailureInfo ::= BIT STRING { 111 -- since we can fail in more than one way! 112 -- More codes may be added in the future if/when required. 113 badAlg (0), 114 -- unrecognized or unsupported Algorithm Identifier 115 badMessageCheck (1), 116 -- integrity check failed (e.g., signature did not verify) 117 badRequest (2), 118 -- transaction not permitted or supported 119 badTime (3), 120 -- messageTime was not sufficiently close to the system time, 121 -- as defined by local policy 122 badCertId (4), 123 -- no certificate could be found matching the provided criteria 124 badDataFormat (5), 125 -- the data submitted has the wrong format 126 wrongAuthority (6), 127 -- the authority indicated in the request is different from the 128 -- one creating the response token 129 incorrectData (7), 130 -- the requester's data is incorrect (used for notary services) 131 missingTimeStamp (8) 132 -- when the timestamp is missing but should be there (by policy) 133 } 135 PKIStatusInfo ::= SEQUENCE { 136 status PKIStatus, 137 statusString PKIFreeText OPTIONAL, 138 failInfo PKIFailureInfo OPTIONAL } 140 4.3 Certificate Identification 142 In order to identify particular certificates the following data 143 structure is used. 145 CertId ::= SEQUENCE { 146 issuer GeneralName, 147 serialNumber INTEGER } 149 4.4 Encrypted Values 151 Certain values in responses may require encryption beyond that that 152 which may be performed in a PKI protocol. For example, a CA may 153 generate key pairs for subscribers but deliver them via an RA. As a 154 general rule RAs should be prohibited from unnecessary or inadvertent 155 contact with a subscriber�s private keys. 157 EncryptedData ::= CHOICE { 158 encryptedValue [0] EncryptedValue, 159 cMSEnveloped [1] EnvelopedData, 160 pKCS8 [2] EncryptedPrivateKeyInfo, 161 pKCS12 [3] KeysAndCertificates } 163 The syntax of encryptedValue is defined below. The EnvelopedData syntax 164 of cMSEnveloped is defined by [CMS]. The EncryptedPrivateKeyInfo syntax 165 of pKCS8 is defined by [PKCS8]. The KeysAndCertificates syntax is 166 defined by [pKCS12]. 168 EncryptedValue ::= SEQUENCE { 169 encValue BIT STRING, 170 -- the encrypted value itself 171 intendedAlg [0] AlgorithmIdentifier OPTIONAL, 172 -- the intended algorithm for which the value will be used 173 symmAlg [1] AlgorithmIdentifier OPTIONAL, 174 -- the symmetric algorithm used to encrypt the value 175 encSymmKey [2] BIT STRING OPTIONAL, 176 -- the (encrypted) symmetric key used to encrypt the value 177 keyAlg [3] AlgorithmIdentifier OPTIONAL 178 -- algorithm used to encrypt the symmetric key 179 } 181 Use of this data structure requires that the creator and intended 182 recipient respectively be able to encrypt and decrypt. Typically, this 183 will mean that the sender and recipient have, or are able to generate, a 184 shared secret key. 186 For Diffie-Hellman keys, the encSymmKey field of EncryptedValue is not 187 included. For RSA, encSymmKey is a symmetric key encrypted under the 188 subscriber�s public RSA key. 190 If the recipient of the PKIMessage already possesses a private key 191 usable for decryption, then the encSymmKey field MAY contain a session 192 key encrypted using the recipient�s public key. 194 5. Message Formats 196 5.1 Certification Request 198 [CRMF] defines the preferred structure for production of certification 199 requests. It is a flexible mechanism designed to enable mandatory and 200 optional cryptographic algorithms, centralized key generation, a variety 201 of proof-of-possession options and several other control features useful 202 to a robust PKI client enrollment capability. 204 Current industry practice can be supported for clients through use of 205 the following structure. 206 PKCSReq ::= SEQUENCE { 207 endEntityInfo EndEntityInfo, 208 regInfo OCTET STRING OPTIONAL 209 } 210 The endEntityInfo field is used to carry a public key, to prove 211 possession of the public key and to provide additional ASN.1 attributes 212 useful to production of the resulting certificate. 214 The regInfo field contains supplementary information related to the 215 context of the certification request when such information is required 216 to fulfill a certification request. This information could include 217 subscriber contact information, billing information or other 218 ancillary information useful to fulfillment of the certification 219 request. 221 Current industry practice has established two structures for producing a 222 signed public key. The use of explicit tagging below allows 223 disambiguation among these options while maintaining bits on the wire 224 compatibility with prior implementations: 226 endEntityInfo :: CHOICE { 227 pKCS10 CertificationRequest, 228 signedKey [0] SignedPublicKeyAndChallenge 229 } 231 SignedPublicKeyAndChallenge :: SEQUENCE { 232 publicKeyAndChallenge PublicKeyAndChallenge, 233 signatureAlgorithm AlgorithmIdentifier, 234 signature BIT STRING 235 } 237 PublicKeyAndChallenge :: SEQUENCE { 238 spki SubjectPublicKeyInfo, 239 challenge IA5String 240 } 242 CertificationRequest ::= SEQUENCE { 243 certificationRequestInfo SEQUENCE { 244 version INTEGER, 245 subject Name, 246 subjectPublicKeyInfo SEQUENCE { 247 algorithm AlgorithmIdentifier, 248 subjectPublicKey BIT STRING } 249 attributes [0] IMPLICIT SET OF Attribute } 250 signatureAlgorithm AlgorithmIdentifier, 251 signature BIT STRING } 253 The client MAY incorporate one or more standard X.509 v3 extensions in 254 the request as an ExtensionReq attribute: 256 ExtensionReq ::= SEQUENCE OF Extension 258 where Extension is imported from PKIX Part 1 and ExtensionReq is 259 identified by the OID value {pkcs-9 14}. 261 5.2 Certification Response 263 Two options are established for the response to a certification request: 264 a simple form that enables basic interoperability and a form that 265 enables generation of subscriber private keys by the CA. 267 5.2.1 Use of SignedData 269 [CMS] supports a degenerate case of the SignedData content type where 270 there are no signers on the content. This degenerate case is used to 271 convey certificate and CRL information. Certification Authorities MAY 272 use this format for returning certificate information resulting from the 273 successful fulfillment of a certification request. The certificate 274 response MUST include the actual subject certificate corresponding to 275 the information in the certification request. The response SHOULD 276 include other certificates which link the issuer to higher level 277 certification authorities and corresponding CRLs. 279 CertRep ::= SEQUENCE { 280 response SignedData, OPTIONAL 281 rspInfo OCTET STRING 282 } 284 Successful requests would include the resulting certificate(s) in the 285 response field along with any additional {name, value} information 286 useful to client-side processing of a successful request. In the event 287 of an unsuccessful request, the rspInfo field contains information 288 regarding the failure which may be useful to the requesting entity. 290 RspInfo content MAY include state information the PKI client needs such 291 as the contents of the regInfo in the CRMF ( see [CRMF]). Other 292 additional data could include detailed error information that uniquely 293 identifies an information field supplied in the original regInfo; e.g. 294 the Zip Code was incorrect for the specified address or locale or 295 billing failed because credit card information was in error. 297 5.2.2 CertRepContent 299 A CertRepContent data structure contains a CA public key, a status value 300 and optionally failure information, a subject certificate, and an 301 encrypted private key. 303 CertRepContent ::= SEQUENCE { 304 caPubs [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL, 305 response SEQUENCE of CertResponse } 307 CertResponse ::= SEQUENCE { 308 certReqId INTEGER, 309 -- to match this response with corresponding request (a value 310 -- of -1 is to be used if certReqId is not specified in the 311 -- corresponding request) 312 status PKIStatusInfo, 313 certifiedKeyPair CertifiedKeyPair, OPTIONAL } 315 CertifiedKeyPair ::= SEQUENCE { 316 certOrEncCert CertOrEncCert, 317 privateKey [0] EncryptedValue OPTIONAL, 318 publicationInfo [1] PKIPublicationInfo OPTIONAL } 320 CertOrEncCert ::= CHOICE { 321 certificate [0] Certificate, 322 encryptedCert [1] EncryptedValue } 324 Given an EncryptedCert and the relevant decryption key the certificate 325 may be obtained. The purpose of this is to allow a CA to return the 326 value of a certificate, but with the constraint that only the intended 327 recipient can obtain the actual certificate. The benefit of this 328 approach is that a CA may reply with a certificate even in the absence 329 of a proof that the requester is the end entity which can use the 330 relevant private key (note that the proof is not obtained until 331 confirmation of receipt is received by the CA). Thus the CA will not 332 have to revoke that certificate in the event that something goes wrong 333 with the proof of possession. 335 5.3 GetCertInitial 337 The GetCertInitial message is used to poll for the certificate 338 associated with prior request if the response to that prior request was 339 a CertRep message with a status of PENDING. 341 Certificates are normally referenced using the CA DN and the certificate 342 serial number. In this case however a certificate has not yet been 343 issued. Thus the CA and Subject DNs are present in the message as a 344 means to identify the requested certification. 346 IssuerAndSubject ::= SEQUENCE { 347 issuer Name, 348 subject Name } 350 5.4 GetCRL 352 This operation is used to retrieve CRLs from a certificate server or 353 service�s repository. This message is useful in circumstances where a 354 fully-deployed Directory is either infeasible or undesired. 356 The GetCRL message body consists of the following syntax: 358 GetCRL ::= SEQUENCE { 359 issuerName Name, 360 cRLName GeneralName, OPTIONAL 362 reasons ReasonFlags OPTIONAL } 364 The Name component is the value of the Issuer DN in the subject certifi- 365 cate. The cRLName component may be the value of CRLDistributionPoints in 366 the subject certificate or equivalent value in the event the certificate 367 does not contain such a value. The time component is used by the client 368 to specify from among potentially several issues of CRL that one whose 369 thisUpdate value is less than but nearest to the specified time. In the 370 absence of a time component, the CA always returns with the most recent 371 CRL. The reasons field can be used to specify from among CRLs 372 partitioned by reason codes. 374 5.5 Revocation Request 376 Two options are established to enable programmatic submission of a 377 revocation request. 379 5.5.1 RevRequest 381 RevRequest ::= SEQUENCE { 382 issuerName Name, 383 serialNumber INTEGER, 384 reason ReasonFlags, 385 passphrase OCTET STRING OPTIONAL, 386 comment PrintableString OPTIONAL } 388 For a revocation request to become a reliable object in the event of a 389 dispute, a strong proof of originator authenticity is required. A 390 Registration Authority�s digital signature on the request can provide 391 this proof for certificates within the scope of the RA�s revocation 392 authority. However, in the instance when an end-entity has lost use of 393 their signature private key, it is impossible to produce a reliable 394 digital signature. [CRMF] provides for the use specification of a 395 passphrase during enrollment which may be used as an alternative 396 authenticator in the instance of loss of use. The acceptability of this 397 practice is a matter of local security policy. 399 5.5.2 RevReqContent 401 When requesting revocation of a certificate (or several certificates) 402 the following data structure is used. 404 RevReqContent ::= SEQUENCE OF RevDetails 406 RevDetails ::= SEQUENCE { 407 certDetails CertTemplate, 408 -- allows requester to specify as much as they can about 409 -- the cert. for which revocation is requested 410 -- (e.g., for cases in which serialNumber is not available) 411 revocationReason ReasonFlags, 412 -- from the Draft Amendment (DAM), so CA knows what to use in 413 -- Distribution point 414 badSinceDate GeneralizedTime OPTIONAL, 415 -- indicates best knowledge of sender 416 crlEntryDetails Extensions 417 -- requested crlEntryExtensions 418 } 420 5.6 Revocation Response 422 The response to the above message. If produced, this is sent to the 423 requester of the revocation. (A separate revocation announcement message 424 MAY be sent to the subject of the certificate for which revocation was 425 requested.) 427 RevRepContent ::= SEQUENCE { 428 status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo, 429 -- in same order as was sent in RevReqContent 430 revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL, 431 -- IDs for which revocation was requested (same order as status) 432 crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL 433 -- the resulting CRLs (there may be more than one) 434 } 436 5.7 Challenge-Response Proof Of Possession 438 [CRMF] establishes the basis for a challenge-response proof of 439 possession technique. The challenge-response messages for proof of 440 possession of a private decryption key are specified as follows (see 441 [MvOV97, p.404], for details). 443 POPODecKeyChallContent ::= SEQUENCE OF Challenge 444 -- One Challenge per encryption key certification request (in the 445 -- same order as these requests appear in FullCertTemplates). 447 Challenge ::= SEQUENCE { 448 owf AlgorithmIdentifier OPTIONAL, 449 -- MUST be present in the first Challenge; MAY be omitted in any 450 -- subsequent Challenge in POPODecKeyChallContent (if omitted, 451 -- then the owf used in the immediately preceding Challenge is 452 -- to be used). 453 witness OCTET STRING, 454 -- the result of applying the one-way function (owf) to a 455 -- randomly-generated INTEGER, A. [Note that a different 456 -- INTEGER MUST be used for each Challenge.] 457 challenge OCTET STRING 458 -- the encryption (under the public key for which the cert. 459 -- request is being made) of Rand, where Rand is specified as 460 -- Rand ::= SEQUENCE { 461 -- int INTEGER, 462 -- - the randomly-generated INTEGER A (above) 463 -- sender GeneralName 464 -- - the sender's name (as included in PKIHeader) 465 -- } 466 } 468 POPODecKeyRespContent ::= SEQUENCE OF INTEGER 469 -- One INTEGER per encryption key certification request (in the 470 -- same order as these requests appear in FullCertTemplates). The 471 -- retrieved INTEGER A (above) is returned to the sender of the 472 -- corresponding Challenge. 474 5.8 PKI Confirmation content 476 This data structure is used in three-way protocols as the final 477 PKIMessage. Its content is the same in all cases - actually there is no 478 content since the PKIHeader carries all the required information. 480 PKIConfirmContent ::= NULL 482 5.9 Announcements 484 >From time to time a PKI may need to distribute information to its 485 clients or subscribers. These messages are generally unsolicited and 486 consequently reverse the flow of request-response behavior. 487 Implementers of protocols that use these message formats should take 488 this effect into account. 490 5.9.1 CA Key Update Announcement content 492 When a CA updates its own key pair the following data structure MAY be 493 used to announce this event. 495 CAKeyUpdAnnContent ::= SEQUENCE { 496 oldWithNew Certificate, -- old pub signed with new priv 497 newWithOld Certificate, -- new pub signed with old priv 498 newWithNew Certificate -- new pub signed with new priv 499 } 501 To change the key of the CA, the CA does the following: 503 1.Generate a new key pair; 505 2.Create a certificate containing the old CA public key signed with 506 the new private key (the "old with new" certificate); 508 3.Create a certificate containing the new CA public key signed with 509 the old private key (the "new with old" certificate); 511 4.Create a certificate containing the new CA public key signed with 512 the new private key (the "new with new" certificate); 514 5.Publish these new certificates via the directory and/or other means 516 6.Export the new CA public key so that end entities may acquire it 517 using the "out-of-band" mechanism (if required). 519 The old CA private key is then no longer required. The old CA public key 520 will however remain in use for some time. The time when the old CA 521 public key is no longer required (other than for non-repudiation) will 522 be when all end entities of this CA have securely acquired the new CA 523 public key. 525 The "old with new" certificate must have a validity period starting at 526 the generation time of the old key pair and ending at the expiry date of 527 the old public key. 529 The "new with old" certificate must have a validity period starting at 530 the generation time of the new key pair and ending at the time by which 531 all end entities of this CA will securely possess the new CA public key 532 (at the latest, the expiry date of the old public key). 534 The "new with new" certificate must have a validity period starting at 535 the generation time of the new key pair and ending at the time by which 536 the CA will next update its key pair. 538 5.9.2 Certificate Announcement 540 This structure MAY be used to announce the existence of certificates. 542 Note that this message is intended to be used for those cases (if any) 543 where there is no pre-existing method for publication of certificates; 544 it is not intended to be used where, for example, X.500 is the 545 method for publication of certificates. 547 CertAnnContent ::= Certificate 549 5.9.3 CRL Announcement 551 When a CA issues a new CRL (or set of CRLs) the following data structure 552 MAY be used to announce this event. 554 CRLAnnContent ::= SEQUENCE OF CertificateList 556 5.9.4 Revocation Announcement 558 When a CA has revoked, or is about to revoke, a particular certificate 559 it MAY issue an announcement of this (possibly upcoming) event. 561 RevAnnContent ::= SEQUENCE { 562 status PKIStatus, 563 certId CertId, 564 willBeRevokedAt GeneralizedTime, 565 badSinceDate GeneralizedTime, 566 crlDetails Extensions OPTIONAL 567 -- extra CRL details(e.g., crl number, reason, location, etc.) 568 } 570 A CA MAY use such an announcement to warn (or notify) a subject that its 571 certificate is about to be (or has been) revoked. This would typically 572 be used where the request for revocation did not come from the subject 573 concerned. 575 The willBeRevokedAt field contains the time at which a new entry will be 576 added to the relevant CRLs. 578 5.10 Key recovery Response 580 For key recovery responses the following syntax is used. For some 581 status values (e.g., waiting) none of the optional fields will be 582 present. 584 KeyRecRepContent ::= SEQUENCE { 585 status PKIStatusInfo, 586 newSigCert [0] Certificate OPTIONAL, 587 caCerts [1] SEQUENCE SIZE (1..MAX) OF 588 Certificate OPTIONAL, 589 keyPairHist [2] SEQUENCE SIZE (1..MAX) OF 590 CertifiedKeyPair OPTIONAL 591 } 593 5.11 PKI General Message content 595 >From time to time a PKI MAY announce other information not explicitly 596 called out in this specification. In such cases the following structure 597 MAY be used to unambiguously identify this information when transmitted 598 as a PKI message. 600 InfoTypeAndValue ::= SEQUENCE { 601 infoType OBJECT IDENTIFIER, 602 infoValue ANY DEFINED BY infoType OPTIONAL 603 } 604 -- Example InfoTypeAndValue contents include, but are not limited to: 605 -- { CAProtEncCert = {id-it 1}, Certificate } 606 -- { SignKeyPairTypes = {id-it 2}, SEQUENCE OF AlgorithmIdentifier } 607 -- { EncKeyPairTypes = {id-it 3}, SEQUENCE OF AlgorithmIdentifier } 608 -- { PreferredSymmAlg = {id-it 4}, AlgorithmIdentifier } 609 -- { CAKeyUpdateInfo = {id-it 5}, CAKeyUpdAnnContent } 610 -- { CurrentCRL = {id-it 6}, CertificateList } 611 -- where {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4} 612 -- This construct MAY also be used to define new PKIX Certificate 613 -- Management Protocol request and response messages, or general- 614 -- purpose (e.g., announcement) messages for future needs or for 615 -- specific environments. 617 GenMsgContent ::= SEQUENCE OF InfoTypeAndValue 618 -- May be sent by EE, RA, or CA (depending on message content). 619 -- The OPTIONAL infoValue parameter of InfoTypeAndValue will typically 620 -- be omitted for some of the examples given above. The receiver is 621 -- free to ignore any contained OBJ. IDs that it does not recognize. 622 -- If sent from EE to CA, the empty set indicates that the CA may send 623 -- any/all information that it wishes. 625 5.12 PKI General Response content 627 GenRepContent ::= SEQUENCE OF InfoTypeAndValue 628 -- The receiver is free to ignore any contained OBJ. IDs that it does 629 -- not recognize. 631 5.13 Error Message 633 ErrorMsgContent ::= SEQUENCE { 634 pKIStatusInfo PKIStatusInfo, 635 errorCode INTEGER OPTIONAL, 636 -- implementation-specific error codes 637 errorDetails PKIFreeText OPTIONAL 638 -- implementation-specific error details 639 } 641 6. SECURITY CONSIDERATIONS 643 This entire memo is about security mechanisms. 645 One cryptographic consideration is worth explicitly spelling out. In 646 the protocols specified above, when an end entity is required to 647 prove possession of a decryption key, it is effectively challenged 648 to decrypt something (its own certificate). This scheme (and many 649 others!) could be vulnerable to an attack if the possessor of the 650 decryption key in question could be fooled into decrypting an 651 arbitrary challenge and returning the cleartext to an attacker. 652 Although in this specification a number of other failures in 653 security are required in order for this attack to succeed, it is 654 conceivable that some future services (e.g., notary, trusted time) 655 could potentially be vulnerable to such attacks. For this reason we 656 re-iterate the general rule that implementations should be very 657 careful about decrypting arbitrary "ciphertext" and revealing 658 recovered "plaintext" since such a practice can lead to serious 659 security vulnerabilities. 661 7. References 663 [COR95] ISO/IEC JTC 1/SC 21, Technical Corrigendum 2 to ISO/IEC 664 9594-8: 1990 & 1993 (1995:E), July 1995. 666 [MvOV97] A. Menezes, P. van Oorschot, S. Vanstone, "Handbook of 667 Applied Cryptography", CRC Press, 1997. 669 [PKCS7] RSA Laboratories, "The Public-Key Cryptography Standards 670 (PKCS)", RSA Data Security Inc., Redwood City, California, 671 November 1993 Release. 673 [PKCS10] RSA Laboratories, "The Public-Key Cryptography Standards 674 (PKCS)", RSA Data Security Inc., Redwood City, California, 675 November 1993 Release. 677 [PKCS11] RSA Laboratories, "The Public-Key Cryptography Standards - 678 PKCS #11: Cryptographic token interface standard", RSA 679 Data Security Inc., Redwood City, California, April 28, 680 1995. 682 [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed Hashing 683 for Message Authentication", Internet Request for Comments 684 2104, February, 1997. 686 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 687 Requirement Levels", Internet Request for Comments 2119 688 (Best Current Practice: BCP 14), March, 1997. 690 [X509-AM] ISO/IEC JTC1/SC 21, Draft Amendments DAM 4 to ISO/IEC 691 9594-2, DAM 2 to ISO/IEC 9594-6, DAM 1 to ISO/IEC 9594-7, 692 and DAM 1 to ISO/IEC 9594-8 on Certificate Extensions, 693 1 December, 1996. 695 [CRMF] M. Myers, C. Adams, D. Solo, D. Kemp, 696 Certificate Request Message Format, 697 , 698 February, 1998 700 [CMS] R. Housley, Cryptographic Message Syntax 701 702 December, 1997 704 [PKCS8] Private Key Information Syntax Standard, v1.2 705 RSA Laboratories Technical Note 706 November 1, 1993 708 Authors' Addresses 709 Michael Myers 710 VeriSign, Inc. 711 1390 Shorebird Way, 712 Mountain View, CA 94043 713 mmyers@verisign.com 715 Carlisle Adams 716 Entrust Technologies 717 750 Heron Road, Suite E08, 718 Ottawa, Ontario 719 Canada K1V 1A7 720 cadams@entrust.com