idnits 2.17.1 draft-ietf-pkix-cmmf-01.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-20) 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 7 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 14 longer pages, the longest (page 1) 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 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 439 has weird spacing: '...the requester...' == Line 456 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 (July 1998) is 9411 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 620 -- Looks like a reference, but probably isn't: '1' on line 621 -- Looks like a reference, but probably isn't: '2' on line 623 -- Looks like a reference, but probably isn't: '3' on line 182 == Unused Reference: 'COR95' is defined on line 689, but no explicit reference was found in the text == Unused Reference: 'MvOV97' is defined on line 692, but no explicit reference was found in the text == Unused Reference: 'PKCS7' is defined on line 695, but no explicit reference was found in the text == Unused Reference: 'PKCS10' is defined on line 699, but no explicit reference was found in the text == Unused Reference: 'PKCS11' is defined on line 703, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 708, but no explicit reference was found in the text == Unused Reference: 'X509-AM' is defined on line 716, 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 (~~), 14 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-01.txt 4 Expires in 6 months July 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 view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 26 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 27 (US West Coast). 29 2. Abstract 31 This is a draft of the Internet X.509 Public Key Infrastructure (PKI) 32 Certificate Management Messages Formats (CMMF). It establishes 33 harmonized message formats to be used in conjunction with security 34 protocol implementations that require interaction with a Public Key 35 Infrastructure (PKI). 37 This draft is being discussed on the ''ietf-pkix'' mailing list. To 38 subscribe, send a message to ietf-pkix-request@tandem.com with the 39 single word �subscribe� in the body of the message. 41 3. Introduction 43 This document defines message formats to be used between a PKI client 44 and a PKI server or service(where a PKI is defined to encompass the 45 roles of Registration Authority and Certification Authority). Using 46 these message formats, a PKI client may: 47 - Request public key certification 48 - Responses may include CA-generated key pairs 49 - Request revocation of a certificate 50 - Receive announcements directly from a PKI on: 51 - CA Key Update 52 - Renewed Certificates 53 - Subscriber Revocation notices 54 - CRL refresh 56 - Request data of a PKI, including: 57 - One�s own or others� certificate 58 - CRL download 60 The specification of a transaction protocol using these message formats 61 is beyond the scope of this document. It is expected that such protocols 62 will be defined with a view towards localized interoperability needs. 63 Where requirements exist to exchange information which is substantially 64 aligned with the message content in this document, such protocols should 65 reference these message formats. 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 68 "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, 69 as shown) are to be interpreted as described in [RFC2119]. 71 4. Common Data Structures 73 Several structures are common to more than one message format. These 74 are: 76 - Status information 77 - Failure information 78 - Certificate identification 79 - Encrypted values 81 4.1 Status Information 83 Responses may include status information pertaining to a prior request. 84 The following values are defined: 86 PKIStatus ::= INTEGER { 87 granted (0), 88 -- you got exactly what you asked for 89 grantedWithMods (1), 90 -- you got something like what you asked for; the 91 -- requester is responsible for ascertaining the differences 92 rejection (2), 93 -- you don't get it, more information elsewhere in the message 94 waiting (3), 95 -- the request body part has not yet been processed, 96 -- expect to hear more later 97 revocationWarning (4), 98 -- this message contains a warning that a revocation is 99 -- imminent 100 revocationNotification (5), 101 -- notification that a revocation has occurred 102 keyUpdateWarning (6) 103 -- update already done for the oldCertId specified in 104 -- FullCertTemplate 105 } 107 4.2 Failure Information 109 The following values may be used to provide more information about 110 failure cases. 112 PKIFailureInfo ::= BIT STRING { 113 -- since we can fail in more than one way! 114 -- More codes may be added in the future if/when required. 115 badAlg (0), 116 -- unrecognized or unsupported Algorithm Identifier 117 badMessageCheck (1), 118 -- integrity check failed (e.g., signature did not verify) 119 badRequest (2), 120 -- transaction not permitted or supported 121 badTime (3), 122 -- messageTime was not sufficiently close to the system time, 123 -- as defined by local policy 124 badCertId (4), 125 -- no certificate could be found matching the provided criteria 126 badDataFormat (5), 127 -- the data submitted has the wrong format 128 wrongAuthority (6), 129 -- the authority indicated in the request is different from the 130 -- one creating the response token 131 incorrectData (7), 132 -- the requester's data is incorrect (used for notary services) 133 missingTimeStamp (8) 134 -- when the timestamp is missing but should be there (by policy) 135 } 137 PKIStatusInfo ::= SEQUENCE { 138 status PKIStatus, 139 statusString PKIFreeText OPTIONAL, 140 failInfo PKIFailureInfo OPTIONAL } 142 PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String 143 -- text encoded as UTF-8 String (note: each UTF8String SHOULD 144 -- include an RFC 1766 language tag to indicate the language 145 -- of the contained text) 147 4.3 Certificate Identification 149 In order to identify particular certificates the following data 150 structure is used. 152 CertId ::= SEQUENCE { 153 issuer GeneralName, 154 serialNumber INTEGER } 156 4.4 Encrypted Values 158 Certain values in responses may require encryption beyond that that 159 which may be performed in a PKI protocol. For example, a CA may 160 generate key pairs for subscribers but deliver them via an RA.As a 161 general rule RAs should be prohibited from unnecessary or inadvertent 162 contact with a subscriber�s private keys. 164 EncryptedData ::= CHOICE { 165 encryptedValue [0] EncryptedValue, 166 cMSEnveloped [1] EnvelopedData } 168 The syntax of encryptedValue is defined below. The EnvelopedData syntax 169 of cMSEnveloped is defined by [CMS]. The EncryptedPrivateKeyInfo syntax 170 of pKCS8 is defined by [PKCS8]. The KeysAndCertificates syntax is 171 defined by [pKCS12]. 173 EncryptedValue ::= SEQUENCE { 174 encValue BIT STRING, 175 -- the encrypted value itself 176 intendedAlg [0] AlgorithmIdentifier OPTIONAL, 177 -- the intended algorithm for which the value will be used 178 symmAlg [1] AlgorithmIdentifier OPTIONAL, 179 -- the symmetric algorithm used to encrypt the value 180 encSymmKey [2] BIT STRING OPTIONAL, 181 -- the (encrypted) symmetric key used to encrypt the value 182 keyAlg [3] AlgorithmIdentifier OPTIONAL 183 -- algorithm used to encrypt the symmetric key 184 } 186 Use of this data structure requires that the creator and intended 187 recipient respectively be able to encrypt and decrypt. Typically, this 188 will mean that the sender and recipient have, or are able to generate, a 189 shared secret key. 191 For key agreement algorithms (such as Diffie-Hellman), the encSymmKey 192 field of EncryptedValue is not included. For key exchange algorithms 193 (such as RSA), the encSymmKey is a symmetric key encrypted under the 194 subscriber's public key. 196 If the recipient of the PKIMessage already possesses a private key 197 usable for decryption, then the encSymmKey field MAY contain a session 198 key encrypted using the recipient�s public key. 200 5. Message Formats 202 5.1 Certification Request 204 [CRMF] defines the preferred structure for production of certification 205 requests. It is a flexible mechanism designed to enable mandatory and 206 optional cryptographic algorithms, centralized key generation, a variety 207 of proof-of-possession options and several other control features useful 208 to a robust PKI client enrollment capability. 210 Current industry practice can be supported for clients through use of 211 the following structure. 213 PKCSReq ::= SEQUENCE { 214 endEntityInfo EndEntityInfo, 215 regInfo OCTET STRING OPTIONAL, 216 certReqId INTEGER OPTIONAL } 218 The endEntityInfo field is used to carry a public key, to prove 219 possession of the public key and to provide additional ASN.1 attributes 220 useful to production of the resulting certificate. 222 The certReqId field can be used to identify individual certification 223 requests in the event multiple PKCSReqs are sent to a CA. 225 The regInfo field contains supplementary information related to the 226 context of the certification request when such information is required 227 to fulfill a certification request. This information could include 228 subscriber contact information, billing information or other 229 ancillary information useful to fulfillment of the certification 230 request. 232 Current industry practice has established two structures for producing a 233 signed public key. The use of explicit tagging below allows 234 disambiguation among these options while maintaining bits on the wire 235 compatibility with prior implementations: 237 endEntityInfo :: CHOICE { 238 pKCS10 CertificationRequest, 239 signedKey [0] SignedPublicKeyAndChallenge } 241 SignedPublicKeyAndChallenge :: SEQUENCE { 242 publicKeyAndChallenge PublicKeyAndChallenge, 243 signatureAlgorithm AlgorithmIdentifier, 244 signature BIT STRING } 246 PublicKeyAndChallenge :: SEQUENCE { 247 spki SubjectPublicKeyInfo, 248 challenge IA5String } 250 CertificationRequest ::= SEQUENCE { 251 certificationRequestInfo SEQUENCE { 252 version INTEGER, 253 subject Name, 254 subjectPublicKeyInfo SEQUENCE { 255 algorithm AlgorithmIdentifier, 256 subjectPublicKey BIT STRING } 257 attributes [0] IMPLICIT SET OF Attribute } 258 signatureAlgorithm AlgorithmIdentifier, 259 signature BIT STRING } 261 The client MAY incorporate one or more standard X.509 v3 extensions in 262 the request as an ExtensionReq attribute: 264 ExtensionReq ::= SEQUENCE OF Extension 266 where Extension is imported from PKIX Part 1 and ExtensionReq is 267 identified by the OID value {pkcs-9 14}. 269 5.2 Certification Response 271 Two options are established for the response to a certification request: 272 a simple form that enables basic interoperability and a form that 273 enables generation of subscriber private keys by the CA. 275 5.2.1 Use of SignedData 277 [CMS] supports a degenerate case of the SignedData content type where 278 there are no signers on the content. This degenerate case is used to 279 convey certificate and CRL information. Certification Authorities MAY 280 use this format for returning certificate information resulting from the 281 successful fulfillment of a certification request. The certificate 282 response MUST include the actual subject certificate corresponding to 283 the information in the certification request. The response SHOULD 284 include other certificates which link the issuer to higher level 285 certification authorities and corresponding CRLs. 287 CertRep ::= SEQUENCE { 288 response SignedData, OPTIONAL 289 rspInfo OCTET STRING } 291 Successful requests would include the resulting certificate(s) in the 292 response field along with any additional {name, value} information 293 useful to client-side processing of a successful request. In the event 294 of an unsuccessful request, the rspInfo field contains information 295 regarding the failure which may be useful to the requesting entity. 297 RspInfo content MAY include state information the PKI client needs such 298 as the contents of the regInfo in the CRMF ( see [CRMF]). Other 299 additional data could include detailed error information that uniquely 300 identifies an information field supplied in the original regInfo; e.g. 301 the Zip Code was incorrect for the specified address or locale or 302 billing failed because credit card information was in error. 304 5.2.2 CertRepContent 306 A CertRepContent data structure contains a CA public key, a status value 307 and optionally failure information, a subject certificate, and an 308 encrypted private key. 310 CertRepContent ::= SEQUENCE { 311 caPubs [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL, 312 response SEQUENCE of CertResponse } 314 CertResponse ::= SEQUENCE { 315 certReqId INTEGER, 316 -- to match this response with corresponding request (a value 317 -- of -1 is to be used if certReqId is not specified in the 318 -- corresponding request) 319 status PKIStatusInfo, 320 certifiedKeyPair CertifiedKeyPair, OPTIONAL } 322 CertifiedKeyPair ::= SEQUENCE { 323 certOrEncCert CertOrEncCert, 324 privateKey [0] EncryptedValue OPTIONAL, 325 publicationInfo [1] PKIPublicationInfo OPTIONAL } 327 CertOrEncCert ::= CHOICE { 328 certificate [0] Certificate, 329 encryptedCert [1] EncryptedValue } 331 Given an EncryptedCert and the relevant decryption key the certificate 332 may be obtained. The purpose of this is to allow a CA to return the 333 value of a certificate, but with the constraint that only the intended 334 recipient can obtain the actual certificate. The benefit of this 335 approach is that a CA may reply with a certificate even in the absence 336 of a proof that the requester is the end entity which can use the 337 relevant private key (note that the proof is not obtained until 338 confirmation of receipt is received by the CA). Thus the CA will not 339 have to revoke that certificate in the event that something goes wrong 340 with the proof of possession. 342 5.3 GetCertInitial 344 The GetCertInitial message is used to poll for the certificate 345 associated with prior request if the response to that prior request was 346 a CertRep message with a status of PENDING. 348 Certificates are normally referenced using the CA DN and the certificate 349 serial number. In this case however a certificate has not yet been 350 issued. Thus the CA and Subject DNs are present in the message as a 351 means to identify the requested certification. The certReqId field, if 352 used, contains a value that matches a corresponding value in a prior 353 certification request in the event multiple requests have been sent to a 354 CA and those requests contained a certReqId value. 356 IssuerAndSubject ::= SEQUENCE { 357 issuer Name, 358 subject Name, 359 certReqId INTEGER OPTIONAL } 361 5.4 GetCRL 363 This operation is used to retrieve CRLs from a certificate server or 364 service�s repository. This message is useful in circumstances where a 365 fully-deployed Directory is either infeasible or undesired. 367 The GetCRL message body consists of the following syntax: 369 GetCRL ::= SEQUENCE { 370 issuerName Name, 371 cRLName GeneralName, OPTIONAL 372 time GeneralizedTime, OPTIONAL 373 reasons ReasonFlags OPTIONAL } 375 The Name component is the value of the Issuer DN in the subject certifi- 376 cate. The cRLName component may be the value of CRLDistributionPoints in 377 the subject certificate or equivalent value in the event the certificate 378 does not contain such a value. The time component is used by the client 379 to specify from among potentially several issues of CRL that one whose 380 thisUpdate value is less than but nearest to the specified time. In the 381 absence of a time component, the CA always returns with the most recent 382 CRL. The reasonFlags field can be used to specify from among CRLs 383 partitioned by revocation reason. Implementors should bear in mind that 384 while a specific revocation request has a single CRLReason code--and 385 consequently entries in the CRL would have a single CRLReason code 386 value--a single CRL can aggregate information for one or more 387 reasonFlags. 389 5.5 Revocation Request 391 Two options are established to enable programmatic submission of a 392 revocation request. 394 5.5.1 RevRequest 396 RevRequests ::= SEQUENCE OF RevRequest 398 RevRequest ::= SEQUENCE { 399 issuerName Name, 400 serialNumber INTEGER, 401 reason CRLReason, 402 passphrase OCTET STRING OPTIONAL, 403 comment UTF8string OPTIONAL } 405 For a revocation request to become a reliable object in the event of a 406 dispute, a strong proof of originator authenticity is required. A 407 Registration Authority�s digital signature on the request can provide 408 this proof for certificates within the scope of the RA�s revocation 409 authority. However, in the instance when an end-entity has lost use of 410 their signature private key, it is impossible to produce a reliable 411 digital signature. [CRMF] provides for the use specification of a 412 passphrase during enrollment which may be used as an alternative 413 authenticator in the instance of loss of use. The acceptability of this 414 practice is a matter of local security policy. 416 5.5.2 RevReqContent 418 When requesting revocation of a certificate (or several certificates) 419 the following data structure is used. 421 RevReqContent ::= SEQUENCE OF RevDetails 423 RevDetails ::= SEQUENCE { 424 certDetails CertTemplate, 425 -- allows requester to specify as much as they can about 426 -- the cert. for which revocation is requested 427 -- (e.g., for cases in which serialNumber is not available) 428 revocationReason ReasonFlags, 429 -- from the Draft Amendment (DAM), so CA knows what to use in 430 -- Distribution point 431 badSinceDate GeneralizedTime OPTIONAL, 432 -- indicates best knowledge of sender 433 crlEntryDetails Extensions 434 -- requested crlEntryExtensions } 436 5.6 Revocation Response 438 The response to the RevReqContent message. If produced, this is sent to 439 the requester of the revocation. (A separate revocation announcement 440 message MAY be sent to the subject of the certificate for which 441 revocation was requested.) 443 RevRepContent ::= SEQUENCE { 444 status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo, 445 -- in same order as was sent in RevReqContent 446 revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL, 447 -- IDs for which revocation was requested (same order as status) 448 crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL 449 -- the resulting CRLs (there may be more than one) } 451 5.7 Challenge-Response Proof Of Possession 453 [CRMF] establishes the basis for a challenge-response proof of 454 possession technique. The challenge-response messages for proof of 455 possession of a private decryption key are specified as follows (see 456 [MvOV97, p.404], for details). 458 POPODecKeyChallContent ::= SEQUENCE OF Challenge 459 -- One Challenge per encryption key certification request (in the 460 -- same order as these requests appear in FullCertTemplates). 462 Challenge ::= SEQUENCE { 463 owf AlgorithmIdentifier OPTIONAL, 464 -- MUST be present in the first Challenge; MAY be omitted in any 465 -- subsequent Challenge in POPODecKeyChallContent (if omitted, 466 -- then the owf used in the immediately preceding Challenge is 467 -- to be used). 468 witness OCTET STRING, 469 -- the result of applying the one-way function (owf) to a 470 -- randomly-generated INTEGER, A. [Note that a different 471 -- INTEGER MUST be used for each Challenge.] 472 challenge OCTET STRING 473 -- the encryption (under the public key for which the cert. 474 -- request is being made) of Rand, where Rand is specified as 475 -- Rand ::= SEQUENCE { 476 -- int INTEGER, 477 -- - the randomly-generated INTEGER A (above) 478 -- sender GeneralName 479 -- - the sender's name 480 -- } 481 } 482 POPODecKeyRespContent ::= SEQUENCE OF INTEGER 483 -- One INTEGER per encryption key certification request (in the 484 -- same order as these requests appear in CertReqMessages). The 485 -- retrieved INTEGER A (above) is returned to the sender of the 486 -- corresponding Challenge. 488 It is recognized that, in general, there is a security risk associated 489 with the decryption of arbitrary data (that is, it is typically not 490 recommended that an entity decrypts arbitrary received ciphertext and 491 returns the corresponding, random-looking plaintext). This is because 492 obtaining the plaintext for carefully-chosen "ciphertexts" may in some 493 cases leak information or provide the challenger with signatures on 494 documents that the receiver had no intention of signing. 496 The witness parameter in the above challenge precludes such attacks 497 because it convincingly demonstrates to the receiver that the challenger 498 knew the plaintext that corresponds to each of the ciphertext challenges 499 prior to the exchange. Therefore, in a strict information-theoretic 500 sense, the challenger learns no information whatsoever other than the 501 fact that the receiver is in possession of the private key corresponding 502 to the public key for which certification is requested (which is what 503 this protocol is explicitly designed to show). Furthermore, the 504 challenger is not in possession of any data (e.g., a signature on a 505 document) after the exchange that it did not already possess prior to 506 the exchange. 508 5.8 PKI Confirmation content 510 This data structure is used in three-way protocols as the final 511 PKIMessage. Its content is the same in all cases - actually there is no 512 content since the PKIHeader carries all the required information. 514 PKIConfirmContent ::= NULL 516 5.9 Announcements 518 >From time to time a PKI may need to distribute information to its 519 clients or subscribers. These messages are generally unsolicited and 520 and may be received by end entities at random times. Implementers of 521 protocols that use these message formats should take this effect into 522 account. 524 5.9.1 CA Key Update Announcement content 526 When a CA updates its own key pair the following data structure MAY be 527 used to announce this event. 529 CAKeyUpdAnnContent ::= SEQUENCE { 530 oldWithNew Certificate, -- old pub signed with new priv 531 newWithOld Certificate, -- new pub signed with old priv 532 newWithNew Certificate -- new pub signed with new priv 533 } 535 To change the key of the CA, the CA does the following: 537 1.Generate a new key pair; 539 2.Create a certificate containing the old CA public key signed with 540 the new private key (the "old with new" certificate); 542 3.Create a certificate containing the new CA public key signed with 543 the old private key (the "new with old" certificate); 545 4.Create a certificate containing the new CA public key signed with 546 the new private key (the "new with new" certificate); 548 5.Publish these new certificates via the directory and/or other means 550 6.Export the new CA public key so that end entities may acquire it 551 using the "out-of-band" mechanism (if required). 553 The old CA private key is then no longer required. The old CA public key 554 will however remain in use for some time. The time when the old CA 555 public key is no longer required (other than for non-repudiation) will 556 be when all end entities of this CA have securely acquired the new CA 557 public key. 559 The "old with new" certificate must have a validity period starting at 560 the generation time of the old key pair and ending at the expiry date of 561 the old public key. 563 The "new with old" certificate must have a validity period starting at 564 the generation time of the new key pair and ending at the time by which 565 all end entities of this CA will securely possess the new CA public key 566 (at the latest, the expiry date of the old public key). 568 The "new with new" certificate must have a validity period starting at 569 the generation time of the new key pair and ending at the time by which 570 the CA will next update its key pair. 572 5.9.2 Certificate Announcement 574 This structure MAY be used to announce the existence of certificates. 576 Note that this message is intended to be used for those cases (if any) 577 where there is no pre-existing method for publication of certificates; 578 it is not intended to be used where, for example, X.500 is the 579 method for publication of certificates. 581 CertAnnContent ::= Certificate 583 5.9.3 CRL Announcement 585 When a CA issues a new CRL (or set of CRLs) the following data structure 586 MAY be used to announce this event. 588 CRLAnnContent ::= SEQUENCE OF CertificateList 590 5.9.4 Revocation Announcement 592 When a CA has revoked, or is about to revoke, a particular certificate 593 it MAY issue an announcement of this (possibly upcoming) event. 595 RevAnnContent ::= SEQUENCE { 596 status PKIStatus, 597 certId CertId, 598 willBeRevokedAt GeneralizedTime, 599 badSinceDate GeneralizedTime, 600 crlDetails Extensions OPTIONAL 601 -- extra CRL details(e.g., crl number, reason, location, etc.) 602 } 604 A CA MAY use such an announcement to warn (or notify) a subject that its 605 certificate is about to be (or has been) revoked. This would typically 606 be used where the request for revocation did not come from the subject 607 concerned. 609 The willBeRevokedAt field contains the time at which a new entry will be 610 added to the relevant CRLs. 612 5.10 Key recovery Response 614 For key recovery responses the following syntax is used. For some 615 status values (e.g., waiting) none of the optional fields will be 616 present. 618 KeyRecRepContent ::= SEQUENCE { 619 status PKIStatusInfo, 620 newSigCert [0] Certificate OPTIONAL, 621 caCerts [1] SEQUENCE SIZE (1..MAX) OF 622 Certificate OPTIONAL, 623 keyPairHist [2] SEQUENCE SIZE (1..MAX) OF 624 CertifiedKeyPair OPTIONAL 625 } 627 5.11 PKI General Message content 629 >From time to time a PKI MAY announce other information not explicitly 630 called out in this specification. In such cases the following structure 631 MAY be used to unambiguously identify this information when transmitted 632 as a PKI message. 634 InfoTypeAndValue ::= SEQUENCE { 635 infoType OBJECT IDENTIFIER, 636 infoValue ANY DEFINED BY infoType OPTIONAL 637 } 638 -- This construct MAY also be used to define new PKIX Certificate 639 -- Management Protocol request and response messages, or general- 640 -- purpose (e.g., announcement) messages for future needs or for 641 -- specific environments. 643 GenMsgContent ::= SEQUENCE OF InfoTypeAndValue 644 -- May be sent by EE, RA, or CA (depending on message content). 645 -- The OPTIONAL infoValue parameter of InfoTypeAndValue will typically 646 -- be omitted for some of the examples given above. The receiver is 647 -- free to ignore any contained OBJ. IDs that it does not recognize. 648 -- If sent from EE to CA, the empty set indicates that the CA may send 649 -- any/all information that it wishes. 651 5.12 PKI General Response content 653 GenRepContent ::= SEQUENCE OF InfoTypeAndValue 654 -- The receiver is free to ignore any contained OBJ. IDs that it does 655 -- not recognize. 657 5.13 Error Message 659 ErrorMsgContent ::= SEQUENCE { 660 pKIStatusInfo PKIStatusInfo, 661 errorCode INTEGER OPTIONAL, 662 -- implementation-specific error codes 663 errorDetails PKIFreeText OPTIONAL 664 -- implementation-specific error details 665 } 667 6. SECURITY CONSIDERATIONS 669 This entire memo is about security mechanisms. 671 One cryptographic consideration is worth explicitly spelling out. In 672 the protocols specified above, when an end entity is required to 673 prove possession of a decryption key, it is effectively challenged 674 to decrypt something (its own certificate). This scheme (and many 675 others!) could be vulnerable to an attack if the possessor of the 676 decryption key in question could be fooled into decrypting an 677 arbitrary challenge and returning the cleartext to an attacker. 678 Although in this specification a number of other failures in 679 security are required in order for this attack to succeed, it is 680 conceivable that some future services (e.g., notary, trusted time) 681 could potentially be vulnerable to such attacks. For this reason we 682 re-iterate the general rule that implementations should be very 683 careful about decrypting arbitrary "ciphertext" and revealing 684 recovered "plaintext" since such a practice can lead to serious 685 security vulnerabilities. 687 7. References 689 [COR95] ISO/IEC JTC 1/SC 21, Technical Corrigendum 2 to ISO/IEC 690 9594-8: 1990 & 1993 (1995:E), July 1995. 692 [MvOV97] A. Menezes, P. van Oorschot, S. Vanstone, "Handbook of 693 Applied Cryptography", CRC Press, 1997. 695 [PKCS7] RSA Laboratories, "The Public-Key Cryptography Standards 696 (PKCS)", RSA Data Security Inc., Redwood City, California, 697 November 1993 Release. 699 [PKCS10] RSA Laboratories, "The Public-Key Cryptography Standards 700 (PKCS)", RSA Data Security Inc., Redwood City, California, 701 November 1993 Release. 703 [PKCS11] RSA Laboratories, "The Public-Key Cryptography Standards - 704 PKCS #11: Cryptographic token interface standard", RSA 705 Data Security Inc., Redwood City, California, April 28, 706 1995. 708 [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed Hashing 709 for Message Authentication", Internet Request for Comments 710 2104, February, 1997. 712 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 713 Requirement Levels", Internet Request for Comments 2119 714 (Best Current Practice: BCP 14), March, 1997. 716 [X509-AM] ISO/IEC JTC1/SC 21, Draft Amendments DAM 4 to ISO/IEC 717 9594-2, DAM 2 to ISO/IEC 9594-6, DAM 1 to ISO/IEC 9594-7, 718 and DAM 1 to ISO/IEC 9594-8 on Certificate Extensions, 719 1 December, 1996. 721 [CRMF] M. Myers, C. Adams, D. Solo, D. Kemp, 722 Certificate Request Message Format, 723 , 724 May, 1998 726 [CMS] R. Housley, Cryptographic Message Syntax 727 728 December, 1997 730 [PKCS8] Private Key Information Syntax Standard, v1.2 731 RSA Laboratories Technical Note 732 November 1, 1993 734 Authors' Addresses 735 Michael Myers 736 VeriSign, Inc. 737 1390 Shorebird Way, 738 Mountain View, CA 94043 739 mmyers@verisign.com 741 Carlisle Adams 742 Entrust Technologies 743 750 Heron Road, Suite E08, 744 Ottawa, Ontario 745 Canada K1V 1A7 746 cadams@entrust.com