idnits 2.17.1 draft-ietf-lamps-rfc7030est-clarify-06.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 (June 14, 2020) is 1405 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: 'RFC5272' is mentioned on line 170, but not defined == Missing Reference: 'RFC5273' is mentioned on line 191, but not defined == Missing Reference: 'RFC2046' is mentioned on line 367, but not defined == Missing Reference: 'RFC5912' is mentioned on line 556, but not defined == Unused Reference: 'RFC8179' is defined on line 467, but no explicit reference was found in the text -- 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 5212 ** Downref: Normative reference to an Informational RFC: RFC 6268 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-41 -- 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 (~~), 7 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: December 16, 2020 W. Pan 7 Huawei Technologies 8 June 14, 2020 10 Clarification of Enrollment over Secure Transport (EST): transfer 11 encodings and ASN.1 12 draft-ietf-lamps-rfc7030est-clarify-06 14 Abstract 16 This document updates RFC7030: Enrollment over Secure Transport (EST) 17 to resolve some errata that was reported, and which has 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 was presented. 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 December 16, 2020. 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 [RFC2616] and [RFC7230]. 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 explicitely with [errata5107] and [errata5904] in 118 Section 3. [errata5108] is dealt with in section Section 5. 120 [errata4384] is closed by correcting the ASN.1 Module in Section 4. 122 2. Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in 127 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 3. Changes to EST endpoint processing 132 The [RFC7030] sections 4.1.3 (CA Certificates Response, /cacerts), 133 4.3.1/4.3.2 (Full CMC, /fullcmc), 4.4.2 (Server-Side Key Generation, 134 /serverkeygen), and 4.5.2 (CSR Attributes, /csrattrs) specify the use 135 of base64 encoding with a Content-Transfer-Encoding for requests and 136 response. 138 This document updates [RFC7030] to require the POST request and 139 payload response of all endpoints use Base64 encoding as specified in 140 Section 4 of [RFC4648]. In both cases, the Distinguished Encoding 141 Rules (DER) [X.690] are used to produce the input for the Base64 142 encoding routine. This format is to be used regardless of any 143 Content-Transfer-Encoding header, and any value in such a header MUST 144 be ignored. 146 3.1. Whitespace processing 148 Note that "base64" as used in the HTTP [RFC2616] does not permit 149 CRLF, while the "base64" used in MIME [RFC2045] does. This 150 specification clarifies that despite [RFC2616], that white space 151 including CR, LF, spaces (ASCII 32) and, tabs (ASCII 9) SHOULD be 152 tolerated by receivers. Senders are not required to insert any kind 153 of white space. 155 3.2. Changes sections 4 of RFC7030 157 3.2.1. Section 4.1.3 159 Replace: 161 A successful response MUST be a certs-only CMC Simple PKI Response, 162 as defined in [RFC5272], containing the certificates described in the 163 following paragraph. The HTTP content-type of 164 "application/pkcs7-mime" is used. The Simple PKI Response is sent 165 with a Content-Transfer-Encoding of "base64" [RFC2045]. 167 with: 169 A successful response MUST be a certs-only CMC Simple PKI Response, 170 as defined in [RFC5272], containing the certificates described in the 171 following paragraph. The HTTP content-type of 172 "application/pkcs7-mime" is used. The CMC Simple PKI Response is 173 encoded in base64 [RFC4648]. 175 3.2.2. Section 4.3.1 177 Replace: 179 If the HTTP POST to /fullcmc is not a valid Full PKI Request, the 180 server MUST reject the message. The HTTP content-type used is 181 "application/pkcs7-mime" with an smime-type parameter "CMC-request", 182 as specified in [RFC5273]. The body of the message is the binary 183 value of the encoding of the PKI Request with a 184 Content-Transfer-Encoding of "base64" [RFC2045]. 186 with: 188 If the HTTP POST to /fullcmc is not a valid Full PKI Request, the 189 server MUST reject the message. The HTTP content-type used is 190 "application/pkcs7-mime" with an smime-type parameter "CMC-request", 191 as specified in [RFC5273]. The body of the message is encoded 192 in base64 [RFC4648]. 194 3.2.3. Section 4.3.2 196 Replace: 198 The body of the message is the binary value of the encoding of the 199 PKI Response with a Content-Transfer-Encoding of "base64" [RFC2045]. 201 with: 203 The body of the message is the base64 [RFC4648] encoding of the 204 PKI Response. 206 3.2.4. Section 4.4.2 208 Replace: 210 An "application/pkcs8" 211 part consists of the base64-encoded DER-encoded [X.690] 212 PrivateKeyInfo with a Content-Transfer-Encoding of "base64" 213 [RFC4648]. 215 with: 217 An "application/pkcs8" part consists of the base64-encoded 218 DER-encoded [X.690] PrivateKeyInfo. 220 Replace: 222 In all three additional encryption cases, the EnvelopedData is 223 returned in the response as an "application/pkcs7-mime" part with an 224 smime-type parameter of "server-generated-key" and a Content- 225 Transfer-Encoding of "base64". 227 with: 229 In all three additional encryption cases, the EnvelopedData is 230 returned in the response as an "application/pkcs7-mime" part 231 with an smime-type parameter of "server-generated-key". It is 232 base64 encoded [RFC4648]. 234 3.2.5. Section 4.5.2 236 This section is updated in its entirety in Section 4. 238 4. Clarification of ASN.1 for Certificate Attribute set. 240 Section 4.5.2 of [RFC7030] is to be replaced with the following text: 242 4.5.2 CSR Attributes Response 244 If locally configured policy for an authenticated EST client 245 indicates a CSR Attributes Response is to be provided, the server 246 response MUST include an HTTP 200 response code. An HTTP response 247 code of 204 or 404 indicates that a CSR Attributes Response is not 248 available. Regardless of the response code, the EST server and CA 249 MAY reject any subsequent enrollment requests for any reason, e.g., 250 incomplete CSR attributes in the request. 252 Responses to attribute request messages MUST be encoded as the 253 content-type of "application/csrattrs", and are to be "base64" 254 [RFC2045] encoded. The syntax for application/csrattrs body is as 255 follows: 257 CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID 259 AttrOrOID ::= CHOICE { 260 oid OBJECT IDENTIFIER, 261 attribute Attribute {{AttrSet}} } 263 AttrSet ATTRIBUTE ::= { ... } 265 An EST server includes zero or more OIDs or attributes [RFC2986] that 266 it requests the client to use in the certification request. The 267 client MUST ignore any OID or attribute it does not recognize. When 268 the server encodes CSR Attributes as an empty SEQUENCE, it means that 269 the server has no specific additional information it desires in a 270 client certification request (this is functionally equivalent to an 271 HTTP response code of 204 or 404). 273 If the CA requires a particular cryptographic algorithm or use of a 274 particular signature scheme (e.g., certification of a public key 275 based on a certain elliptic curve, or signing using a certain hash 276 algorithm) it MUST provide that information in the CSR Attribute 277 Response. If an EST server requires the linking of identity and POP 278 information (see Section 3.5), it MUST include the challengePassword 279 OID in the CSR Attributes Response. 281 The structure of the CSR Attributes Response SHOULD, to the greatest 282 extent possible, reflect the structure of the CSR it is requesting. 283 Requests to use a particular signature scheme (e.g. using a 284 particular hash function) are represented as an OID to be reflected 285 in the SignatureAlgorithm of the CSR. Requests to use a particular 286 cryptographic algorithm (e.g., certification of a public key based on 287 a certain elliptic curve) are represented as an attribute, to be 288 reflected as the AlgorithmIdentifier of the SubjectPublicKeyInfo, 289 with a type indicating the algorithm and the values indicating the 290 particular parameters specific to the algorithm. Requests for 291 descriptive information from the client are made by an attribute, to 292 be represented as Attributes of the CSR, with a type indicating the 293 [RFC2985] extensionRequest and the values indicating the particular 294 attributes desired to be included in the resulting certificate's 295 extensions. 297 The sequence is Distinguished Encoding Rules (DER) encoded [X.690] 298 and then base64 encoded (Section 4 of [RFC4648]). The resulting text 299 forms the application/csrattr body, without headers. 301 For example, if a CA requests a client to submit a certification 302 request containing the challengePassword (indicating that linking of 303 identity and POP information is requested; see Section 3.5), an 304 extensionRequest with the Media Access Control (MAC) address 305 ([RFC2307]) of the client, and to use the secp384r1 elliptic curve 306 and to sign with the SHA384 hash function. Then, it takes the 307 following: 309 OID: challengePassword (1.2.840.113549.1.9.7) 311 Attribute: type = extensionRequest (1.2.840.113549.1.9.14) 312 value = macAddress (1.3.6.1.1.1.1.22) 314 Attribute: type = id-ecPublicKey (1.2.840.10045.2.1) 315 value = secp384r1 (1.3.132.0.34) 317 OID: ecdsaWithSHA384 (1.2.840.10045.4.3.3) 319 and encodes them into an ASN.1 SEQUENCE to produce: 321 30 41 06 09 2a 86 48 86 f7 0d 01 09 07 30 12 06 07 2a 86 48 ce 3d 322 02 01 31 07 06 05 2b 81 04 00 22 30 16 06 09 2a 86 48 86 f7 0d 01 323 09 0e 31 09 06 07 2b 06 01 01 01 01 16 06 08 2a 86 48 ce 3d 04 03 324 03 326 and then base64 encodes the resulting ASN.1 SEQUENCE to produce: 328 MEEGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMBYGCSqGSIb3DQEJDjEJ 329 BgcrBgEBAQEWBggqhkjOPQQDAw== 331 5. Clarification of error messages for certificate enrollment 332 operations 334 [errata5108] clarifies what format the error messages are to be in. 335 Previously a client might be confused into believing that an error 336 returned with type text/plain was not intended to be an error. 338 5.1. Updating section 4.2.3: Simple Enroll and Re-enroll Response 340 Replace: 342 If the content-type is not set, the response data MUST be a 343 plaintext human-readable error message containing explanatory 344 information describing why the request was rejected (for 345 example, indicating that CSR attributes are incomplete). 347 with: 349 If the content-type is not set, the response data MUST be a 350 plaintext human-readable error message containing explanatory 351 information describing why the request was rejected (for 352 example, indicating that CSR attributes are incomplete). 353 Servers MAY use the "text/plain" content-type [RFC2046] 354 for human-readable errors. 356 5.2. Updating section 4.4.2: Server-Side Key Generation Response 358 Replace: 360 If the content-type is not set, the response data MUST be a 361 plaintext human-readable error message. 363 with: 365 If the content-type is not set, the response data must be a 366 plaintext human-readable error message. 367 Servers MAY use the "text/plain" content-type [RFC2046] 368 for human-readable errors. 370 6. Privacy Considerations 372 This document does not disclose any additional identifies to either 373 active or passive observer would see with [RFC7030]. 375 7. Security Considerations 377 This document clarifies an existing security mechanism. It does not 378 create any new protocol mechanism. 380 8. IANA Considerations 382 The ASN.1 module in Appendix A of this document makes use of object 383 identifiers (OIDs). This document requests that IANA register an OID 384 in the SMI Security for PKIX Arc in the Module identifiers subarc 385 (1.3.6.1.5.5.7.0) for the ASN.1 module. The OID for the Asymmetric 386 Decryption Key Identifier (1.2.840.113549.1.9.16.2.54) was previously 387 defined in [RFC7030]. 389 IANA is requested to update the "Reference" column for the Asymmetric 390 Decryption Key Identifier attribute to also include a reference to 391 this document. 393 9. Acknowledgements 395 This work was supported by Huawei Technologies. 397 The ASN.1 Module was assembled by Russ Housley and formatted by Sean 398 Turner. Russ Housley provided editorial review. 400 10. References 402 10.1. Normative References 404 [errata4384] 405 "EST errata 4384: ASN.1 encoding error", n.d., 406 . 408 [errata5107] 409 "EST errata 5107: use Content-Transfer-Encoding", n.d., 410 . 412 [errata5108] 413 "EST errata 5108: use of Content-Type for error message", 414 n.d., . 416 [errata5904] 417 "EST errata 5904: use Content-Transfer-Encoding", n.d., 418 . 420 [IEC62351] 421 International Electrotechnical Commission, "Power systems 422 management and associated information exchange - Data and 423 communications security - Part 9: Cyber security key 424 management for power system equipment", ISO/ 425 IEC 62351-9:2017, 2017. 427 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 428 Extensions (MIME) Part One: Format of Internet Message 429 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 430 . 432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 433 Requirement Levels", BCP 14, RFC 2119, 434 DOI 10.17487/RFC2119, March 1997, 435 . 437 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 438 Request Syntax Specification Version 1.7", RFC 2986, 439 DOI 10.17487/RFC2986, November 2000, 440 . 442 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 443 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 444 . 446 [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, 447 M., and D. Brungard, "Requirements for GMPLS-Based Multi- 448 Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, 449 DOI 10.17487/RFC5212, July 2008, 450 . 452 [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules 453 for the Cryptographic Message Syntax (CMS) and the Public 454 Key Infrastructure Using X.509 (PKIX)", RFC 6268, 455 DOI 10.17487/RFC6268, July 2011, 456 . 458 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 459 "Enrollment over Secure Transport", RFC 7030, 460 DOI 10.17487/RFC7030, October 2013, 461 . 463 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 464 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 465 May 2017, . 467 [RFC8179] Bradner, S. and J. Contreras, "Intellectual Property 468 Rights in IETF Technology", BCP 79, RFC 8179, 469 DOI 10.17487/RFC8179, May 2017, 470 . 472 [X.680] ITU-T, "Information technology - Abstract Syntax Notation 473 One.", ISO/IEC 8824-1:2002, 2002. 475 [X.681] ITU-T, "Information technology - Abstract Syntax Notation 476 One: Information Object Specification.", ISO/ 477 IEC 8824-2:2002, 2002. 479 [X.682] ITU-T, "Information technology - Abstract Syntax Notation 480 One: Constraint Specification.", ISO/IEC 8824-2:2002, 481 2002. 483 [X.683] ITU-T, "Information technology - Abstract Syntax Notation 484 One: Parameterization of ASN.1 Specifications.", ISO/ 485 IEC 8824-2:2002, 2002. 487 [X.690] ITU-T, "Information technology - ASN.1 encoding Rules: 488 Specification of Basic Encoding Rules (BER), Canonical 489 Encoding Rules (CER) and Distinguished Encoding Rules 490 (DER).", ISO/IEC 8825-1:2002, 2002. 492 10.2. Informative References 494 [I-D.ietf-anima-bootstrapping-keyinfra] 495 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 496 and K. Watsen, "Bootstrapping Remote Secure Key 497 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 498 keyinfra-41 (work in progress), April 2020. 500 [RFC2307] Howard, L., "An Approach for Using LDAP as a Network 501 Information Service", RFC 2307, DOI 10.17487/RFC2307, 502 March 1998, . 504 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 505 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 506 Transfer Protocol -- HTTP/1.1", RFC 2616, 507 DOI 10.17487/RFC2616, June 1999, 508 . 510 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 511 Classes and Attribute Types Version 2.0", RFC 2985, 512 DOI 10.17487/RFC2985, November 2000, 513 . 515 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 516 Protocol (HTTP/1.1): Message Syntax and Routing", 517 RFC 7230, DOI 10.17487/RFC7230, June 2014, 518 . 520 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 521 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 522 DOI 10.17487/RFC7231, June 2014, 523 . 525 Appendix A. ASN.1 Module 527 This annex provides the normative ASN.1 definitions for the 528 structures described in this specification using ASN.1 as defined in 529 [X.680], [X.681], [X.682] and [X.683]. 531 The ASN.1 modules makes imports from the ASN.1 modules in [RFC5212] 532 and [RFC6268]. 534 There is no ASN.1 Module in RFC 7030. This module has been created 535 by combining the lines that are contained in the document body. 537 PKIXEST-2019 538 { iso(1) identified-organization(3) dod(6) 539 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 540 id-mod-est-2019(TBD) } 542 DEFINITIONS IMPLICIT TAGS ::= 543 BEGIN 545 -- EXPORTS ALL -- 547 IMPORTS 549 Attribute 550 FROM CryptographicMessageSyntax-2010 -- [RFC6268] 551 { iso(1) member-body(2) us(840) rsadsi(113549) 552 pkcs(1) pkcs-9(9) smime(16) modules(0) 553 id-mod-cms-2009(58) } 555 ATTRIBUTE 556 FROM PKIX-CommonTypes-2009 -- [RFC5912] 557 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 558 mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } ; 560 -- CSR Attributes 562 CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID 564 AttrOrOID ::= CHOICE { 565 oid OBJECT IDENTIFIER, 566 attribute Attribute {{AttrSet}} } 568 AttrSet ATTRIBUTE ::= { ... } 570 -- Asymmetric Decrypt Key Identifier Attribute 572 aa-asymmDecryptKeyID ATTRIBUTE ::= 573 { TYPE AsymmetricDecryptKeyIdentifier 574 IDENTIFIED BY id-aa-asymmDecryptKeyID } 576 id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= { iso(1) member-body(2) 577 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2) 54 } 579 AsymmetricDecryptKeyIdentifier ::= OCTET STRING 581 END 583 Authors' Addresses 585 Michael Richardson 586 Sandelman Software Works 588 Email: mcr+ietf@sandelman.ca 590 Thomas Werner 591 Siemens 593 Email: thomas-werner@siemens.com 595 Wei Pan 596 Huawei Technologies 598 Email: william.panwei@huawei.com