idnits 2.17.1 draft-ietf-curdle-cms-ecdh-new-curves-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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (8 September 2016) is 2787 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 104, but not defined -- Looks like a reference, but probably isn't: '0' on line 115 -- Looks like a reference, but probably isn't: '2' on line 116 == Missing Reference: 'HMAC' is mentioned on line 163, 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.curdle-pkix' -- 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 (~~), 6 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: 8 March 2017 8 September 2016 6 Use of the Elliptic Curve Diffie-Hellamn Key Agreement Algorithm 7 with X25519 and X448 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 8 March 2017. 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 When these two curves are used with with Diffie-Hellman key 65 agreement, they are referred to as X25519 and X448. 67 1.1. Terminology 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in RFC 2119 [STDWORDS]. 73 1.2. ASN.1 75 CMS values are generated using ASN.1 [X680], which uses the Basic 76 Encoding Rules (BER) and the Distinguished Encoding Rules (DER) 77 [X690]. 79 2. Key Agreement 81 In 1976, Diffie and Hellman describe a means for two parties to agree 82 upon a shared secret value in manner that prevents eavesdroppers from 83 learning the shared secret value [DH1976]. This secret may then be 84 converted into pairwise symmetric keying material for use with other 85 cryptographic algorithms. Over the years, many variants of this 86 fundamental technique have been developed. This document describes 87 the conventions for using Ephemeral-Static Elliptic Curve Diffie- 88 Hellamn (ECDH) key agreement using X25519 and X448 [CURVE]. 90 The originator uses an ephemeral public/private key pair that is 91 generated on the same elliptic curve as the public key of the 92 recipient. The ephemeral key pair is used for a single CMS protected 93 content type, and then it is discarded. The originator obtains the 94 recipient's static public key from the recipient's certificate 95 [PROFILE]. 97 X25519 is described in Section 6.1 of [CURVE], and X448 is described 98 in Section 6.2 of [CURVE]. Since curve25519 and curve448 have 99 cofactors of 8 and 4, respectively, an input point of small order 100 will eliminate any contribution from the other party's private key. 101 As described in Section 7 of [CURVE], implementations MAY detect this 102 situation by checking for the all-zero output. 104 In [CURVE], the shared secret value that is produced by ECDH is 105 called K. (In some other specifications, the shared secret value is 106 called Z.) A key derivation function (KDF) is used to produce a 107 pairwise key-encryption key from K, the length of the key-encryption 108 key, and the DER-encoded ECC-CMS-SharedInfo structure [CMSECC]. 110 The ECC-CMS-SharedInfo definition from [CMSECC] is repeated here for 111 convenience. 113 ECC-CMS-SharedInfo ::= SEQUENCE { 114 keyInfo AlgorithmIdentifier, 115 entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL, 116 suppPubInfo [2] EXPLICIT OCTET STRING } 118 The ECC-CMS-SharedInfo keyInfo field contains the object identifier 119 of the key-encryption algorithm and associated parameters. This 120 algorithm will be used to wrap the content-encryption key. In this 121 specification, the AES Key Wrap algorithm identifier has absent 122 parameters. 124 The ECC-CMS-SharedInfo entityUInfo field optionally contains 125 additional keying material supplied by the sending agent. Note that 126 [CMS] requires implementations to accept a KeyAgreeRecipientInfo 127 SEQUENCE that includes the ukm field. If the ukm field is present, 128 the ukm is placed in the entityUInfo field. The ukm value need not 129 be longer than the key-encryption key that will be produced by the 130 KDF. When present, the ukm ensures that a different key-encryption 131 key is generated, even when the originator ephemeral private key is 132 improperly used more than once. 134 The ECC-CMS-SharedInfo suppPubInfo field contains the length of the 135 generated key-encryption key, in bits, represented as a 32-bit 136 number. For example, the key length for AES-256 would be 0x00000100. 138 2.1. ANSI-X9.63-KDF 140 The ANSI-X9.63-KDF key derivation function is a simple construct 141 based on a one-way hash function described in ANS X9.63 [X963]. This 142 KDF is also described in Section 3.6.1 of [SEC1]. 144 Three values are concatenated to produce the input string to the KDF: 145 1. The shared secret value generated by ECDH, K. 146 2. The iteration counter, starting with one, as described below. 147 3. The DER-encoded ECC-CMS-SharedInfo structure. 149 To generate a key-encryption key, generates one or more KM blocks, 150 with the counter starting at 0x00000001, and incrementing the counter 151 for each subsequent KM block until enough material has been 152 generated. The KM blocks are concatenated left to right: 154 KM(i) = Hash(K || INT32(counter=i) || DER(ECC-CMS-SharedInfo)) 156 KEK = KM(counter=1) || KM(counter=2) ... 158 KEK is the pairwise key-encryption key. 160 2.2. HKDF 162 The HKDF key derivation function is a robust construct based on a 163 one-way hash function described in RFC 5869 [HMAC]. HKDF is 164 comprised of two steps: HKDF-Extract followed by HKDF-Expand. 166 Three values are used as inputs to the HKDF: 167 1. The shared secret value generated by ECDH, K. 168 2. The length in octets of the keying data to be generated. 169 3. The DER-encoded ECC-CMS-SharedInfo structure. 171 The ECC-CMS-SharedInfo structure includes the ukm. This field is 172 optional, and if it is present, the ukm is also used as the HKDF 173 salt. 175 The length of the generated key-encryption key is used two places, 176 once in bits, and once in octets. The ECC-CMS-SharedInfo structure 177 includes the length of the generated key-encryption key in bits. The 178 HKDF-Expand function takes an argument for the length of the 179 generated key-encryption key in octets. 181 In summary: 183 if ukm is provided, then salt = ukm, else salt = zero 184 PRK = HKDF-Extract(salt, K) 186 KEK = HKDF-Expand(PRK, DER(ECC-CMS-SharedInfo), SizeInOctets(KEK)) 188 KEK is the pairwise key-encryption key. 190 3. Enveloped-data Conventions 192 The CMS enveloped-data content type [CMS] consists of an encrypted 193 content and wrapped content-encryption keys for one or more 194 recipients. The ECDH key agreement algorithm is used to generate a 195 pairwise key-encryption key between the originator and a particular 196 recipient. Then, the key-encryption key is used to wrap the content- 197 encryption key for that recipient. When there more than one 198 recipient, the same content-encryption key is wrapped for each of 199 them. 201 A compliant implementation MUST meet the requirements for 202 constructing an enveloped-data content type in Section 6 of [CMS]. 204 A content-encryption key MUST be randomly generated for each instance 205 of an enveloped-data content type. The content-encryption key is 206 used to encrypt the content. 208 3.1. EnvelopedData Fields 210 The enveloped-data content type is ASN.1 encoded using the 211 EnvelopedData syntax. The fields of the EnvelopedData syntax MUST be 212 populated as described in [CMS]; for the recipients that use X25519 213 or X448 the RecipientInfo kari choice MUST be used. 215 3.2. KeyAgreeRecipientInfo Fields 217 The fields of the KeyAgreeRecipientInfo syntax MUST be populated as 218 described in this section when X25519 or X448 is employed for one or 219 more recipients. 221 The KeyAgreeRecipientInfo version MUST be 3. 223 The KeyAgreeRecipientInfo originator provides three alternatives for 224 identifying the originator's public key, and the originatorKey 225 alternative MUST be used. The originatorKey MUST contain an 226 ephemeral key for the originator. The originatorKey algorithm field 227 MUST contain the id-ecPublicKey object identifier along with 228 ECParameters as specified in [PKIXECC]. The originator's ephemeral 229 public key MUST be encoded using the type ECPoint as specified in 230 [CMSECC]. As a convenience, 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 236 ECParameters ::= CHOICE { 237 namedCurve OBJECT IDENTIFIER 238 -- implicitCurve NULL 239 -- specifiedCurve SpecifiedECDomain -- } 241 The object identifiers for X25519 and X448 have been assigned in 242 [ID.curdle-pkix]. They are repeated below for convenience. 244 When using X25519, the ECPoint contains exactly 32 octets, and the 245 ECParameters namedCurve MUST contain the following object identifier: 247 id-X25519 OBJECT IDENTIFIER ::= { 1.3.101.110 } 249 When using X448, the ECPoint contains exactly 56 octets, and the 250 ECParameters namedCurve MUST contain the following object identifier: 252 id-X448 OBJECT IDENTIFIER ::= { 1.3.101.111 } 254 KeyAgreeRecipientInfo ukm is optional. Note that [CMS] requires 255 implementations to accept a KeyAgreeRecipientInfo SEQUENCE that 256 includes the ukm field. If present, the ukm is placed in the 257 entityUInfo field of the ECC-CMS-SharedInfo as input to the KDF. The 258 ukm value need not be longer than the key-encryption key produced by 259 the KDF. 261 KeyAgreeRecipientInfo keyEncryptionAlgorithm MUST contain the object 262 identifier of the key-encryption algorithm that will be used to wrap 263 the content-encryption key. The conventions for using AES-128, 264 AES-192, and AES-256 in the key wrap mode are specified in [CMSAES]. 266 KeyAgreeRecipientInfo recipientEncryptedKeys includes a recipient 267 identifier and encrypted key for one or more recipients. The 268 RecipientEncryptedKey KeyAgreeRecipientIdentifier MUST contain either 269 the issuerAndSerialNumber identifying the recipient's certificate or 270 the RecipientKeyIdentifier containing the subject key identifier from 271 the recipient's certificate. In both cases, the recipient's 272 certificate contains the recipient's static X25519 or X448 public 273 key. RecipientEncryptedKey EncryptedKey MUST contain the content- 274 encryption key encrypted with the pairwise key-encryption key using 275 the algorithm specified by the KeyWrapAlgorithm. 277 4. Authenticated-data Conventions 279 The CMS authenticated-data content type [CMS] consists an 280 authenticated content, a message authentication code (MAC), and 281 encrypted authentication keys for one or more recipients. The ECDH 282 key agreement algorithm is used to generate a pairwise key-encryption 283 key between the originator and a particular recipient. Then, the 284 key-encryption key is used to wrap the authentication key for that 285 recipient. When there more than one recipient, the same 286 authentication key is wrapped for each of them. 288 A compliant implementation MUST meet the requirements for 289 constructing an authenticated-data content type in Section 9 of 290 [CMS]. 292 A authentication key MUST be randomly generated for each instance of 293 an authenticated-data content type. The authentication key is used 294 to compute the MAC over the content. 296 4.1. AuthenticatedData Fields 298 The authenticated-data content type is ASN.1 encoded using the 299 AuthenticatedData syntax. The fields of the AuthenticatedData syntax 300 MUST be populated as described in [CMS]; for the recipients that use 301 X25519 or X448 the RecipientInfo kari choice MUST be used. 303 4.2. KeyAgreeRecipientInfo Fields 305 The fields of the KeyAgreeRecipientInfo syntax MUST be populated as 306 described in Section 3.2 of this document. 308 5. Authenticated-Enveloped-data Conventions 310 The CMS authenticated-enveloped-data content type content type 311 [AUTHENV] consists of an authenticated and encrypted content and 312 encrypted content-authenticated-encryption keys for one or more 313 recipients. The ECDH key agreement algorithm is used to generate a 314 pairwise key-encryption key between the originator and a particular 315 recipient. Then, the key-encryption key is used to wrap the content- 316 authenticated-encryption key for that recipient. When there more 317 than one recipient, the same content-authenticated-encryption key is 318 wrapped for each of them. 320 A compliant implementation MUST meet the requirements for 321 constructing an authenticated-data content type in Section 2 of 322 [AUTHENV]. 324 A content-authenticated-encryption key MUST be randomly generated for 325 each instance of an authenticated-enveloped-data content type. The 326 content-authenticated-encryption key key is used to authenticate and 327 encrypt the content. 329 5.1. AuthEnvelopedData Fields 331 The authenticated-enveloped-data content type is ASN.1 encoded using 332 the AuthEnvelopedData syntax. The fields of the AuthEnvelopedData 333 syntax MUST be populated as described in [AUTHENV]; for the 334 recipients that use X25519 or X448 the RecipientInfo kari choice MUST 335 be used. 337 5.2. KeyAgreeRecipientInfo Fields 339 The fields of the KeyAgreeRecipientInfo syntax MUST be populated as 340 described in Section 3.2 of this document. 342 6. Certificate Conventions 344 RFC 5280 [PROFILE] specifies the profile for using X.509 Certificates 345 in Internet applications. A recipient static public key is needed 346 for X25519 or X448, and the originator obtains that public key from 347 the recipient's certificate. The conventions in this section augment 348 RFC 5280 [PROFILE]. 350 The id-ecPublicKey object identifier continues to identify the static 351 ECDH public key for the recipient. The associated EcpkParameters 352 parameters structure is specified in [PKIXALG], and the namedCurve 353 alternative MUST be used. The object identifiers from Section 3.2 of 354 this document are used for X25519 and X448. The EcpkParameters 355 parameters structure is repeated here for convenience: 357 EcpkParameters ::= CHOICE { 358 ecParameters ECParameters, 359 namedCurve OBJECT IDENTIFIER, 360 implicitlyCA NULL } 362 The certificate issuer MAY use indicate the intended usage for the 363 certified public key by including the key usage certificate extension 364 as specified in Section 4.2.1.3 of [PROFILE]. If the keyUsage 365 extension is present in a certificate that conveys an ECDH static 366 public key, then the key usage extension MUST set the keyAgreement 367 bit. 369 7. Key Agreement Algorithm Identifiers 371 The following object identifiers are assigned to indicate ECDH with 372 HKDF using various one-way hash functions. These are expected to be 373 used as AlgorithmIdentifiers with a parameter that specifies the key- 374 encryption algorithm. 376 dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= { 377 TBD0 } 379 dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= { 380 TBD1 } 382 dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= { 383 TBD2 } 385 8. SMIMECapabilities Attribute Conventions 387 A sending agent MAY announce to other agents that it supports ECDH 388 key agreement using the SMIMECapabilities signed attribute in a 389 signed message [SMIME] or a certificate [CERTCAP]. Following the 390 pattern established in [CMSECC], the SMIMECapabilities associated 391 with ECDH carries a DER-encoded object identifier that identifies 392 support for ECDH in conjunction with a particular KDF, and it 393 includes a parameter that names the key wrap algorithm. 395 The following SMIMECapabilities values (in hexidecimal) from [CMSECC] 396 might be of interest to implementations that support X25519 and X448: 398 ECDH with ANSI-X9.63-KDF using SHA-256; uses AES-128 key wrap: 399 30 15 06 06 2B 81 04 01 0B 01 30 0B 06 09 60 86 48 01 65 03 04 400 01 05 402 ECDH with ANSI-X9.63-KDF using SHA-384; uses AES-128 key wrap: 403 30 15 06 06 2B 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04 404 01 05 406 ECDH with ANSI-X9.63-KDF using SHA-512; uses AES-128 key wrap: 407 30 15 06 06 2B 81 04 01 0B 03 30 0B 06 09 60 86 48 01 65 03 04 408 01 05 410 ECDH with ANSI-X9.63-KDF using SHA-256; uses AES-256 key wrap: 411 30 15 06 06 2B 81 04 01 0B 01 30 0B 06 09 60 86 48 01 65 03 04 412 01 2D 414 ECDH with ANSI-X9.63-KDF using SHA-384; uses AES-256 key wrap: 415 30 15 06 06 2B 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04 416 01 2D 418 ECDH with ANSI-X9.63-KDF using SHA-512; uses AES-256 key wrap: 419 30 15 06 06 2B 81 04 01 0B 03 30 0B 06 09 60 86 48 01 65 03 04 420 01 2D 422 The following SMIMECapabilities values (in hexidecimal) based on the 423 algorithm identifiers in Section 7 of this document might be of 424 interest to implementations that support X25519 and X448: 426 ECDH with HKDF using SHA-256; uses AES-128 key wrap: 427 TBD 429 ECDH with HKDF using SHA-384; uses AES-128 key wrap: 430 TBD 432 ECDH with HKDF using SHA-512; uses AES-128 key wrap: 433 TBD 435 ECDH with HKDF using SHA-256; uses AES-256 key wrap: 436 TBD 438 ECDH with HKDF using SHA-384; uses AES-256 key wrap: 439 TBD 441 ECDH with HKDF using SHA-512; uses AES-256 key wrap: 442 TBD 444 9. Security Considerations 446 Please consult the security considerations of [CMS] for security 447 considerations related to the enveloped-data content type and the 448 authenticated-data content type. 450 Please consult the security considerations of [AUTHENV] for security 451 considerations related to the authenticated-enveloped-data content 452 type. 454 Please consult the security considerations of [CURVES] for security 455 considerations related to the use of X25519 and X448. 457 The originator uses an ephemeral public/private key pair that is 458 generated on the same elliptic curve as the public key of the 459 recipient. The ephemeral key pair is used for a single CMS protected 460 content type, and then it is discarded. If the originator wants to 461 be able to decrypt the content (for enveloped-data and authenticated- 462 enveloped-data) or check the authentication (for authenticated-data), 463 then the originator needs to treat themselves as a recipient. 465 As specified in [CMS], implementations MUST support processing of the 466 KeyAgreeRecipientInfo ukm field, so interoperability is not a concern 467 if the ukm is present or absent. The ukm is placed in the 468 entityUInfo field of the ECC-CMS-SharedInfo structure. When present, 469 the ukm ensures that a different key-encryption key is generated, 470 even when the originator ephemeral private key is improperly used 471 more than once. 473 10. IANA Considerations 475 Three object identifiers for the Key Agreement Algorithm Identifiers 476 in Sections 7 are needed. Are they going to come from an IANA 477 registry or from the registry that assigned the object identifiers in 478 [ID.curdle-pkix]? 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.curdle-pkix] 501 Josefsson, S., and J. Schaad, "Algorithm Identifiers for 502 Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for 503 use in the Internet X.509 Public Key Infrastructure", 504 15 August 2016, Work-in-progress. 506 [PKIXALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and 507 Identifiers for the Internet X.509 Public Key 508 Infrastructure Certificate and Certificate Revocation List 509 (CRL) Profile", RFC 3279, April 2002. 511 [PKIXECC] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 512 "Elliptic Curve Cryptography Subject Public Key 513 Information", RFC 5480, March 2009. 515 [PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 516 Housley, R., and W. Polk, "Internet X.509 Public Key 517 Infrastructure Certificate and Certificate Revocation List 518 (CRL) Profile", RFC 5280, May 2008. 520 [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 521 Elliptic Curve Cryptography", version 2.0, May 2009, 522 . 524 [SMIME] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 525 Mail Extensions (S/MIME) Version 3.2 Message 526 Specification", RFC 5751, January 2010. 528 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 529 Requirement Levels", BCP 14, RFC 2119, March 1997. 531 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 532 One (ASN.1): Specification of basic notation", ITU-T 533 Recommendation X.680, 2015. 535 [X690] ITU-T, "Information technology -- ASN.1 encoding rules: 536 Specification of Basic Encoding Rules (BER), Canonical 537 Encoding Rules (CER) and Distinguished Encoding Rules 538 (DER)", ITU-T Recommendation X.690, 2015. 540 12. Informative References 542 [CMSECC] Turner, S., and D. Brown, "Use of Elliptic Curve 543 Cryptography (ECC) Algorithms in Cryptographic Message 544 Syntax (CMS)", RFC 5753, January 2010. 546 [CMSAES] Schaad, J., "Use of the Advanced Encryption Standard (AES) 547 Encryption Algorithm in Cryptographic Message Syntax 548 (CMS)", RFC 3565, July 2003. 550 [DH1976] Diffie, W., and M. E. Hellman, "New Directions in 551 Cryptography", IEEE Trans. on Info. Theory, Vol. IT-22, 552 Nov. 1976, pp. 644-654. 554 [X963] "Public-Key Cryptography for the Financial Services 555 Industry: Key Agreement and Key Transport Using Elliptic 556 Curve Cryptography", American National Standard 557 X9.63-2001, 2001. 559 13. Acknowledgements 561 Thanks to Jim Schaad, Stefan Santesson, Sean Turner for their review 562 and insightful suggestions. 564 Author Address 566 Russ Housley 567 918 Spring Knoll Drive 568 Herndon, VA 20170 569 USA 570 housley@vigilsec.com