idnits 2.17.1 draft-ietf-lamps-rfc7030est-clarify-10.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 -- The document date (August 11, 2020) is 1354 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2046' is mentioned on line 366, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IEC62351' ** Downref: Normative reference to an Informational RFC: RFC 2986 ** Downref: Normative reference to an Informational RFC: RFC 5912 ** Downref: Normative reference to an Informational RFC: RFC 6268 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-43 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LAMPS Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Updates: 7030 (if approved) T. Werner 5 Intended status: Standards Track Siemens 6 Expires: February 12, 2021 W. Pan 7 Huawei Technologies 8 August 11, 2020 10 Clarification of Enrollment over Secure Transport (EST): transfer 11 encodings and ASN.1 12 draft-ietf-lamps-rfc7030est-clarify-10 14 Abstract 16 This document updates RFC7030: Enrollment over Secure Transport (EST) 17 to resolve some errata that were reported, and which have proven to 18 cause interoperability issues when RFC7030 was extended. 20 This document deprecates the specification of "Content-Transfer- 21 Encoding" headers for EST endpoints. This document fixes some 22 syntactical errors in ASN.1 that were present. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on February 12, 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Changes to EST endpoint processing . . . . . . . . . . . . . 3 61 3.1. Whitespace processing . . . . . . . . . . . . . . . . . . 4 62 3.2. Changes sections 4 of RFC7030 . . . . . . . . . . . . . . 4 63 3.2.1. Section 4.1.3 . . . . . . . . . . . . . . . . . . . . 4 64 3.2.2. Section 4.3.1 . . . . . . . . . . . . . . . . . . . . 4 65 3.2.3. Section 4.3.2 . . . . . . . . . . . . . . . . . . . . 5 66 3.2.4. Section 4.4.2 . . . . . . . . . . . . . . . . . . . . 5 67 3.2.5. Section 4.5.2 . . . . . . . . . . . . . . . . . . . . 5 68 4. Clarification of ASN.1 for Certificate Attribute set. . . . . 6 69 5. Clarification of error messages for certificate enrollment 70 operations . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 5.1. Updating section 4.2.3: Simple Enroll and Re-enroll 72 Response . . . . . . . . . . . . . . . . . . . . . . . . 8 73 5.2. Updating section 4.4.2: Server-Side Key Generation 74 Response . . . . . . . . . . . . . . . . . . . . . . . . 8 75 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 81 10.2. Informative References . . . . . . . . . . . . . . . . . 11 82 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 85 1. Introduction 87 Enrollment over Secure Transport (EST) is defined in [RFC7030]. The 88 EST specification defines a number of HTTP end points for certificate 89 enrollment and management. The details of the transaction were 90 defined in terms of MIME headers as defined in [RFC2045], rather than 91 in terms of the HTTP protocol as defined in [RFC7230] and [RFC7231]. 93 [RFC2616] and later [RFC7231] Appendix A.5 has text specifically 94 deprecating Content-Transfer-Encoding. However, [RFC7030] 95 incorrectly uses this header. 97 Any updates to [RFC7030] to bring it inline with HTTP processing risk 98 changing the on-wire protocol in a way that is not backwards 99 compatible. However, reports from implementers suggest that many 100 implementations do not send the Content-Transfer-Encoding, and many 101 of them ignore it. The consequence is that simply deprecating the 102 header would remain compatible with current implementations. 104 [I-D.ietf-anima-bootstrapping-keyinfra] extends [RFC7030], adding new 105 functionality, and interop testing of the protocol has revealed that 106 unusual processing called out in [RFC7030] causes confusion. 108 EST is currently specified as part of [IEC62351], and is widely used 109 in Government, Utilities and Financial markets today. 111 This document therefore revises [RFC7030] to reflect the field 112 reality, deprecating the extraneous field. 114 This document deals with errata numbers [errata4384], [errata5107], 115 [errata5108], and [errata5904]. 117 This document deals with [errata5107] and [errata5904] in Section 3. 118 [errata5108] is dealt with in Section 5. [errata4384] is closed by 119 correcting the ASN.1 Module in Section 4. 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in 126 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 3. Changes to EST endpoint processing 131 The [RFC7030] sections 4.1.3 (CA Certificates Response, /cacerts), 132 4.3.1/4.3.2 (Full CMC, /fullcmc), 4.4.2 (Server-Side Key Generation, 133 /serverkeygen), and 4.5.2 (CSR Attributes, /csrattrs) specify the use 134 of base64 encoding with a Content-Transfer-Encoding for requests and 135 response. 137 This document updates [RFC7030] to require the POST request and 138 payload response of all endpoints use Base64 encoding as specified in 139 Section 4 of [RFC4648]. In both cases, the Distinguished Encoding 140 Rules (DER) [X.690] are used to produce the input for the Base64 141 encoding routine. This format is to be used regardless of any 142 Content-Transfer-Encoding header, and any value in such a header MUST 143 be ignored. 145 3.1. Whitespace processing 147 Note that "base64" as used in the HTTP [RFC2616] does not permit 148 CRLF, while the "base64" used in MIME [RFC2045] does. This 149 specification clarifies that despite [RFC2616], that white space 150 including CR, LF, spaces (ASCII 32) and, tabs (ASCII 9) SHOULD be 151 tolerated by receivers. Senders are not required to insert any kind 152 of white space. 154 3.2. Changes sections 4 of RFC7030 156 3.2.1. Section 4.1.3 158 Replace: 160 A successful response MUST be a certs-only CMC Simple PKI Response, 161 as defined in [RFC5272], containing the certificates described in the 162 following paragraph. The HTTP content-type of 163 "application/pkcs7-mime" is used. The Simple PKI Response is sent 164 with a Content-Transfer-Encoding of "base64" [RFC2045]. 166 with: (RFCEDITOR: maybe artwork is the wrong choice here) 168 A successful response MUST be a certs-only CMC Simple PKI Response, 169 as defined in [RFC5272], containing the certificates described in the 170 following paragraph. The HTTP content-type of 171 "application/pkcs7-mime" is used. The CMC Simple PKI Response is 172 encoded in base64 [RFC4648]. 174 3.2.2. Section 4.3.1 176 Replace: 178 If the HTTP POST to /fullcmc is not a valid Full PKI Request, the 179 server MUST reject the message. The HTTP content-type used is 180 "application/pkcs7-mime" with an smime-type parameter "CMC-request", 181 as specified in [RFC5273]. The body of the message is the binary 182 value of the encoding of the PKI Request with a 183 Content-Transfer-Encoding of "base64" [RFC2045]. 185 with: 187 If the HTTP POST to /fullcmc is not a valid Full PKI Request, the 188 server MUST reject the message. The HTTP content-type used is 189 "application/pkcs7-mime" with an smime-type parameter "CMC-request", 190 as specified in [RFC5273]. The body of the message is encoded 191 in base64 [RFC4648]. 193 3.2.3. Section 4.3.2 195 Replace: 197 The body of the message is the binary value of the encoding of the 198 PKI Response with a Content-Transfer-Encoding of "base64" [RFC2045]. 200 with: 202 The body of the message is the base64 [RFC4648] encoding of the 203 PKI Response. 205 3.2.4. Section 4.4.2 207 Replace: 209 An "application/pkcs8" 210 part consists of the base64-encoded DER-encoded [X.690] 211 PrivateKeyInfo with a Content-Transfer-Encoding of "base64" 212 [RFC4648]. 214 with: 216 An "application/pkcs8" part consists of the base64-encoded 217 DER-encoded [X.690] PrivateKeyInfo. 219 Replace: 221 In all three additional encryption cases, the EnvelopedData is 222 returned in the response as an "application/pkcs7-mime" part with an 223 smime-type parameter of "server-generated-key" and a Content- 224 Transfer-Encoding of "base64". 226 with: 228 In all three additional encryption cases, the EnvelopedData is 229 returned in the response as an "application/pkcs7-mime" part 230 with an smime-type parameter of "server-generated-key". It is 231 base64 encoded [RFC4648]. 233 3.2.5. Section 4.5.2 235 This section is updated in its entirety in Section 4. 237 4. Clarification of ASN.1 for Certificate Attribute set. 239 Section 4.5.2 of [RFC7030] is to be replaced with the following text: 241 4.5.2 CSR Attributes Response 243 If locally configured policy for an authenticated EST client 244 indicates a CSR Attributes Response is to be provided, the server 245 response MUST include an HTTP 200 response code. An HTTP response 246 code of 204 or 404 indicates that a CSR Attributes Response is not 247 available. Regardless of the response code, the EST server and CA 248 MAY reject any subsequent enrollment requests for any reason, e.g., 249 incomplete CSR attributes in the request. 251 Responses to attribute request messages MUST be encoded as the 252 content-type of "application/csrattrs", and are to be "base64" 253 [RFC4648] encoded. The syntax for application/csrattrs body is as 254 follows: 256 CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID 258 AttrOrOID ::= CHOICE { 259 oid OBJECT IDENTIFIER, 260 attribute Attribute {{AttrSet}} } 262 AttrSet ATTRIBUTE ::= { ... } 264 An EST server includes zero or more OIDs or attributes [RFC2986] that 265 it requests the client to use in the certification request. The 266 client MUST ignore any OID or attribute it does not recognize. When 267 the server encodes CSR Attributes as an empty SEQUENCE, it means that 268 the server has no specific additional information it desires in a 269 client certification request (this is functionally equivalent to an 270 HTTP response code of 204 or 404). 272 If the CA requires a particular cryptographic algorithm or use of a 273 particular signature scheme (e.g., certification of a public key 274 based on a certain elliptic curve, or signing using a certain hash 275 algorithm) it MUST provide that information in the CSR Attribute 276 Response. If an EST server requires the linking of identity and POP 277 information (see Section 3.5), it MUST include the challengePassword 278 OID in the CSR Attributes Response. 280 The structure of the CSR Attributes Response SHOULD, to the greatest 281 extent possible, reflect the structure of the CSR it is requesting. 282 Requests to use a particular signature scheme (e.g. using a 283 particular hash function) are represented as an OID to be reflected 284 in the SignatureAlgorithm of the CSR. Requests to use a particular 285 cryptographic algorithm (e.g., certification of a public key based on 286 a certain elliptic curve) are represented as an attribute, to be 287 reflected as the AlgorithmIdentifier of the SubjectPublicKeyInfo, 288 with a type indicating the algorithm and the values indicating the 289 particular parameters specific to the algorithm. Requests for 290 descriptive information from the client are made by an attribute, to 291 be represented as Attributes of the CSR, with a type indicating the 292 [RFC2985] extensionRequest and the values indicating the particular 293 attributes desired to be included in the resulting certificate's 294 extensions. 296 The sequence is Distinguished Encoding Rules (DER) encoded [X.690] 297 and then base64 encoded (Section 4 of [RFC4648]). The resulting text 298 forms the application/csrattr body, without headers. 300 For example, if a CA requests a client to submit a certification 301 request containing the challengePassword (indicating that linking of 302 identity and POP information is requested; see Section 3.5), an 303 extensionRequest with the Media Access Control (MAC) address 304 ([RFC2307]) of the client, and to use the secp384r1 elliptic curve 305 and to sign with the SHA384 hash function. Then, it takes the 306 following: 308 OID: challengePassword (1.2.840.113549.1.9.7) 310 Attribute: type = extensionRequest (1.2.840.113549.1.9.14) 311 value = macAddress (1.3.6.1.1.1.1.22) 313 Attribute: type = id-ecPublicKey (1.2.840.10045.2.1) 314 value = secp384r1 (1.3.132.0.34) 316 OID: ecdsaWithSHA384 (1.2.840.10045.4.3.3) 318 and encodes them into an ASN.1 SEQUENCE to produce: 320 30 41 06 09 2a 86 48 86 f7 0d 01 09 07 30 12 06 07 2a 86 48 ce 3d 321 02 01 31 07 06 05 2b 81 04 00 22 30 16 06 09 2a 86 48 86 f7 0d 01 322 09 0e 31 09 06 07 2b 06 01 01 01 01 16 06 08 2a 86 48 ce 3d 04 03 323 03 325 and then base64 encodes the resulting ASN.1 SEQUENCE to produce: 327 MEEGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMBYGCSqGSIb3DQEJDjEJ 328 BgcrBgEBAQEWBggqhkjOPQQDAw== 330 5. Clarification of error messages for certificate enrollment 331 operations 333 [errata5108] clarifies what format the error messages are to be in. 334 Previously a client might be confused into believing that an error 335 returned with type text/plain was not intended to be an error. 337 5.1. Updating section 4.2.3: Simple Enroll and Re-enroll Response 339 Replace: 341 If the content-type is not set, the response data MUST be a 342 plaintext human-readable error message containing explanatory 343 information describing why the request was rejected (for 344 example, indicating that CSR attributes are incomplete). 346 with: 348 If the content-type is not set, the response data MUST be a 349 plaintext human-readable error message containing explanatory 350 information describing why the request was rejected (for 351 example, indicating that CSR attributes are incomplete). 352 Servers MAY use the "text/plain" content-type [RFC2046] 353 for human-readable errors. 355 5.2. Updating section 4.4.2: Server-Side Key Generation Response 357 Replace: 359 If the content-type is not set, the response data MUST be a 360 plaintext human-readable error message. 362 with: 364 If the content-type is not set, the response data MUST be a 365 plaintext human-readable error message. 366 Servers MAY use the "text/plain" content-type [RFC2046] 367 for human-readable errors. 369 6. Privacy Considerations 371 This document does not disclose any additional identities to either 372 active or passive observer would see with [RFC7030]. 374 7. Security Considerations 376 This document clarifies an existing security mechanism. It does not 377 create any new protocol mechanism. 379 All security considerations from [RFC7030] also apply for the 380 clarifications described in this document. 382 8. IANA Considerations 384 The ASN.1 module in Appendix A of this document makes use of object 385 identifiers (OIDs). This document requests that IANA register an OID 386 in the SMI Security for PKIX Arc in the Module identifiers subarc 387 (1.3.6.1.5.5.7.0) for the ASN.1 module. The OID for the Asymmetric 388 Decryption Key Identifier (1.2.840.113549.1.9.16.2.54) was previously 389 defined in [RFC7030]. 391 IANA is requested to update the "Reference" column for the Asymmetric 392 Decryption Key Identifier attribute to also include a reference to 393 this document. 395 9. Acknowledgements 397 This work was supported by Huawei Technologies. 399 The ASN.1 Module was assembled by Russ Housley and formatted by Sean 400 Turner. Russ Housley provided editorial review. 402 10. References 404 10.1. Normative References 406 [errata4384] 407 "EST errata 4384: ASN.1 encoding error", n.d., 408 . 410 [errata5107] 411 "EST errata 5107: use Content-Transfer-Encoding", n.d., 412 . 414 [errata5108] 415 "EST errata 5108: use of Content-Type for error message", 416 n.d., . 418 [errata5904] 419 "EST errata 5904: use Content-Transfer-Encoding", n.d., 420 . 422 [IEC62351] 423 International Electrotechnical Commission, "Power systems 424 management and associated information exchange - Data and 425 communications security - Part 9: Cyber security key 426 management for power system equipment", ISO/ 427 IEC 62351-9:2017, 2017. 429 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 430 Extensions (MIME) Part One: Format of Internet Message 431 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 432 . 434 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 435 Requirement Levels", BCP 14, RFC 2119, 436 DOI 10.17487/RFC2119, March 1997, 437 . 439 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 440 Request Syntax Specification Version 1.7", RFC 2986, 441 DOI 10.17487/RFC2986, November 2000, 442 . 444 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 445 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 446 . 448 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 449 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 450 . 452 [RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS 453 (CMC): Transport Protocols", RFC 5273, 454 DOI 10.17487/RFC5273, June 2008, 455 . 457 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 458 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 459 DOI 10.17487/RFC5912, June 2010, 460 . 462 [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules 463 for the Cryptographic Message Syntax (CMS) and the Public 464 Key Infrastructure Using X.509 (PKIX)", RFC 6268, 465 DOI 10.17487/RFC6268, July 2011, 466 . 468 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 469 "Enrollment over Secure Transport", RFC 7030, 470 DOI 10.17487/RFC7030, October 2013, 471 . 473 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 474 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 475 May 2017, . 477 [X.680] ITU-T, "Information technology - Abstract Syntax Notation 478 One.", ISO/IEC 8824-1:2002, 2002. 480 [X.681] ITU-T, "Information technology - Abstract Syntax Notation 481 One: Information Object Specification.", ISO/ 482 IEC 8824-2:2002, 2002. 484 [X.682] ITU-T, "Information technology - Abstract Syntax Notation 485 One: Constraint Specification.", ISO/IEC 8824-2:2002, 486 2002. 488 [X.683] ITU-T, "Information technology - Abstract Syntax Notation 489 One: Parameterization of ASN.1 Specifications.", ISO/ 490 IEC 8824-2:2002, 2002. 492 [X.690] ITU-T, "Information technology - ASN.1 encoding Rules: 493 Specification of Basic Encoding Rules (BER), Canonical 494 Encoding Rules (CER) and Distinguished Encoding Rules 495 (DER).", ISO/IEC 8825-1:2002, 2002. 497 10.2. Informative References 499 [I-D.ietf-anima-bootstrapping-keyinfra] 500 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 501 and K. Watsen, "Bootstrapping Remote Secure Key 502 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 503 keyinfra-43 (work in progress), August 2020. 505 [RFC2307] Howard, L., "An Approach for Using LDAP as a Network 506 Information Service", RFC 2307, DOI 10.17487/RFC2307, 507 March 1998, . 509 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 510 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 511 Transfer Protocol -- HTTP/1.1", RFC 2616, 512 DOI 10.17487/RFC2616, June 1999, 513 . 515 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 516 Classes and Attribute Types Version 2.0", RFC 2985, 517 DOI 10.17487/RFC2985, November 2000, 518 . 520 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 521 Protocol (HTTP/1.1): Message Syntax and Routing", 522 RFC 7230, DOI 10.17487/RFC7230, June 2014, 523 . 525 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 526 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 527 DOI 10.17487/RFC7231, June 2014, 528 . 530 Appendix A. ASN.1 Module 532 This annex provides the normative ASN.1 definitions for the 533 structures described in this specification using ASN.1 as defined in 534 [X.680], [X.681], [X.682] and [X.683]. 536 The ASN.1 modules makes imports from the ASN.1 modules in [RFC5912] 537 and [RFC6268]. 539 There is no ASN.1 Module in RFC 7030. This module has been created 540 by combining the lines that are contained in the document body. 542 PKIXEST-2019 543 { iso(1) identified-organization(3) dod(6) 544 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 545 id-mod-est-2019(TBD) } 547 DEFINITIONS IMPLICIT TAGS ::= 548 BEGIN 550 -- EXPORTS ALL -- 552 IMPORTS 554 Attribute 555 FROM CryptographicMessageSyntax-2010 -- [RFC6268] 556 { iso(1) member-body(2) us(840) rsadsi(113549) 557 pkcs(1) pkcs-9(9) smime(16) modules(0) 558 id-mod-cms-2009(58) } 560 ATTRIBUTE 561 FROM PKIX-CommonTypes-2009 -- [RFC5912] 562 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 563 mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } ; 565 -- CSR Attributes 567 CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID 569 AttrOrOID ::= CHOICE { 570 oid OBJECT IDENTIFIER, 571 attribute Attribute {{AttrSet}} } 573 AttrSet ATTRIBUTE ::= { ... } 575 -- Asymmetric Decrypt Key Identifier Attribute 577 aa-asymmDecryptKeyID ATTRIBUTE ::= 578 { TYPE AsymmetricDecryptKeyIdentifier 579 IDENTIFIED BY id-aa-asymmDecryptKeyID } 581 id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= { iso(1) member-body(2) 582 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 54 } 584 AsymmetricDecryptKeyIdentifier ::= OCTET STRING 586 END 588 Authors' Addresses 590 Michael Richardson 591 Sandelman Software Works 593 Email: mcr+ietf@sandelman.ca 595 Thomas Werner 596 Siemens 598 Email: thomas-werner@siemens.com 600 Wei Pan 601 Huawei Technologies 603 Email: william.panwei@huawei.com