idnits 2.17.00 (12 Aug 2021) /tmp/idnits15650/draft-ietf-curdle-cms-ecdh-new-curves-00.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 "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document date (5 May 2016) is 2207 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: 'CURVE' is mentioned on line 102, but not defined -- Looks like a reference, but probably isn't: '0' on line 113 -- Looks like a reference, but probably isn't: '2' on line 114 == Missing Reference: 'HMAC' is mentioned on line 161, but not defined == Unused Reference: 'HKDF' is defined on line 496, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 7748 (ref. 'CURVES') ** Downref: Normative reference to an Informational RFC: RFC 5869 (ref. 'HKDF') -- Possible downref: Non-RFC (?) normative reference: ref. 'ID.josefsson-pkix-newcurves' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' ** Obsolete normative reference: RFC 5751 (ref. 'SMIME') (Obsoleted by RFC 8551) -- Possible downref: Non-RFC (?) normative reference: ref. 'X680' -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft R. Housley 3 Intended status: Standards Track Vigil Security 4 Expires: 5 November 2016 5 May 2016 6 Use of the Elliptic Curve Diffie-Hellamn Key Agreement Algorithm with 7 curve25519 and curve448 in the Cryptographic Message Syntax (CMS) 9 11 Abstract 13 This document describes the conventions for using Elliptic Curve 14 Diffie-Hellamn (ECDH) key agreement algorithm using curve25519 and 15 curve448 in the Cryptographic Message Syntax (CMS). 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 5 November 2016. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Introduction 51 This document describes the conventions for using Elliptic Curve 52 Diffie-Hellamn (ECDH) key agreement using curve25519 and curve448 53 [CURVE] in the Cryptographic Message Syntax (CMS) [CMS]. Key 54 agreement is supported in three CMS content types: the enveloped-data 55 content type [CMS], authenticated-data content type [CMS], and the 56 authenticated-enveloped-data content type [AUTHENV]. 58 The conventions for using some Elliptic Curve Cryptography (ECC) 59 algorithms in CMS are described in [CMSECC]. These conventions cover 60 the use of ECDH with some curves other than curve25519 and curve448 61 [CURVE]. Those other curves are not deprecated, but support for 62 curve25519 and curve448 is encouraged. 64 1.1. Terminology 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in RFC 2119 [STDWORDS]. 70 1.2. ASN.1 72 CMS values are generated using ASN.1 [X680], which uses the Basic 73 Encoding Rules (BER) and the Distinguished Encoding Rules (DER) 74 [X690]. 76 2. Key Agreement 78 In 1976, Diffie and Hellman describe a means for two parties to agree 79 upon a shared secret value in manner that prevents eavesdroppers from 80 learning the shared secret value [DH1976]. This secret may then be 81 converted into pairwise symmetric keying material for use with other 82 cryptographic algorithms. Over the years, many variants of this 83 fundamental technique have been developed. This document describes 84 the conventions for using Ephemeral-Static Elliptic Curve Diffie- 85 Hellamn (ECDH) key agreement using curve25519 and curve448. 87 The originator uses an ephemeral public/private key pair that is 88 generated on the same elliptic curve as the public key of the 89 recipient. The ephemeral key pair is used for a single CMS protected 90 content type, and then it is discarded. The originator obtains the 91 recipient's static public key from the recipient's certificate 92 [PROFILE]. 94 ECDH with curve25519 is described in Section 6.1 of [CURVE], and ECDH 95 with curve448 is described in Section 6.2 of [CURVE]. Since 96 curve25519 and curve448 have cofactors of 8 and 4, respectively, an 97 input point of small order will eliminate any contribution from the 98 other party's private key. As described in Section 7 of [CURVE], 99 implementations MAY detect this situation by checking for the all- 100 zero output. 102 In [CURVE], the shared secret value that is produced by ECDH is 103 called K. (In some other specifications, the shared secret value is 104 called Z.) A key derivation function (KDF) is used to produce a 105 pairwise key-encryption key from K, the length of the key-encryption 106 key, and the DER-encoded ECC-CMS-SharedInfo structure [CMSECC]. 108 The ECC-CMS-SharedInfo definition from [CMSECC] is repeated here for 109 convenience. 111 ECC-CMS-SharedInfo ::= SEQUENCE { 112 keyInfo AlgorithmIdentifier, 113 entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL, 114 suppPubInfo [2] EXPLICIT OCTET STRING } 116 The ECC-CMS-SharedInfo keyInfo field contains the object identifier 117 of the key-encryption algorithm and associated parameters. This 118 algorithm will be used to wrap the content-encryption key. In this 119 specification, the AES Key Wrap algorithm identifier has absent 120 parameters. 122 The ECC-CMS-SharedInfo entityUInfo field optionally contains 123 additional keying material supplied by the sending agent. Note that 124 [CMS] requires implementations to accept a KeyAgreeRecipientInfo 125 SEQUENCE that includes the ukm field. If the ukm field is present, 126 the ukm is placed in the entityUInfo field. The ukm value need not 127 be longer than the key-encryption key that will be produced by the 128 KDF. When present, the ukm ensures that a different key-encryption 129 key is generated, even when the originator ephemeral private key is 130 improperly used more than once. 132 The ECC-CMS-SharedInfo suppPubInfo field contains the length of the 133 generated key-encryption key, in bits, represented as a 32-bit 134 number. For example, the key length for AES-256 would be 0x00000100. 136 2.1. ANSI-X9.63-KDF 138 The ANSI-X9.63-KDF key derivation function is a simple construct 139 based on a one-way hash function described in ANS X9.63 [X963]. This 140 KDF is also described in Section 3.6.1 of [SEC1]. 142 Three values are concatenated to produce the input string to the KDF: 143 1. The shared secret value generated by ECDH, K. 144 2. The iteration counter, starting with one, as described below. 145 3. The DER-encoded ECC-CMS-SharedInfo structure. 147 To generate a key-encryption key, generates one or more KM blocks, 148 with the counter starting at 0x00000001, and incrementing the counter 149 for each subsequent KM block until enough material has been 150 generated. The KM blocks are concatenated left to right: 152 KM(i) = Hash(K || INT32(counter=i) || DER(ECC-CMS-SharedInfo)) 154 KEK = KM(counter=1) || KM(counter=2) ... 156 KEK is the pairwise key-encryption key. 158 2.2. HKDF 160 The HKDF key derivation function is a robust construct based on a 161 one-way hash function described in RFC 5869 [HMAC]. HKDF is 162 comprised of two steps: HKDF-Extract followed by HKDF-Expand. 164 Three values are used as inputs to the HKDF: 165 1. The shared secret value generated by ECDH, K. 166 2. The length in octets of the keying data to be generated. 167 3. The DER-encoded ECC-CMS-SharedInfo structure. 169 The ECC-CMS-SharedInfo structure includes the ukm. This field is 170 optional, and if it is present, the ukm is also used as the HKDF 171 salt. 173 The length of the generated key-encryption key is used two places, 174 once in bits, and once in octets. The ECC-CMS-SharedInfo structure 175 includes the length of the generated key-encryption key in bits. The 176 HKDF-Expand function takes an argument for the length of the 177 generated key-encryption key in octets. 179 In summary: 181 if ukm is provided, then salt = ukm, else salt = zero 182 PRK = HKDF-Extract(salt, K) 184 KEK = HKDF-Expand(PRK, DER(ECC-CMS-SharedInfo), SizeInOctets(KEK)) 186 KEK is the pairwise key-encryption key. 188 3. Enveloped-data Conventions 190 The CMS enveloped-data content type [CMS] consists of an encrypted 191 content and wrapped content-encryption keys for one or more 192 recipients. The ECDH key agreement algorithm is used to generate a 193 pairwise key-encryption key between the originator and a particular 194 recipient. Then, the key-encryption key is used to wrap the content- 195 encryption key for that recipient. When there more than one 196 recipient, the same content-encryption key is wrapped for each of 197 them. 199 A compliant implementation MUST meet the requirements for 200 constructing an enveloped-data content type in Section 6 of [CMS]. 202 A content-encryption key MUST be randomly generated for each instance 203 of an enveloped-data content type. The content-encryption key is 204 used to encipher the content. 206 3.1. EnvelopedData Fields 208 The enveloped-data content type is ASN.1 encoded using the 209 EnvelopedData syntax. The fields of the EnvelopedData syntax MUST be 210 populated as described in [CMS]; for the recipients that use ECDH 211 with curve25519 or curve448 the RecipientInfo kari choice MUST be 212 used. 214 3.2. KeyAgreeRecipientInfo Fields 216 The fields of the KeyAgreeRecipientInfo syntax MUST be populated as 217 described in this section when ECDH with curve25519 or curve448 is 218 employed for one or more recipients. 220 The KeyAgreeRecipientInfo version MUST be 3. 222 The KeyAgreeRecipientInfo originator provides three alternatives for 223 identifying the originator's public key, and the originatorKey 224 alternative MUST be used. The originatorKey MUST contain an 225 ephemeral key for the originator. The originatorKey algorithm field 226 MUST contain the id-ecPublicKey object identifier along with 227 ECParameters as specified in [PKIXECC]. The originator's ephemeral 228 public key MUST be encoded using the type ECPoint as specified in 230 [CMSECC]. As a courtesy, the definitions are repeated here: 232 id-ecPublicKey OBJECT IDENTIFIER ::= { 233 iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 } 235 ECPoint ::= OCTET STRING 237 ECParameters ::= CHOICE { 238 namedCurve OBJECT IDENTIFIER 239 -- implicitCurve NULL 240 -- specifiedCurve SpecifiedECDomain -- } 242 The object identifiers for curve25519 and curve448 have been assigned 243 in [ID.josefsson-pkix-newcurves]. They are repeated below for 244 convenience. 246 When using curve25519, the ECPoint contains exactly 32 octets, and 247 the ECParameters namedCurve MUST contain the following object 248 identifier: 250 id-Curve25519 OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 11591 15 1 } 252 When using curve448, the ECPoint contains exactly 56 octets, and the 253 ECParameters namedCurve MUST contain the following object identifier: 255 id-Curve448 OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 11591 15 2 } 257 KeyAgreeRecipientInfo ukm is optional. Note that [CMS] requires 258 implementations to accept a KeyAgreeRecipientInfo SEQUENCE that 259 includes the ukm field. If present, the ukm is placed in the 260 entityUInfo field of the ECC-CMS-SharedInfo as input to the KDF. The 261 ukm value need not be longer than the key-encryption key produced by 262 the KDF. 264 KeyAgreeRecipientInfo keyEncryptionAlgorithm MUST contain the object 265 identifier of the key-encryption algorithm that will be used to wrap 266 the content-encryption key. The conventions for using AES-128, 267 AES-192, and AES-256 in the key wrap mode are specified in [CMSAES]. 269 KeyAgreeRecipientInfo recipientEncryptedKeys includes a recipient 270 identifier and encrypted key for one or more recipients. The 271 RecipientEncryptedKey KeyAgreeRecipientIdentifier MUST contain either 272 the issuerAndSerialNumber identifying the recipient's certificate or 273 the RecipientKeyIdentifier containing the subject key identifier from 274 the recipient's certificate. In both cases, the recipient's 275 certificate contains the recipient's static ECDH public key with 276 curve25519 or curve448 public key. RecipientEncryptedKey 277 EncryptedKey MUST contain the content-encryption key encrypted with 278 the pairwise key-encryption key using the algorithm specified by the 279 KeyWrapAlgorithm. 281 4. Authenticated-data Conventions 283 The CMS authenticated-data content type [CMS] consists an 284 authenticated content, a message authentication code (MAC), and 285 encrypted authentication keys for one or more recipients. The ECDH 286 key agreement algorithm is used to generate a pairwise key-encryption 287 key between the originator and a particular recipient. Then, the 288 key-encryption key is used to wrap the authentication key for that 289 recipient. When there more than one recipient, the same 290 authentication key is wrapped for each of them. 292 A compliant implementation MUST meet the requirements for 293 constructing an authenticated-data content type in Section 9 of 294 [CMS]. 296 A authentication key MUST be randomly generated for each instance of 297 an authenticated-data content type. The authentication key is used 298 to compute the MAC over the content. 300 4.1. AuthenticatedData Fields 302 The authenticated-data content type is ASN.1 encoded using the 303 AuthenticatedData syntax. The fields of the AuthenticatedData syntax 304 MUST be populated as described in [CMS]; for the recipients that use 305 ECDH with curve25519 or curve448 the RecipientInfo kari choice MUST 306 be used. 308 4.2. KeyAgreeRecipientInfo Fields 310 The fields of the KeyAgreeRecipientInfo syntax MUST be populated as 311 described in Section 3.2 of this document. 313 5. Authenticated-Enveloped-data Conventions 315 The CMS authenticated-enveloped-data content type content type 316 [AUTHENV] consists of an authenticated and encrypted content and 317 encrypted content-authenticated-encryption keys for one or more 318 recipients. The ECDH key agreement algorithm is used to generate a 319 pairwise key-encryption key between the originator and a particular 320 recipient. Then, the key-encryption key is used to wrap the content- 321 authenticated-encryption key for that recipient. When there more 322 than one recipient, the same content-authenticated-encryption key is 323 wrapped for each of them. 325 A compliant implementation MUST meet the requirements for 326 constructing an authenticated-data content type in Section 2 of 327 [AUTHENV]. 329 A content-authenticated-encryption key MUST be randomly generated for 330 each instance of an authenticated-enveloped-data content type. The 331 content-authenticated-encryption key key is used to authenticate and 332 encrypt the content. 334 5.1. AuthEnvelopedData Fields 336 The authenticated-enveloped-data content type is ASN.1 encoded using 337 the AuthEnvelopedData syntax. The fields of the AuthEnvelopedData 338 syntax MUST be populated as described in [AUTHENV]; for the 339 recipients that use ECDH with curve25519 or curve448 the 340 RecipientInfo kari choice MUST be used. 342 5.2. KeyAgreeRecipientInfo Fields 344 The fields of the KeyAgreeRecipientInfo syntax MUST be populated as 345 described in Section 3.2 of this document. 347 6. Certificate Conventions 349 RFC 5280 [PROFILE] specifies the profile for using X.509 Certificates 350 in Internet applications. A recipient static public key is needed 351 for ECDH with curve25519 or curve448, and the originator obtains that 352 public key from the recipient's certificate. The conventions in this 353 section augment RFC 5280. 355 The id-ecPublicKey object identifier continues to identify the static 356 ECDH public key for the recipient. The associated EcpkParameters 357 parameters structure is specified in [PKIXALG], and the namedCurve 358 alternative MUST be used. The object identifiers from Section 3.2 of 359 this document are used for curve25519 and curve448. The 360 EcpkParameters parameters structure is repeated here for convenience: 362 EcpkParameters ::= CHOICE { 363 ecParameters ECParameters, 364 namedCurve OBJECT IDENTIFIER, 365 implicitlyCA NULL } 367 The certificate issuer MAY use indicate the intended usage for the 368 certified public key by including the key usage certificate extension 369 as specified in Section 4.2.1.3 of [PROFILE]. If the keyUsage 370 extension is present in a certificate that conveys an ECDH static 371 public key, then the key usage extension MUST set the keyAgreement 372 bit. 374 7. Key Agreement Algorithm Identifiers 376 The following object identifiers are assigned to indicate ECDH with 377 HKDF using various one-way hash functions. These are expected to be 378 used as AlgorithmIdentifiers with a parameter that specifies the key- 379 encryption algorithm. 381 dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= { 382 TBD 0 } 384 dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= { 385 TBD 1 } 387 dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= { 388 TBD 2 } 390 8. SMIMECapabilities Attribute Conventions 392 A sending agent MAY announce to other agents that it supports ECDH 393 key agreement using the SMIMECapabilities signed attribute in a 394 signed message [SMIME] or a certificate [CERTCAP]. Following the 395 pattern established in [CMSECC], the SMIMECapabilities associated 396 with ECDH carries a DER-encoded object identifier that identifies 397 support for ECDH in conjunction with a particular KDF, and it 398 includes a parameter that names the key wrap algorithm. 400 The following SMIMECapabilities values (in hexidecimal) from [CMSECC] 401 might be of interest to implementations that support curve25519 and 402 curve448: 404 ECDH with ANSI-X9.63-KDF using SHA-256; uses AES-128 key wrap: 405 30 15 06 06 2B 81 04 01 0B 01 30 0B 06 09 60 86 48 01 65 03 04 406 01 05 408 ECDH with ANSI-X9.63-KDF using SHA-384; uses AES-128 key wrap: 409 30 15 06 06 2B 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04 410 01 05 412 ECDH with ANSI-X9.63-KDF using SHA-512; uses AES-128 key wrap: 413 30 15 06 06 2B 81 04 01 0B 03 30 0B 06 09 60 86 48 01 65 03 04 414 01 05 416 ECDH with ANSI-X9.63-KDF using SHA-256; uses AES-256 key wrap: 417 30 15 06 06 2B 81 04 01 0B 01 30 0B 06 09 60 86 48 01 65 03 04 418 01 2D 420 ECDH with ANSI-X9.63-KDF using SHA-384; uses AES-256 key wrap: 421 30 15 06 06 2B 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04 422 01 2D 424 ECDH with ANSI-X9.63-KDF using SHA-512; uses AES-256 key wrap: 425 30 15 06 06 2B 81 04 01 0B 03 30 0B 06 09 60 86 48 01 65 03 04 426 01 2D 428 The following SMIMECapabilities values (in hexidecimal) based on the 429 algorithm identifiers in Section 7 of this document might be of 430 interest to implementations that support curve25519 and curve448: 432 ECDH with HKDF using SHA-256; uses AES-128 key wrap: 433 TBD 435 ECDH with HKDF using SHA-384; uses AES-128 key wrap: 436 TBD 438 ECDH with HKDF using SHA-512; uses AES-128 key wrap: 439 TBD 441 ECDH with HKDF using SHA-256; uses AES-256 key wrap: 442 TBD 444 ECDH with HKDF using SHA-384; uses AES-256 key wrap: 445 TBD 447 ECDH with HKDF using SHA-512; uses AES-256 key wrap: 448 TBD 450 9. Security Considerations 452 Please consult the security considerations of [CMS] and [AUTHENV] for 453 security considerations related to the enveloped-data content type 454 and the authenticated-enveloped-data content type, respectively. 456 Please consult the security considerations of [CURVES] for security 457 considerations related to the use of ECDH with curve25519 and 458 curve448. 460 The originator uses an ephemeral public/private key pair that is 461 generated on the same elliptic curve as the public key of the 462 recipient. The ephemeral key pair is used for a single CMS protected 463 content type, and then it is discarded. If the originator wants to 464 be able to decrypt the content (for enveloped-data and authenticated- 465 enveloped-data) or check the authentication (for authenticated-data), 466 then the originator needs to treat themselves as a recipient. 468 As specified in [CMS], implementations MUST support processing of the 469 KeyAgreeRecipientInfo ukm field, so interoperability is not a concern 470 if the ukm is present or absent. The ukm is placed in the 471 entityUInfo field of the ECC-CMS-SharedInfo structure. When present, 472 the ukm ensures that a different key-encryption key is generated, 473 even when the originator ephemeral private key is improperly used 474 more than once. 476 10. IANA Considerations 478 No IANA registrations are requested in this document. 480 11. Normative References 482 [AUTHENV] Housley, R., "Cryptographic Message Syntax (CMS) 483 Authenticated-Enveloped-Data Content Type", RFC 5083, 484 November 2007. 486 [CERTCAP] Santesson, S., "X.509 Certificate Extension for 487 Secure/Multipurpose Internet Mail Extensions (S/MIME) 488 Capabilities", RFC 4262, December 2005. 490 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 491 5652, September 2009. 493 [CURVES] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 494 for Security", RFC 7748, January 2016. 496 [HKDF] Krawczyk, H., and P. Eronen, "HMAC-based Extract-and- 497 Expand Key Derivation Function (HKDF)", RFC 5869, May 498 2010. 500 [ID.josefsson-pkix-newcurves] 501 Josefsson, S., "Using Curve25519 and Curve448 in PKIX", 502 12 October 2015, Work-in-progress. 504 [PKIXALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and 505 Identifiers for the Internet X.509 Public Key 506 Infrastructure Certificate and Certificate Revocation List 507 (CRL) Profile", RFC 3279, April 2002. 509 [PKIXECC] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 510 "Elliptic Curve Cryptography Subject Public Key 511 Information", RFC 5480, March 2009. 513 [PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 514 Housley, R., and W. Polk, "Internet X.509 Public Key 515 Infrastructure Certificate and Certificate Revocation List 516 (CRL) Profile", RFC 5280, May 2008. 518 [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 519 Elliptic Curve Cryptography", version 2.0, May 2009, 520 . 522 [SMIME] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 523 Mail Extensions (S/MIME) Version 3.2 Message 524 Specification", RFC 5751, January 2010. 526 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 527 Requirement Levels", BCP 14, RFC 2119, March 1997. 529 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 530 One (ASN.1): Specification of basic notation", ITU-T 531 Recommendation X.680, 2002. 533 [X690] ITU-T, "Information technology -- ASN.1 encoding rules: 534 Specification of Basic Encoding Rules (BER), Canonical 535 Encoding Rules (CER) and Distinguished Encoding Rules 536 (DER)", ITU-T Recommendation X.690, 2002. 538 12. Informative References 540 [CMSECC] Turner, S., and D. Brown, "Use of Elliptic Curve 541 Cryptography (ECC) Algorithms in Cryptographic Message 542 Syntax (CMS)", RFC 5753, January 2010. 544 [CMSAES] Schaad, J., "Use of the Advanced Encryption Standard (AES) 545 Encryption Algorithm in Cryptographic Message Syntax 546 (CMS)", RFC 3565, July 2003. 548 [DH1976] Diffie, W., and M. E. Hellman, "New Directions in 549 Cryptography", IEEE Trans. on Info. Theory, Vol. IT-22, 550 Nov. 1976, pp. 644-654. 552 [X963] "Public-Key Cryptography for the Financial Services 553 Industry: Key Agreement and Key Transport Using Elliptic 554 Curve Cryptography", American National Standard 555 X9.63-2001, 2001. 557 13. Acknowledgements 559 Thanks to Jim Schaad, Stefan Santesson, Sean Turner for their review 560 and insightful suggestions. 562 Author Address 564 Russ Housley 565 918 Spring Knoll Drive 566 Herndon, VA 20170 567 USA 568 housley@vigilsec.com