idnits 2.17.1 draft-brockhaus-lamps-cmp-updates-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4210, updated by this document, for RFC5378 checks: 2000-03-07) -- 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 (November 3, 2019) is 1635 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 568 == Missing Reference: 'CRMF' is mentioned on line 563, but not defined -- Looks like a reference, but probably isn't: '1' on line 569 ** Downref: Normative reference to an Informational RFC: RFC 2986 == Outdated reference: A later version (-03) exists of draft-brockhaus-lamps-lightweight-cmp-profile-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Brockhaus 3 Internet-Draft Siemens 4 Updates: 4210 (if approved) November 3, 2019 5 Intended status: Standards Track 6 Expires: May 6, 2020 8 CMP Updates 9 draft-brockhaus-lamps-cmp-updates-01 11 Abstract 13 This document contains a set of updates to the base syntax of 14 Certificate Management Protocol (CMP) version 2. This document 15 updates RFC 4210. 17 Specifically, the CMP services updated in this document comprise the 18 enabling of using EnvelopedData instead of EncryptedValue and the 19 definition of extended key usages to identify certificates of CMP 20 endpoints on certification and registration authorities. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 6, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. History of changes . . . . . . . . . . . . . . . . . . . . . 2 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Convention and Terminology . . . . . . . . . . . . . . . 3 59 3. Updates to RFC 4210 - Certificate Management Protocol (CMP) . 3 60 3.1. New Section 1.1. - Changes since RFC 4210 . . . . . . . . 3 61 3.2. New Section 4.5 - Extended Key Usage . . . . . . . . . . 4 62 3.3. Replace Section 5.1.3.4 - Multiple Protection . . . . . . 5 63 3.4. Replace Section 5.2.2. - Encrypted Values . . . . . . . . 5 64 3.5. Update Section 5.3.4. - Certification Response . . . . . 7 65 3.6. Update Section 5.3.19.9. - Revocation Passphrase . . . . 8 66 3.7. New Section - Polling Request and Response . . . . . . . 8 67 3.8. Update Appendix B - The Use of Revocation Passphrase . . 9 68 3.9. Update Appendix C - Request Message Behavioral 69 Clarifications . . . . . . . . . . . . . . . . . . . . . 10 70 3.10. Update Appendix D.4. - Initial Registration/Certification 71 (Basic Authenticated Scheme) . . . . . . . . . . . . . . 10 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 77 7.2. Informative References . . . . . . . . . . . . . . . . . 12 78 Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . 12 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 81 1. History of changes 83 From version 00 -> 01: 85 o Add a section describing the new extended key usages 87 o Complete the section on changes to the specification of encrypted 88 values 90 o Add a section on a clarification to Appendix D.4 92 o Add a section describing the new extended key usages 94 o Minor generalization in sections 5.1.3.4 and 5.3.22 96 o Minor changes in wording 98 2. Introduction 100 While using CMP [RFC4210] in industrial and IoT environments and 101 developing the Lightweight CMP Profile 102 [I-D.brockhaus-lamps-lightweight-cmp-profile] some limitations were 103 identified in the original CMP specification. This document updates 104 RFC 4210 [RFC4210] to overcome these limitations. 106 In general this document aims to improve the crypto agility of CMP to 107 be flexible to react on future advances in cryptography. 109 This document also introduces new extended key usages to identify CMP 110 services on registration and certification authorities. 112 2.1. Convention and Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 In this document, these words will appear with that interpretation 119 only when in ALL CAPS. Lower case uses of these words are not to be 120 interpreted as carrying significance described in RFC 2119. 122 Technical terminology is used in conformance with RFC 4210 [RFC4210], 123 RFC 4211 [RFC4211], and RFC 5280 [RFC5280]. The following key words 124 are used: 126 CA: Certification authority, which issues certificates. 128 RA: Registration authority, an optional system component to which 129 a CA delegates certificate management functions such as 130 authorization checks. 132 KGA: Key generation authority, which generates key pairs on behalf 133 of an EE. The KGA could be co-located with a RA or a CA. 135 EE: End entity, a user, device, or service that holds a PKI 136 certificate. An identifier for the EE is given as its 137 subject of the certificate. 139 3. Updates to RFC 4210 - Certificate Management Protocol (CMP) 141 3.1. New Section 1.1. - Changes since RFC 4210 143 The following subsections describe feature updates to RFC 4210 144 [RFC4210]. They are always related to the base specification. Hence 145 references to the original sections in RFC 4210 [RFC4210] are used 146 whenever possible. 148 Insert this section at the end of the current Section 1. 150 The following updates were made since RFC 4210: 152 o Offering envelopedData as another choice next to EncryptedValue to 153 extend crypto agility in CMP. Note that according to RFC 4211 154 [RFC4211] section 2.1.9 the use of the EncryptedValue structure 155 has been deprecated in favor of the EnvelopedData structure. For 156 reasons of completeness and consistency the exchange of 157 EncryptedValue with EncryptedKey is performed not only where 158 required for the needed crypto agility for protection of centrally 159 generated private key, but also for other purposes like encryption 160 of certificates and revocation passphrases. 162 o Add new extended key usages for different CMP server types, e.g. 163 Registration authority and certification authority. 165 3.2. New Section 4.5 - Extended Key Usage 167 Insert this section. 169 The Extended Key Usage (EKU) extension indicates the purposes for 170 which the certified public key may be used. It therefore restricts 171 the use of a certificate to specific applications. Certificates used 172 for CMP message protection or signed data for central key generation 173 SHOULD use one of the following EKUs to express its authorization for 174 acting as the PKI management entities described below. The ASN.1 to 175 define these EKUs is: 177 id-kp-cmpCA OBJECT IDENTIFIER ::= { id-kp ... } 178 id-kp-cmpRA OBJECT IDENTIFIER ::= { id-kp ... } 179 id-kp-cmpKGA OBJECT IDENTIFIER ::= { id-kp ... } 181 < TBD: IDs to be defined. > 183 The description of the PKI entity for each of the EKUs is as follows: 185 CMP Certification Authorities as described in section 3.1.1.2 are 186 identified by the id-kp-cmpCA extended key usage in the context of 187 CMP management operations, especially CMP message protection. The 188 certificate may be the same as or different than the CA uses to sign 189 a certificate. If a different certificate is used for CMP management 190 operations, the certificates containing the id-kp-cmpCA extended key 191 usage SHOULD have the same name as the certificate used for issuing 192 certificates. 194 Note: Using a separate key pair for protecting CMP management 195 operations at the CA decreases the number of operations of the 196 private key used to sign certificates. 198 CMP Registration Authorities as described in section 3.1.1.3 are 199 identified by the id-kp-cmpRA extended key usage. This usage is 200 placed into RA certificates. 202 CMP Key Generation Authorities are identified by the id-kp-cmPKGA 203 extended key usage. Though the KGA knows the private key it 204 generated on behalf of the end entity, this is a very sensible 205 service and needs specific authorization. This authorization is 206 indicated by placing the id-kp-cmpKGA extended key usage into the RA 207 or CA certificate used to protect the origin of the private key to 208 express the aithorization to offer this service. 210 3.3. Replace Section 5.1.3.4 - Multiple Protection 212 Section 5.1.3.4 of RFC 4210 [RFC4210] describes the nested Message. 213 This document deletes the stipulation that all PKI messages contained 214 in a nested message must be of the same type. 216 Replace the last paragraph in Section 5.1.3.4 with the following 217 text. 219 (The use of PKIMessages, a SEQUENCE OF PKIMessage, lets the RA batch 220 the requests of several EEs in a single new message.) If the RA 221 wishes to modify the message(s) in some way (e.g., add particular 222 field values or new extensions), then it MAY create its own desired 223 PKIBody. The original PKIMessage from the EE MAY be included in the 224 generalInfo field of PKIHeader (to accommodate, for example, cases in 225 which the CA wishes to check POP or other information on the original 226 EE message). The infoType to be used in this situation is {id-it 15} 227 (see Section 5.3.19 for the value of id-it) and the infoValue is 228 PKIMessages (contents MUST be in the same order as the requests in 229 PKIBody). 231 3.4. Replace Section 5.2.2. - Encrypted Values 233 Section 5.2.2 of RFC 4210 [RFC4210] describes the usage of 234 EncryptedValue to transport encrypted data. This document extends 235 the encryption of data to also use EnvelopedData. 237 Replace the text of the section with the following text. 239 Where encrypted data (restricted, in this specification, to be either 240 private keys, certificates or passwords) are sent in PKI messages, 241 the EncryptedKey data structure is used. 243 EncryptedKey ::= CHOICE { 244 encryptedValue EncryptedValue, -- deprecated 245 envelopedData [0] EnvelopedData } 247 See CRMF [RFC4211] for EncryptedKey and EncryptedValue syntax and for 248 EnvelopedData syntax see CMS [RFC5652]. Using the EncryptedKey data 249 structure, the choice to either use EncryptedValue (for backward 250 compatibility only) or EnvelopedData is offered. The use of the 251 EncryptedValue structure has been deprecated in favor of the 252 EnvelopedData structure. Therefore, it is recommended to use 253 EnvelopedData. 255 The EncryptedKey data structure is used in CMP to either transport a 256 private key, certificate or revocation passphrase in encrypted form. 258 EnvelopedData is used as follows: 260 o Contains only one recepientInfo structure because the content is 261 encrypted only for one recipient. 263 o Contains the private key in a SignedData structure as specified in 264 CMS section 5 [RFC5652] signed by the Key Generation Authority. 266 o Contains the certificate or revocation passphrase directly in the 267 encryptedContent field. 269 Note: When transferring a centrally generated private key in a 270 certificate response message to the EE, the algorithm identifier and 271 the associated public key will anyhow be transported in this response 272 message. Therefore, the private key will not be delivered in a key 273 package structure as specified in [RFC5958] and [RFC6032]. But the 274 wrapping of the private key in a SignedData structure that is wrapped 275 in an this EnvelopedData structure as specified in [RFC6032] is 276 applied here. 278 The content of the EnvelopedData structure, as specified in CMS 279 section 3 [RFC5652], MUST be encrypted using a newly generated 280 symmetric content-encryption key. This content-encryption key MUST 281 be securely provided to the recipient using one of three key 282 management techniques. 284 The choice of the key management technique to be used by the sender 285 depends on the ceredential available for the recitpient: 287 o Jointly shared secret: The content-encryption key will be 288 protected using the symmetric key-encryption key management 289 technique, as specified in CMS section 5.2.3 [RFC5652]. 291 o Recipient's certificate that contains a key usage extension 292 asserting keyAgreement: The content-encryption key will be 293 protected using the key agreement key management technique, as 294 specified in CMS section 5.2.2 [RFC5652]. 296 o Recipient's certificate that contains a key usage extension 297 asserting keyEncipherment: The content-encryption key will be 298 protected using the key transport key management technique, as 299 specified in CMS section 5.2.1 [RFC5652]. 301 The EncryptedValue data structure MAY be used for backward 302 compatibility reasons. Use of this data structure requires that the 303 creator and intended recipient be able to encrypt and decrypt, 304 respectively. Typically, this will mean that the sender and 305 recipient have, or are able to generate, a shared secret key. If the 306 recipient of the PKIMessage already possesses a private key usable 307 for decryption, then the encSymmKey field MAY contain a session key 308 encrypted using the corresponding recipient's public key. 310 3.5. Update Section 5.3.4. - Certification Response 312 Section 5.3.4 of RFC 4210 [RFC4210] describes the Certification 313 Response. This document updates the syntax by using EncryptedKey 314 instead of EncryptedValue as described in Section 3.1 above. 316 Replace the ASN.1 syntax of CertifiedKeyPair and CertOrEncCert with 317 the following text. 319 CertifiedKeyPair ::= SEQUENCE { 320 certOrEncCert CertOrEncCert, 321 privateKey [0] EncryptedKey OPTIONAL, 322 -- see [CRMF] for comment on encoding 323 publicationInfo [1] PKIPublicationInfo OPTIONAL 324 } 326 CertOrEncCert ::= CHOICE { 327 certificate [0] Certificate, 328 encryptedCert [1] EncryptedKey 329 } 331 Add the following paragraphs to the end of the section. 333 The use of EncryptedKey is described in section 5.2.2. 335 3.6. Update Section 5.3.19.9. - Revocation Passphrase 337 Section 5.3.19.9 of RFC 4210 [RFC4210] describes the provisioning of 338 a revocation passphrase for authenticating a later revocation 339 request. This document updates the handling by using EncryptedKey 340 instead of EncryptedValue to transport this information as described 341 in Section 3.1 above. 343 Replace the text of the section with the following text. 345 The revocation passphrase MAY be used by the EE to send a passphrase 346 to a CA/RA for the purpose of authenticating a later revocation 347 request (in the case that the appropriate signing private key is no 348 longer available to authenticate the request). See Appendix B for 349 further details on the use of this mechanism. 351 GenMsg: {id-it 12}, EncryptedKey 352 GenRep: {id-it 12}, < absent > 354 The use of EncryptedKey is described in section 5.2.2. 356 3.7. New Section - Polling Request and Response 358 Section 5.3.22 of RFC 4210 [RFC4210] describes when and how polling 359 messages are used. This document adds the polling mechanism also to 360 outstanding p10cr transactions. 362 Replace the all paragraphs in front of the state machine diagram in 363 Section 5.3.22 with the following text. 365 This pair of messages is intended to handle scenarios in which the 366 client needs to poll the server in order to determine the status of 367 an outstanding ir, cr, p10cr, or kur transaction (i.e., when the 368 "waiting" PKIStatus has been received). 370 PollReqContent ::= SEQUENCE OF SEQUENCE { 371 certReqId INTEGER } 373 PollRepContent ::= SEQUENCE OF SEQUENCE { 374 certReqId INTEGER, 375 checkAfter INTEGER, -- time in seconds 376 reason PKIFreeText OPTIONAL } 378 The following clauses describe when polling messages are used, and 379 how they are used. It is assumed that multiple certConf messages can 380 be sent during transactions. There will be one sent in response to 381 each ip, cp, or kup that contains a CertStatus for an issued 382 certificate. 384 1 In response to an ip, cp, or kup message, an EE will send a 385 certConf for all issued certificates and, following the ack, a 386 pollReq for all pending certificates. 388 2 In response to a pollReq, a CA/RA will return an ip, cp, or kup if 389 one or more of the pending certificates is ready; otherwise, it 390 will return a pollRep. 392 3 If the EE receives a pollRep, it will wait for at least as long as 393 the checkAfter value before sending another pollReq. 395 4 If an ip, cp, or kup is received in response to a pollReq, then it 396 will be treated in the same way as the initial response. 398 Note: As the PKCS#10 [RFC2986] does not contain a certificate request 399 number, it is assumed that there is only one CertificationRequestInfo 400 data structure in a p10cr message and the certReqId is to be det to 0 401 in all following messages of this transaction. 403 3.8. Update Appendix B - The Use of Revocation Passphrase 405 Appendix B of RFC 4210 [RFC4210] describes the usage of the 406 revocation passphrases. As this document updates RFC 4210 [RFC4210] 407 to utilize EncryptedKey in favor of EncryptedValue as described in 408 Section 3.1 above, the description is updated accordingly. 410 Replace the first bullet point of this section with the following 411 text. 413 o The OID and value specified in Section 5.3.19.9 of RFC 4210 414 [RFC4210] MAY be sent in a GenMsg message at any time, or MAY be 415 sent in the generalInfo field of the PKIHeader of any PKIMessage 416 at any time. (In particular, the EncryptedKey as described in 417 section 5.2.2 may be sent in the header of the certConf message 418 that confirms acceptance of certificates requested in an 419 initialization request or certificate request message.) This 420 conveys a revocation passphrase chosen by the entity (i.e., for 421 use of EnvelopedData this is in the decrypted bytes of 422 encryptedContent of the EnvelopedData structure and for use of 423 EncryptedValue this is in the decrypted bytes of the encValue 424 field) to the relevant CA/RA; furthermore, the transfer is 425 accomplished with appropriate confidentiality characteristics. 427 Replace the third bullet point of this section with the following 428 text. 430 o When using EnvelopedData the contentType of EncryptedContentInfo 431 and when using EncryptedValue the valueHint field MAY contain a 432 key identifier (chosen by the entity, along with the passphrase 433 itself) to assist in later retrieval of the correct passphrase 434 (e.g., when the revocation request is constructed by the entity 435 and received by the CA/RA). 437 3.9. Update Appendix C - Request Message Behavioral Clarifications 439 Appendix C of RFC 4210 [RFC4210] provides clarifications to the 440 request message behavior. As this document updates RFC 4210 441 [RFC4210] to utilize EncryptedKey in favor of EncryptedValue as 442 described in Section 3.1 above, the description is updated 443 accordingly. 445 Replace the note coming after the ASN.1 syntax of POPOPrivKey of this 446 section with the following text. 448 -- ********** 449 -- * the type of "thisMessage" is given as BIT STRING in RFC 4211 450 -- * [RFC4211]; it should be "EncryptedKey" (in accordance with 451 -- * Section 5.2.2, "Encrypted Values", of this specification). 452 -- * Therefore, this document makes the behavioral clarification of 453 -- * specifying that the contents of "thisMessage" MUST be encoded 454 -- * either as EnvelopedData or EncryptedValue (only for backward 455 -- * compatibility) and then wrapped in a BIT STRING. This allows 456 -- * the necessary conveyance and protection of the private key 457 -- * while maintaining bits-on-the-wire compatibility with RFC 4211 458 -- * [RFC4211]. 459 -- ********** 461 3.10. Update Appendix D.4. - Initial Registration/Certification (Basic 462 Authenticated Scheme) 464 Appendix D.4 of RFC 4210 [RFC4210] provides the initial registration/ 465 certification scheme. This scheme shall continue to use 466 EncryptedValue for backward compatibility reasons. 468 Replace the comment after the privateKey field of 469 crc[1].certifiedKeyPair in the syntax of the Initialization Response 470 message with the following text. 472 -- see Appendix C, Request Message Behavioral Clarifications 473 -- for backward compatibility reasons, use EncryptedValue 475 4. IANA Considerations 477 479 5. Security Considerations 481 No changes are made to the existing security considerations of 482 RFC 4210 [RFC4210]. 484 6. Acknowledgements 486 Special thank goes to Jim Schaad his guidance and for the inspiration 487 I got from [RFC6402] that updates CMC in a similar manner. 489 I also like to thank all reviewers of this document for their 490 valuable feedback. 492 7. References 494 7.1. Normative References 496 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 497 Requirement Levels", BCP 14, RFC 2119, 498 DOI 10.17487/RFC2119, March 1997, 499 . 501 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 502 Request Syntax Specification Version 1.7", RFC 2986, 503 DOI 10.17487/RFC2986, November 2000, 504 . 506 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 507 "Internet X.509 Public Key Infrastructure Certificate 508 Management Protocol (CMP)", RFC 4210, 509 DOI 10.17487/RFC4210, September 2005, 510 . 512 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 513 Certificate Request Message Format (CRMF)", RFC 4211, 514 DOI 10.17487/RFC4211, September 2005, 515 . 517 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 518 Housley, R., and W. Polk, "Internet X.509 Public Key 519 Infrastructure Certificate and Certificate Revocation List 520 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 521 . 523 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 524 RFC 5652, DOI 10.17487/RFC5652, September 2009, 525 . 527 7.2. Informative References 529 [I-D.brockhaus-lamps-lightweight-cmp-profile] 530 Brockhaus, H., Fries, S., and D. Oheimb, "Lightweight CMP 531 Profile", draft-brockhaus-lamps-lightweight-cmp-profile-00 532 (work in progress), July 2019. 534 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 535 DOI 10.17487/RFC5958, August 2010, 536 . 538 [RFC6032] Turner, S. and R. Housley, "Cryptographic Message Syntax 539 (CMS) Encrypted Key Package Content Type", RFC 6032, 540 DOI 10.17487/RFC6032, December 2010, 541 . 543 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 544 Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, 545 . 547 Appendix A. ASN.1 Modules 549 Changes to the following parts are needed 551 o Import from PKIKXCRMF-2005 553 CertTemplate, PKIPublicationInfo, EncryptedKey, CertId, 554 CertReqMessages 555 FROM PKIXCRMF-2005 {iso(1) identified-organization(3) 556 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 557 id-mod(0) id-mod-crmf2005(36)} 559 o In CertifiedKeyPair, CertOrEncCert and id-it-revPassphrase 560 CertifiedKeyPair ::= SEQUENCE { 561 certOrEncCert CertOrEncCert, 562 privateKey [0] EncryptedKey OPTIONAL, 563 -- see [CRMF] for comment on encoding 564 publicationInfo [1] PKIPublicationInfo OPTIONAL 565 } 567 CertOrEncCert ::= CHOICE { 568 certificate [0] CMPCertificate, 569 encryptedCert [1] EncryptedKey 570 } 572 -- id-it-revPassphrase OBJECT IDENTIFIER ::= {id-it 12} 573 -- RevPassphraseValue ::= EncryptedKey 575 -- 576 -- Extended Key Usage extension for PKI entities used in 577 -- CMP operations 578 -- 580 id-kp-cmpCA OBJECT IDENTIFIER ::= { id-kp ... } 581 id-kp-cmpRA OBJECT IDENTIFIER ::= { id-kp ... } 582 id-kp-cmpKGA OBJECT IDENTIFIER ::= { id-kp ... } 583 < TBD: IDs to be defined. > 585 < TBD: If needed the complete ASN.1 Module from RFC 4210 section 586 needs to be copied here. > 588 Author's Address 590 Hendrik Brockhaus 591 Siemens AG 592 Otto-Hahn-Rin 6 593 Munich 81739 594 Germany 596 Email: hendrik.brockhaus@siemens.com 597 URI: http://www.siemens.com/