idnits 2.17.1 draft-ietf-smime-3278bis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 5, 2009) is 5590 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 2282 -- Looks like a reference, but probably isn't: '2' on line 2283 ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) -- Obsolete informational reference (is this intentional?): RFC 3278 (ref. 'CMS-ECC') (Obsoleted by RFC 5753) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 S/MIME WG Sean Turner, IECA 2 Internet Draft Dan Brown, Certicom 3 Intended Status: Informational January 5, 2009 4 Obsoletes: 3278 (once approved) 5 Expires: July 5, 2009 7 Use of Elliptic Curve Cryptography (ECC) Algorithms 8 in Cryptographic Message Syntax (CMS) 9 draft-ietf-smime-3278bis-05.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on June 5, 2008. 34 Copyright Notice 36 Copyright (c) 2009 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. 46 Abstract 48 This document describes how to use Elliptic Curve Cryptography (ECC) 49 public-key algorithms in the Cryptographic Message Syntax (CMS). The 50 ECC algorithms support the creation of digital signatures and the 51 exchange of keys to encrypt or authenticate content. The definition 52 of the algorithm processing is based on the NIST FIPS 186-3 for 53 digital signature, NIST SP800-56A and SEC1 for key agreement, RFC 54 3370 and RFC 3565 for key wrap and content encryption, NIST FIPS 180- 55 3 for message digest, SEC1 for key derivation, and RFC 2104 and RFC 56 4231 for message authentication code standards. This document 57 obsoletes RFC 3278. 59 Discussion 61 This draft is being discussed on the 'ietf-smime' mailing list. To 62 subscribe, send a message to ietf-smime-request@imc.org with the 63 single word subscribe in the body of the message. There is a Web site 64 for the mailing list at . 66 Table of Contents 68 1. Introduction...................................................3 69 1.1. Requirements Terminology..................................3 70 2. SignedData using ECC...........................................3 71 2.1. SignedData using ECDSA....................................4 72 3. EnvelopedData using ECC Algorithms.............................5 73 3.1. EnvelopedData using (ephemeral-static) ECDH...............5 74 3.2. EnvelopedData using 1-Pass ECMQV..........................7 75 4. AuthenticatedData and AuthEnvelopedData using ECC.............10 76 4.1. AuthenticatedData using 1-pass ECMQV.....................10 77 4.2. AuthEnvelopedData using 1-pass ECMQV.....................11 78 5. Certificates using ECC........................................12 79 6. SMIMECapabilities Attribute and ECC...........................12 80 7. ASN.1 Syntax..................................................20 81 7.1. Algorithm Identifiers....................................20 82 7.2. Other Syntax.............................................24 83 8. Recommended Algorithms and Elliptic Curves....................25 84 9. Security Considerations.......................................28 85 10. IANA Considerations..........................................33 86 11. References...................................................33 87 11.1. Normative...............................................33 88 11.2. Informative.............................................35 89 Appendix A ASN.1 Modules.........................................36 90 Appendix A.1 1988 ASN.1 Module................................36 91 Appendix A.2 2004 ASN.1 Module................................43 93 Appendix B Changes since RFC 3278................................53 94 Acknowledgements.................................................56 95 Author's Addresses...............................................56 97 1. Introduction 99 The Cryptographic Message Syntax (CMS) is cryptographic algorithm 100 independent. This specification defines a profile for the use of 101 Elliptic Curve Cryptography (ECC) public key algorithms in the CMS. 102 The ECC algorithms are incorporated into the following CMS content 103 types: 105 - 'SignedData' to support ECC-based digital signature methods 106 (ECDSA) to sign content; 108 - 'EnvelopedData' to support ECC-based public-key agreement 109 methods (ECDH and ECMQV) to generate pairwise key-encryption 110 keys to encrypt content-encryption keys used for content 111 encryption; 113 - 'AuthenticatedData' to support ECC-based public-key agreement 114 methods (ECMQV) to generate pairwise key-encryption keys to 115 encrypt message-authentication keys used for content 116 authentication and integrity; and, 118 - 'AuthEnvelopedData' to support ECC-based public-key agreement 119 methods (ECMQV) to generate pairwise key-encryption keys to 120 encrypt message-authentication and content-encryption keys used 121 for content authentication, integrity, and encryption. 123 Certification of EC public keys is also described to provide public- 124 key distribution in support of the specified techniques. 126 The document will obsolete [CMS-ECC]. The technical changes 127 performed since RFC 3278 are detailed in Appendix B. 129 1.1. Requirements Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [MUST]. 135 2. SignedData using ECC 137 This section describes how to use ECC algorithms with the CMS 138 SignedData format to sign data. 140 2.1. SignedData using ECDSA 142 This section describes how to use the Elliptic Curve Digital 143 Signature Algorithm (ECDSA) with SignedData. ECDSA is specified in 144 [FIPS186-3]. The method is the elliptic curve analog of the Digital 145 Signature Algorithm (DSA) [FIPS186-3]. ECDSA is used with the Secure 146 Hash Algorithm (SHA) [FIPS180-3]. 148 In an implementation that uses ECDSA with CMS SignedData, the 149 following techniques and formats MUST be used. 151 2.1.1. Fields of the SignedData 153 When using ECDSA with SignedData, the fields of SignerInfo are as in 154 [CMS], but with the following restrictions: 156 - digestAlgorithm MUST contain the algorithm identifier of the hash 157 algorithm (see Section 7.1.1) which MUST be one of the 158 following: id-sha1, id-sha224, id-sha256, id-sha384, or id- 159 sha512. 161 - signatureAlgorithm contains the signature algorithm identifier 162 (see Section 7.1.3): ecdsa-with-SHA1, ecdsa-with-SHA224, ecdsa- 163 with-SHA256, ecdsa-with-SHA384, or ecdsa-with-SHA512. 165 - signature MUST contain the DER encoding (as an octet string) of a 166 value of the ASN.1 type ECDSA-Sig-Value (see Section 7.2). 168 When using ECDSA, the SignedData certificates field MAY include the 169 certificate(s) for the EC public key(s) used in the generation of the 170 ECDSA signatures in SignedData. ECC certificates are discussed in 171 Section 5. 173 2.1.2. Actions of the sending agent 175 When using ECDSA with SignedData, the sending agent uses the message 176 digest calculation process and signature generation process for 177 SignedData that are specified in [CMS]. To sign data, the sending 178 agent uses the signature method specified in [FIPS186-3]. 180 The sending agent encodes the resulting signature using the 181 ECDSA-Sig-Value syntax (see Section 7.2) and places it in the 182 SignerInfo signature field. 184 2.1.3. Actions of the receiving agent 186 When using ECDSA with SignedData, the receiving agent uses the 187 message digest calculation process and signature verification process 188 for SignedData that are specified in [CMS]. To verify SignedData, 189 the receiving agent uses the signature verification method specified 190 in [FIPS186-3]. 192 In order to verify the signature, the receiving agent retrieves the 193 integers r and s from the SignerInfo signature field of the received 194 message. 196 3. EnvelopedData using ECC Algorithms 198 This section describes how to use ECC algorithms with the CMS 199 EnvelopedData format. 201 This document does not specify the static-static ECDH, method C(0,2, 202 ECC CDH) from [SP800-56A]. Static-static ECDH is analogous to 203 static-static DH, which is specified in [CMS-ALG]. Ephemeral-static 204 ECDH and 1-Pass ECMQV were specified because they provide better 205 security due to the originator's ephemeral contribution to the key 206 agreement scheme. 208 3.1. EnvelopedData using (ephemeral-static) ECDH 210 This section describes how to use the ephemeral-static Elliptic Curve 211 Diffie-Hellman (ECDH) key agreement algorithm with EnvelopedData, 212 method C(1, 1, ECC CDH) from [SP800-56A] and ECDH with the standard 213 primitive from Section 3.3.1 of [SEC1]. Ephemeral-static ECDH is the 214 elliptic curve analog of the ephemeral-static Diffie-Hellman key 215 agreement algorithm specified jointly in the documents [CMS-ALG] and 216 [CMS-DH]. 218 If an implementation uses ECDH with CMS EnvelopedData, then the 219 following techniques and formats MUST be used. 221 The fields of EnvelopedData are as in [CMS]; as ECDH is a key 222 agreement algorithm, the RecipientInfo kari choice is used. 224 3.1.1. Fields of KeyAgreeRecipientInfo 226 When using ephemeral-static ECDH with EnvelopedData, the fields of 227 KeyAgreeRecipientInfo are as follows: 229 - version MUST be 3. 231 - originator MUST be the alternative originatorKey. The 232 originatorKey algorithm field MUST contain the id-ecPublicKey 233 object identifier (see Section 7.1.3). The parameters 234 associated with id-ecPublicKey MUST be absent or ECParameters. 235 NOTE: The previous version of this document required NULL to be 236 present; support for this legacy form is OPTIONAL. The 237 originatorKey publicKey field MUST contain the value of the 238 ASN.1 type ECPoint (see Section 7.2), which represents the 239 sending agent's ephemeral EC public key. The ECPoint in 240 uncompressed form MUST be supported. 242 - ukm MAY be present or absent. However, message originators 243 SHOULD include the ukm. As specified in RFC 3852 [CMS], 244 implementations MUST support ukm message recipient processing, 245 so interoperability is not a concern if the ukm is present or 246 absent. The ukm is placed in the entityUInfo field of the ECC- 247 CMS-SharedInfo structure. When present, the ukm is used to 248 ensure that a different key-encryption key is generated, even 249 when the ephemeral private key is improperly used more than 250 once, by using the ECC-CMS-SharedInfo as an input to the key 251 derivation function (see Section 7.2). 253 - keyEncryptionAlgorithm MUST contain the object identifier of the 254 key encryption algorithm, which in this case is a key agreement 255 algorithm (see Section 7.1.4). The parameters field contains 256 KeyWrapAlgorithm. The KeyWrapAlgorithm is the algorithm 257 identifier that indicates the symmetric encryption algorithm 258 used to encrypt the content-encryption key (CEK) with the key- 259 encryption key (KEK) and any associated parameters (see Section 260 7.1.5). Algorithm requirements are found in Section 8. 262 - recipientEncryptedKeys contains an identifier and an encrypted 263 key for each recipient. The RecipientEncryptedKey 264 KeyAgreeRecipientIdentifier MUST contain either the 265 issuerAndSerialNumber identifying the recipient's certificate or 266 the RecipientKeyIdentifier containing the subject key identifier 267 from the recipient's certificate. In both cases, the 268 recipient's certificate contains the recipient's static ECDH 269 public key. RecipientEncryptedKey EncryptedKey MUST contain the 270 content-encryption key encrypted with the ephemeral-static, 271 ECDH-generated pairwise key-encryption key using the algorithm 272 specified by the KeyWrapAlgorithm. 274 3.1.2. Actions of the sending agent 276 When using ephemeral-static ECDH with EnvelopedData, the sending 277 agent first obtains the recipient's EC public key and domain 278 parameters (e.g. from the recipient's certificate). The sending 279 agent then determines an integer "keydatalen", which is the 280 KeyWrapAlgorithm symmetric key-size in bits, and also a bit string 281 "SharedInfo", which is the DER encoding of ECC-CMS-SharedInfo (see 282 Section 7.2). The sending agent then performs the key deployment and 283 the key agreement operation of the Elliptic Curve Diffie-Hellman 284 Scheme specified in [SP800-56A] or [SEC1]; in either case, use the 285 KDF defined in Section 3.6.1 of [SEC1] with the hash algorithm 286 identified in the key agreement algorithm. As a result the sending 287 agent obtains: 289 - an ephemeral public key, which is represented as a value of the 290 type ECPoint (see Section 7.2), encapsulated in a bit string and 291 placed in the KeyAgreeRecipientInfo originator field, and 293 - a shared secret bit string "K", which is used as the pairwise 294 key-encryption key for that recipient, as specified in [CMS]. 296 In a single message, if there are multiple layers for a recipient, 297 then the ephemeral public key can be reused by the originator for 298 that recipient in each of the different layers. 300 3.1.3. Actions of the receiving agent 302 When using ephemeral-static ECDH with EnvelopedData, the receiving 303 agent determines the bit string "SharedInfo", which is the DER 304 encoding of ECC-CMS-SharedInfo (see Section 7.2), and the integer 305 "keydatalen" from the key-size, in bits, of the KeyWrapAlgorithm. The 306 receiving agent retrieves the ephemeral EC public key from the bit 307 string KeyAgreeRecipientInfo originator, with a value of the type 308 ECPoint (see Section 7.2) encapsulated as a bit string, and if 309 present, originally supplied additional user key material from the 310 ukm field. The receiving agent performs the key agreement operation 311 of the Elliptic Curve Diffie-Hellman Scheme specified in [SP800-56A] 312 or [SEC1]; in either case, use the KDF defined in Section 3.6.1 of 313 [SEC1]. As a result, the receiving agent obtains a shared secret bit 314 string "K", which is used as the pairwise key-encryption key to 315 unwrap the CEK. 317 3.2. EnvelopedData using 1-Pass ECMQV 319 This section describes how to use the 1-Pass elliptic curve MQV 320 (ECMQV) key agreement algorithm with EnvelopedData, method 321 C(1, 2, ECC MQV) from [SP800-56A]. Like the KEA algorithm [CMS-KEA], 322 1-Pass ECMQV uses three key pairs: an ephemeral key pair, a static 323 key pair of the sending agent, and a static key pair of the receiving 324 agent. Using an algorithm with the sender static key pair allows for 325 knowledge of the message creator, this means that authentication can, 326 in some circumstances, be obtained for AuthEnvelopedData and 327 AuthenticatedData. This means that 1-Pass ECMQV can be a common 328 algorithm for EnvelopedData, AuthenticatedData and AuthEnvelopedData, 329 while ECDH can only be used in EnvelopedData. 331 If an implementation uses 1-Pass ECMQV with CMS EnvelopedData, then 332 the following techniques and formats MUST be used. 334 The fields of EnvelopedData are as in [CMS]; as 1-Pass ECMQV is a key 335 agreement algorithm, the RecipientInfo kari choice is used. When 336 using 1-Pass ECMQV, the EnvelopedData originatorInfo field MAY 337 include the certificate(s) for the EC public key(s) used in the 338 formation of the pairwise key. ECC certificates are discussed in 339 Section 5. 341 3.2.1. Fields of KeyAgreeRecipientInfo 343 When using 1-Pass ECMQV with EnvelopedData, the fields of 344 KeyAgreeRecipientInfo are: 346 - version MUST be 3. 348 - originator identifies the static EC public key of the sender. It 349 SHOULD be one of the alternatives, issuerAndSerialNumber or 350 subjectKeyIdentifier, and point to one of the sending agent's 351 certificates. 353 - ukm MUST be present. The ukm field is an octet string which MUST 354 contain the DER encoding of the type MQVuserKeyingMaterial (see 355 Section 7.2). The MQVuserKeyingMaterial ephemeralPublicKey 356 algorithm field MUST contain the id-ecPublicKey object 357 identifier (see Section 7.1.3). The parameters associated with 358 id-ecPublicKey MUST be absent or ECParameters. NOTE: The 359 previous version of this document required NULL to be present; 360 support for this legacy form is OPTIONAL. The 361 MQVuserKeyingMaterial ephemeralPublicKey publicKey field MUST 362 contain the DER-encoding of the ASN.1 type ECPoint (see Section 363 7.2) representing the sending agent's ephemeral EC public key. 364 The MQVuserKeyingMaterial addedukm field, if present, contains 365 additional user keying material from the sending agent. 367 - keyEncryptionAlgorithm MUST contain the object identifier of the 368 key encryption algorithm, which in this case is a key agreement 369 algorithm (see Section 7.1.4). The parameters field contains 370 KeyWrapAlgorithm. The KeyWrapAlgorithm indicates the symmetric 371 encryption algorithm used to encrypt the CEK with the KEK 372 generated using the 1-Pass ECMQV algorithm and any associated 373 parameters (see Section 7.1.5). Algorithm requirements are 374 found in Section 8. 376 - recipientEncryptedKeys contains an identifier and an encrypted 377 key for each recipient. The RecipientEncryptedKey 378 KeyAgreeRecipientIdentifier MUST contain either the 379 issuerAndSerialNumber identifying the recipient's certificate or 380 the RecipientKeyIdentifier containing the subject key identifier 381 from the recipient's certificate. In both cases, the 382 recipient's certificate contains the recipient's static ECMQV 383 public key. RecipientEncryptedKey EncryptedKey MUST contain the 384 content-encryption key encrypted with the 1-Pass ECMQV-generated 385 pairwise key-encryption key using the algorithm specified by the 386 KeyWrapAlgorithm. 388 3.2.2. Actions of the sending agent 390 When using 1-Pass ECMQV with EnvelopedData, the sending agent first 391 obtains the recipient's EC public key and domain parameters (e.g. 392 from the recipient's certificate), and checks that the domain 393 parameters are the same as the sender's domain parameters. The 394 sending agent then determines an integer "keydatalen", which is the 395 KeyWrapAlgorithm symmetric key-size in bits, and also a bit string 396 "SharedInfo", which is the DER encoding of ECC-CMS-SharedInfo (see 397 Section 7.2). The sending agent then performs the key deployment and 398 key agreement operations of the Elliptic Curve MQV Scheme specified 399 in [SP800-56A], but uses the KDF defined in Section 3.6.1 of [SEC1]. 400 As a result, the sending agent obtains: 402 - an ephemeral public key, which is represented as a value of type 403 ECPoint (see Section 7.2), encapsulated in a bit string, placed 404 in an MQVuserKeyingMaterial ephemeralPublicKey publicKey field 405 (see Section 7.2), and 407 - a shared secret bit string "K", which is used as the pairwise 408 key-encryption key for that recipient, as specified in [CMS]. 410 In a single message, if there are multiple layers for a recipient, 411 then the ephemeral public key can be reused by the originator for 412 that recipient in each of the different layers. 414 3.2.3. Actions of the receiving agent 416 When using 1-Pass ECMQV with EnvelopedData, the receiving agent 417 determines the bit string "SharedInfo", which is the DER encoding of 418 ECC-CMS-SharedInfo (see Section 7.2), and the integer "keydatalen" 419 from the key-size, in bits, of the KeyWrapAlgorithm. The receiving 420 agent then retrieves the static and ephemeral EC public keys of the 421 originator, from the originator and ukm fields as described in 422 Section 3.2.1, and its static EC public key identified in the rid 423 field and checks that the originator's domain parameters are the same 424 as the recipient's domain parameters. The receiving agent then 425 performs the key agreement operation of the Elliptic Curve MQV Scheme 426 [SP800-56A], but uses the KDF defined in Section 3.6.1 of [SEC1]. As 427 a result, the receiving agent obtains a shared secret bit string "K", 428 which is used as the pairwise key-encryption key to unwrap the CEK. 430 4. AuthenticatedData and AuthEnvelopedData using ECC 432 This section describes how to use ECC algorithms with the CMS 433 AuthenticatedData format. AuthenticatedData lacks non-repudiation, 434 and so in some instances is preferable to SignedData. (For example, 435 the sending agent might not want the message to be authenticated when 436 forwarded.) 438 This section also describes how to use ECC algorithms with the CMS 439 AuthEnvelopedData format [CMS-AUTHENV]. AuthEnvelopedData supports 440 authentication and encryption, and in some instances is preferable to 441 signing and then encrypting data. 443 For both AuthenticatedData and AuthEnvelopedData, data origin 444 authentication with 1-Pass ECMQV can only be provided when there is 445 one and only one recipient. When there are multiple recipients, an 446 attack is possible where one recipient modifies the content without 447 other recipients noticing [BON]. A sending agent who is concerned 448 with such an attack SHOULD use a separate AuthenticatedData or 449 AuthEnvelopedData for each recipient. 451 Using an algorithm with the sender static key pair allows for 452 knowledge of the message creator; this means that authentication can, 453 in some circumstances, be obtained for AuthEnvelopedData and 454 AuthenticatedData. This means that 1-Pass ECMQV can be a common 455 algorithm for EnvelopedData, AuthenticatedData, and AuthEnvelopedData 456 while ECDH can only be used in EnvelopedData. 458 4.1. AuthenticatedData using 1-pass ECMQV 460 This section describes how to use the 1-Pass elliptic curve MQV 461 (ECMQV) key agreement algorithm with AuthenticatedData. ECMQV is 462 method C(1, 2, ECC MQV) from [SP800-56A]. 464 When using ECMQV with AuthenticatedData, the fields of 465 AuthenticatedData are as in [CMS], but with the following 466 restrictions: 468 - macAlgorithm MUST contain the algorithm identifier of the message 469 authentication code (MAC) algorithm (see Section 7.1.7) which 470 MUST be one of the following: hmac-SHA1, id-hmacWITHSHA224, id- 471 hmacWITHSHA256, id-hmacWITHSHA384, or id-hmacWITHSHA512. 473 - digestAlgorithm MUST contain the algorithm identifier of the hash 474 algorithm (see Section 7.1.1) which MUST be one of the 475 following: id-sha1, id-sha224, id-sha256, id-sha384, and id- 476 sha512. 478 As 1-Pass ECMQV is a key agreement algorithm, the RecipientInfo kari 479 choice is used in the AuthenticatedData. When using 1-Pass ECMQV, 480 the AuthenticatedData originatorInfo field MAY include the 481 certificate(s) for the EC public key(s) used in the formation of the 482 pairwise key. ECC certificates are discussed in Section 5. 484 4.1.1. Fields of the KeyAgreeRecipientInfo 486 The AuthenticatedData KeyAgreeRecipientInfo fields are used in the 487 same manner as the fields for the corresponding EnvelopedData 488 KeyAgreeRecipientInfo fields of Section 3.2.1 of this document. 490 4.1.2. Actions of the sending agent 492 The sending agent uses the same actions as for EnvelopedData with 493 1-Pass ECMQV, as specified in Section 3.2.2 of this document. 495 In a single message, if there are multiple layers for a recipient, 496 then the ephemeral public key can be reused by the originator for 497 that recipient in each of the different layers. 499 4.1.3. Actions of the receiving agent 501 The receiving agent uses the same actions as for EnvelopedData with 502 1-Pass ECMQV, as specified in Section 3.2.3 of this document. 504 4.2. AuthEnvelopedData using 1-pass ECMQV 506 This section describes how to use the 1-Pass elliptic curve MQV 507 (ECMQV) key agreement algorithm with AuthEnvelopedData. ECMQV is 508 method C(1, 2, ECC MQV) from [SP800-56A]. 510 When using ECMQV with AuthEnvelopedData, the fields of 511 AuthenticatedData are as in [CMS-AUTHENV]. 513 As 1-Pass ECMQV is a key agreement algorithm, the RecipientInfo kari 514 choice is used. When using 1-Pass ECMQV, the AuthEnvelopedData 515 originatorInfo field MAY include the certificate(s) for the EC public 516 key used in the formation of the pairwise key. ECC certificates are 517 discussed in Section 5. 519 4.2.1. Fields of the KeyAgreeRecipientInfo 521 The AuthEnvelopedData KeyAgreeRecipientInfo fields are used in the 522 same manner as the fields for the corresponding EnvelopedData 523 KeyAgreeRecipientInfo fields of Section 3.2.1 of this document. 525 4.2.2. Actions of the sending agent 527 The sending agent uses the same actions as for EnvelopedData with 1- 528 Pass ECMQV, as specified in Section 3.2.2 of this document. 530 In a single message, if there are multiple layers for a recipient, 531 then the ephemeral public key can be reused by the originator for 532 that recipient in each of the different layers. 534 4.2.3. Actions of the receiving agent 536 The receiving agent uses the same actions as for EnvelopedData with 537 1-Pass ECMQV, as specified in Section 3.2.3 of this document. 539 5. Certificates using ECC 541 Internet X.509 certificates [PKI] can be used in conjunction with 542 this specification to distribute agents' public keys. The use of ECC 543 algorithms and keys within X.509 certificates is specified in [PKI- 544 ALG]. 546 6. SMIMECapabilities Attribute and ECC 548 A sending agent MAY announce to receiving agents that it supports one 549 or more of the ECC algorithms specified in this document by using the 550 SMIMECapabilities signed attribute [MSG] in either a signed message 551 or a certificate [CERTCAP]. 553 The SMIMECapabilities attribute value indicates support for one of 554 the ECDSA signature algorithms in a SEQUENCE with the capabilityID 555 field containing the object identifier ecdsa-with-SHA1 with NULL 556 parameters and ecdsa-with-SHA* (where * is 224, 256, 384, or 512) 557 with absent parameters. The DER encodings are: 559 ecdsa-with-SHA1: 30 0b 06 07 2a 86 48 ce 3d 04 01 05 00 561 ecdsa-with-SHA224: 30 0a 06 08 2a 86 48 ce 3d 04 03 01 563 ecdsa-with-SHA256: 30 0a 06 08 2a 86 48 ce 3d 04 03 02 565 ecdsa-with-SHA384: 30 0a 06 08 2a 86 48 ce 3d 04 03 03 567 ecdsa-with-SHA512: 30 0a 06 08 2a 86 48 ce 3d 04 03 04 569 NOTE: The SMIMECapabilities attribute indicates that parameters for 570 ECDSA with SHA-1 are NULL, however, the parameters are absent when 571 used to generate a digital signature. 573 The SMIMECapabilities attribute value indicates support for 574 a) the standard ECDH key agreement algorithm, 575 b) the cofactor ECDH key agreement algorithm, or 576 c) the 1-Pass ECMQV key agreement algorithm 577 is a SEQUENCE with the capabilityID field containing the object 578 identifier 579 a) dhSinglePass-stdDH-sha*kdf-scheme, 580 b) dhSinglePass-cofactorDH-sha*kdf-scheme, or 581 c) mqvSinglePass-sha*kdf-scheme 582 respectively (where * is 1, 224, 256, 384, or 512) with the 583 parameters present. The parameters indicate the supported key- 584 encryption algorithm with the KeyWrapAlgorithm algorithm identifier. 586 The DER encodings that indicate capabilities are as follows (KA is 587 key agreement, KDF is key derivation function, and Wrap is key wrap 588 algorithm): 590 KA=ECDH standard KDF=SHA-1 Wrap=Triple-DES 592 30 1c 06 09 2b 81 05 10 86 48 3f 00 02 30 0f 06 0b 2a 86 48 86 593 f7 0d 01 09 10 03 06 05 00 595 KA=ECDH standard KDF=SHA-224 Wrap=Triple-DES 597 30 19 06 06 2b 81 04 01 0B 00 30 0f 06 0b 2a 86 48 86 f7 0d 01 598 09 10 03 06 05 00 600 KA=ECDH standard KDF=SHA-256 Wrap=Triple-DES 602 30 19 06 06 2b 81 04 01 0B 01 30 0f 06 0b 2a 86 48 86 f7 0d 01 603 09 10 03 06 05 00 605 KA=ECDH standard KDF=SHA-384 Wrap=Triple-DES 607 30 19 06 06 2b 81 04 01 0B 02 30 0f 06 0b 2a 86 48 86 f7 0d 01 608 09 10 03 06 05 00 610 KA=ECDH standard KDF=SHA-512 Wrap=Triple-DES 612 30 19 06 06 2b 81 04 01 0B 03 30 0f 06 0b 2a 86 48 86 f7 0d 01 613 09 10 03 06 05 00 615 KA=ECDH standard KDF=SHA-1 Wrap=AES-128 617 30 1a 06 09 2b 81 05 10 86 48 3f 00 02 30 0d 06 09 60 86 48 01 618 65 03 04 01 05 05 00 620 KA=ECDH standard KDF=SHA-224 Wrap=AES-128 622 30 17 06 06 2b 81 04 01 0B 00 30 0d 06 09 60 86 48 01 65 03 04 623 01 05 05 00 625 KA=ECDH standard KDF=SHA-256 Wrap=AES-128 627 30 17 06 06 2b 81 04 01 0B 01 30 0d 06 09 60 86 48 01 65 03 04 628 01 05 05 00 630 KA=ECDH standard KDF=SHA-384 Wrap=AES-128 632 30 17 06 06 2b 81 04 01 0B 02 30 0d 06 09 60 86 48 01 65 03 04 633 01 05 05 00 635 KA=ECDH standard KDF=SHA-512 Wrap=AES-128 637 30 17 06 06 2b 81 04 01 0B 03 30 0d 06 09 60 86 48 01 65 03 04 638 01 05 05 00 640 KA=ECDH standard KDF=SHA-1 Wrap=AES-192 642 30 1a 06 09 2b 81 05 10 86 48 3f 00 02 30 0d 06 09 60 86 48 01 643 65 03 04 01 2D 05 00 645 KA=ECDH standard KDF=SHA-224 Wrap=AES-192 647 30 17 06 06 2b 81 04 01 0B 00 30 0d 06 09 60 86 48 01 65 03 04 648 01 2D 05 00 650 KA=ECDH standard KDF=SHA-256 Wrap=AES-192 652 30 17 06 06 2b 81 04 01 0B 01 30 0d 06 09 60 86 48 01 65 03 04 653 01 2D 05 00 655 KA=ECDH standard KDF=SHA-384 Wrap=AES-192 657 30 17 06 06 2b 81 04 01 0B 02 30 0d 06 09 60 86 48 01 65 03 04 658 01 2D 05 00 660 KA=ECDH standard KDF=SHA-512 Wrap=AES-192 662 30 17 06 06 2b 81 04 01 0B 03 30 0d 06 09 60 86 48 01 65 03 04 663 01 2D 05 00 665 KA=ECDH standard KDF=SHA-1 Wrap=AES-256 667 30 1a 06 09 2b 81 05 10 86 48 3f 00 02 30 0d 06 09 60 86 48 01 668 65 03 04 01 2D 05 00 670 KA=ECDH standard KDF=SHA-224 Wrap=AES-256 672 30 17 06 06 2b 81 04 01 0B 00 30 0d 06 09 60 86 48 01 65 03 04 673 01 2D 05 00 675 KA=ECDH standard KDF=SHA-256 Wrap=AES-256 677 30 17 06 06 2b 81 04 01 0B 01 30 0d 06 09 60 86 48 01 65 03 04 678 01 2D 05 00 680 KA=ECDH standard KDF=SHA-384 Wrap=AES-256 682 30 17 06 06 2b 81 04 01 0B 02 30 0d 06 09 60 86 48 01 65 03 04 683 01 2D 05 00 685 KA=ECDH standard KDF=SHA-512 Wrap=AES-256 687 30 17 06 06 2b 81 04 01 0B 03 30 0d 06 09 60 86 48 01 65 03 04 688 01 2D 05 00 690 KA=ECDH cofactor KDF=SHA-1 Wrap=Triple-DES 692 30 1c 06 09 2b 81 05 10 86 48 3f 00 03 30 0f 06 0b 2a 86 48 86 693 f7 0d 01 09 10 03 06 05 00 695 KA=ECDH cofactor KDF=SHA-224 Wrap=Triple-DES 697 30 19 06 06 2b 81 04 01 0E 00 30 0f 06 0b 2a 86 48 86 f7 0d 01 698 09 10 03 06 05 00 700 KA=ECDH cofactor KDF=SHA-256 Wrap=Triple-DES 702 30 19 06 06 2b 81 04 01 0E 01 30 0f 06 0b 2a 86 48 86 f7 0d 01 703 09 10 03 06 05 00 705 KA=ECDH cofactor KDF=SHA-384 Wrap=Triple-DES 707 30 19 06 06 2b 81 04 01 0E 02 30 0f 06 0b 2a 86 48 86 f7 0d 01 708 09 10 03 06 05 00 710 KA=ECDH cofactor KDF=SHA-512 Wrap=Triple-DES 712 30 19 06 06 2b 81 04 01 0E 03 30 0f 06 0b 2a 86 48 86 f7 0d 01 713 09 10 03 06 05 00 715 KA=ECDH cofactor KDF=SHA-1 Wrap=AES-128 717 30 1a 06 09 2b 81 05 10 86 48 3f 00 03 30 0d 06 09 60 86 48 01 718 65 03 04 01 05 05 00 720 KA=ECDH cofactor KDF=SHA-224 Wrap=AES-128 722 30 17 06 06 2b 81 04 01 0E 00 30 0d 06 09 60 86 48 01 65 03 04 723 01 05 05 00 725 KA=ECDH cofactor KDF=SHA-256 Wrap=AES-128 727 30 17 06 06 2b 81 04 01 0E 01 30 0d 06 09 60 86 48 01 65 03 04 728 01 05 05 00 730 KA=ECDH cofactor KDF=SHA-384 Wrap=AES-128 732 30 17 06 06 2b 81 04 01 0E 02 30 0d 06 09 60 86 48 01 65 03 04 733 01 05 05 00 735 KA=ECDH cofactor KDF=SHA-512 Wrap=AES-128 737 30 17 06 06 2b 81 04 01 0E 03 30 0d 06 09 60 86 48 01 65 03 04 738 01 05 05 00 740 KA=ECDH cofactor KDF=SHA-1 Wrap=AES-192 742 30 1a 06 09 2b 81 05 10 86 48 3f 00 03 30 0d 06 09 60 86 48 01 743 65 03 04 01 19 05 00 745 KA=ECDH cofactor KDF=SHA-224 Wrap=AES-192 747 30 17 06 06 2b 81 04 01 0E 00 30 0d 06 09 60 86 48 01 65 03 04 748 01 19 05 00 750 KA=ECDH cofactor KDF=SHA-256 Wrap=AES-192 752 30 17 06 06 2b 81 04 01 0E 01 30 0d 06 09 60 86 48 01 65 03 04 753 01 19 05 00 755 KA=ECDH cofactor KDF=SHA-384 Wrap=AES-192 757 30 17 06 06 2b 81 04 01 0E 02 30 0d 06 09 60 86 48 01 65 03 04 758 01 19 05 00 760 KA=ECDH cofactor KDF=SHA-512 Wrap=AES-192 762 30 17 06 06 2b 81 04 01 0E 03 30 0d 06 09 60 86 48 01 65 03 04 763 01 19 05 00 765 KA=ECDH cofactor KDF=SHA-1 Wrap=AES-256 767 30 1a 06 09 2b 81 05 10 86 48 3f 00 03 30 0d 06 09 60 86 48 01 768 65 03 04 01 2D 05 00 770 KA=ECDH cofactor KDF=SHA-224 Wrap=AES-256 772 30 17 06 06 2b 81 04 01 0E 00 30 0d 06 09 60 86 48 01 65 03 04 773 01 2D 05 00 775 KA=ECDH cofactor KDF=SHA-256 Wrap=AES-256 777 30 17 06 06 2b 81 04 01 0E 01 30 0d 06 09 60 86 48 01 65 03 04 778 01 2D 05 00 780 KA=ECDH cofactor KDF=SHA-384 Wrap=AES-256 782 30 17 06 06 2b 81 04 01 0E 02 30 0d 06 09 60 86 48 01 65 03 04 783 01 2D 05 00 785 KA=ECDH cofactor KDF=SHA-512 Wrap=AES-256 787 30 17 06 06 2b 81 04 01 0E 03 30 0d 06 09 60 86 48 01 65 03 04 788 01 2D 05 00 790 KA=ECMQV 1-Pass KDF=SHA-1 Wrap=Triple-DES 792 30 1c 06 09 2b 81 05 10 86 48 3f 00 10 30 0f 06 0b 2a 86 48 86 793 f7 0d 01 09 10 03 06 05 00 795 KA=ECMQV 1-Pass KDF=SHA-224 Wrap=Triple-DES 797 30 19 06 06 2b 81 04 01 0F 00 30 0f 06 0b 2a 86 48 86 f7 0d 01 798 09 10 03 06 05 00 800 KA=ECMQV 1-Pass KDF=SHA-256 Wrap=Triple-DES 802 30 19 06 06 2b 81 04 01 0F 01 30 0f 06 0b 2a 86 48 86 f7 0d 01 803 09 10 03 06 05 00 805 KA=ECMQV 1-Pass KDF=SHA-384 Wrap=Triple-DES 807 30 19 06 06 2b 81 04 01 0F 02 30 0f 06 0b 2a 86 48 86 f7 0d 01 808 09 10 03 06 05 00 810 KA=ECMQV 1-Pass KDF=SHA-512 Wrap=Triple-DES 812 30 19 06 06 2b 81 04 01 0F 03 30 0f 06 0b 2a 86 48 86 f7 0d 01 813 09 10 03 06 05 00 815 KA=ECMQV 1-Pass KDF=SHA-1 Wrap=AES-128 817 30 1a 06 09 2b 81 05 10 86 48 3f 00 10 30 0d 06 09 60 86 48 01 818 65 03 04 01 05 05 00 820 KA=ECMQV 1-Pass KDF=SHA-224 Wrap=AES-128 822 30 17 06 06 2b 81 04 01 0F 00 30 0d 06 09 60 86 48 01 65 03 04 823 01 05 05 00 825 KA=ECMQV 1-Pass KDF=SHA-256 Wrap=AES-128 827 30 17 06 06 2b 81 04 01 0F 01 30 0d 06 09 60 86 48 01 65 03 04 828 01 05 05 00 830 KA=ECMQV 1-Pass KDF=SHA-384 Wrap=AES-128 832 30 17 06 06 2b 81 04 01 0F 02 30 0d 06 09 60 86 48 01 65 03 04 833 01 05 05 00 835 KA=ECMQV 1-Pass KDF=SHA-512 Wrap=AES-128 837 30 17 06 06 2b 81 04 01 0F 03 30 0d 06 09 60 86 48 01 65 03 04 838 01 05 05 00 840 KA=ECMQV 1-Pass KDF=SHA-1 Wrap=AES-192 842 30 1a 06 09 2b 81 05 10 86 48 3f 00 10 30 0d 06 09 60 86 48 01 843 65 03 04 01 2D 05 00 845 KA=ECMQV 1-Pass KDF=SHA-224 Wrap=AES-192 847 30 17 06 06 2b 81 04 01 0F 00 30 0d 06 09 60 86 48 01 65 03 04 848 01 19 05 00 850 KA=ECMQV 1-Pass KDF=SHA-256 Wrap=AES-192 852 30 17 06 06 2b 81 04 01 0F 01 30 0d 06 09 60 86 48 01 65 03 04 853 01 19 05 00 855 KA=ECMQV 1-Pass KDF=SHA-384 Wrap=AES-192 857 30 17 06 06 2b 81 04 01 0F 02 30 0d 06 09 60 86 48 01 65 03 04 858 01 19 05 00 860 KA=ECMQV 1-Pass KDF=SHA-512 Wrap=AES-192 862 30 17 06 06 2b 81 04 01 0F 03 30 0d 06 09 60 86 48 01 65 03 04 863 01 19 05 00 865 KA=ECMQV 1-Pass KDF=SHA-1 Wrap=AES-256 867 30 1a 06 09 2b 81 05 10 86 48 3f 00 10 30 0d 06 09 60 86 48 01 868 65 03 04 01 2D 05 00 870 KA=ECMQV 1-Pass KDF=SHA-224 Wrap=AES-256 872 30 17 06 06 2b 81 04 01 0F 00 30 0d 06 09 60 86 48 01 65 03 04 873 01 2D 05 00 875 KA=ECMQV 1-Pass KDF=SHA-256 Wrap=AES-256 877 30 17 06 06 2b 81 04 01 0F 01 30 0d 06 09 60 86 48 01 65 03 04 878 01 2D 05 00 880 KA=ECMQV 1-Pass KDF=SHA-384 Wrap=AES-256 882 30 17 06 06 2b 81 04 01 0F 02 30 0d 06 09 60 86 48 01 65 03 04 883 01 2D 05 00 885 KA=ECMQV 1-Pass KDF=SHA-512 Wrap=AES-256 887 30 17 06 06 2b 81 04 01 0F 03 30 0d 06 09 60 86 48 01 65 03 04 888 01 2D 05 00 890 NOTE: The S/MIME Capabilities indicate that parameters for the key 891 wrap algorithm AES-* (where * is 128, 192, or 256) are NULL; however, 892 the parameters are absent when used to encrypt/decrypt a content 893 encryption key. 895 NOTE: The S/MIME Capabilities for the supported AES content 896 encryption key sizes are defined in [CMS-AES]. 898 NOTE: The S/MIME Capabilities for the supported MAC algorithms are 899 defined in [CMS-ASN]. 901 7. ASN.1 Syntax 903 The ASN.1 syntax used in this document is gathered in this section 904 for reference purposes. 906 7.1. Algorithm Identifiers 908 This section provides the object identifiers for the algorithms used 909 in this document along with any associated parameters. 911 7.1.1. Digest Algorithms 913 Digest algorithm object identifiers are used in the SignedData 914 digestAlgorithms and digestAlgorithm fields and the AuthenticatedData 915 digestAlgorithm field. The digest algorithms used in this document 916 are: SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. The object 917 identifiers and parameters associated with these algorithms are found 918 in [CMS-ALG] and [CMS-SHA2]. 920 7.1.2. Originator Public Key 922 The KeyAgreeRecipientInfo originator field uses the following object 923 identifier to indicate an elliptic curve public key: 925 id-ecPublicKey OBJECT IDENTIFIER ::= { 926 ansi-x9-62 keyType(2) 1 } 928 where 930 ansi-x9-62 OBJECT IDENTIFIER ::= { 931 iso(1) member-body(2) us(840) 10045 } 933 When the object identifier id-ecPublicKey is used here with an 934 algorithm identifier, the associated parameters MUST be either absent 935 or ECParameters. Implementations MUST accept id-ecPublicKey with 936 absent and ECParameters parameters. If ECParameters is present, its 937 value MUST match the recipient's ECParameters. Implementations 938 SHOULD generate absent parameters for the id-ecPublicKey object 939 identifier in the KeyAgreeRecipientInfo originator field. 941 NOTE: [CMS-ECC] indicated the parameters were NULL. Support for this 942 legacy form is OPTIONAL. 944 7.1.3. Signature Algorithms 946 Signature algorithm identifiers are used in the SignedData 947 signatureAlgorithm and signature fields. The signature algorithms 948 used in this document are ECDSA with SHA-1, ECDSA with SHA-224, ECDSA 949 with SHA-256, ECDSA with SHA-384, and ECDSA with SHA-512. The object 950 identifiers and parameters associated with these algorithms are found 951 in [PKI-ALG]. 953 NOTE: [CMS-ECC] indicated the parameters were NULL. Support for this 954 legacy form is OPTIONAL. 956 7.1.4. Key Agreement Algorithms 958 Key agreement algorithms are used in EnvelopedData, 959 AuthenticatedData, and AuthEnvelopedData in the KeyAgreeRecipientInfo 960 keyEncryptionAlgorithm field. The following object identifiers 961 indicate the key agreement algorithms used in this document: 963 dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 964 x9-63-scheme 2 } 966 dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 967 secg-scheme 11 0 } 969 dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 970 secg-scheme 11 1 } 972 dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 973 secg-scheme 11 2 } 975 dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 976 secg-scheme 11 3 } 978 dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 979 x9-63-scheme 3 } 981 dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 982 secg-scheme 14 0 } 984 dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 985 secg-scheme 14 1 } 987 dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 988 secg-scheme 14 2 } 990 dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 991 secg-scheme 14 3 } 993 mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= { 994 x9-63-scheme 16 } 996 mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= { 997 secg-scheme 15 0 } 999 mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= { 1000 secg-scheme 15 1 } 1002 mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= { 1003 secg-scheme 15 2 } 1005 mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= { 1006 secg-scheme 15 3 } 1008 where 1010 x9-63-scheme OBJECT IDENTIFIER ::= { 1011 iso(1) identified-organization(3) tc68(133) country(16) 1012 x9(840) x9-63(63) schemes(0) } 1014 and 1016 secg-scheme OBJECT IDENTIFIER ::= { 1017 iso(1) identified-organization(3) certicom(132) schemes(1) } 1019 When the object identifiers are used here within an algorithm 1020 identifier, the associated parameters field contains KeyWrapAlgorithm 1021 to indicate the key wrap algorithm and any associated parameters. 1023 7.1.5. Key Wrap Algorithms 1025 Key wrap algorithms are used as part of the parameters in the key 1026 agreement algorithm. The key wrap algorithms used in this document 1027 are Triple-DES, AES-128, AES-192, and AES-256. The object 1028 identifiers and parameters for these algorithms are found in [CMS- 1029 ALG] and [CMS-AES]. 1031 7.1.6. Content Encryption Algorithms 1033 Content encryption algorithms are used in EnvelopedData and 1034 AuthEnvelopedData in the EncryptedContentInfo 1035 contentEncryptionAlgorithm field. The content encryption algorithms 1036 used with EnvelopedData in this document are 3-Key Triple DES in CBC 1037 mode, AES-128 in CBC mode, AES-192 in CBC mode, and AES-256 in CBC 1038 mode. The object identifiers and parameters associated with these 1039 algorithms are found in [CMS-ALG] and [CMS-AES]. The content 1040 encryption algorithms used with AuthEnvelopedData in this document 1041 are AES-128 in CCM mode, AES-192 in CCM mode, AES-256 in CCM mode, 1042 AES-128 in GCM mode, AES-192 in GCM mode, and AES-256 in GCM mode. 1043 The object identifiers and parameters associated with these 1044 algorithms are found in [CMS-AESCG]. 1046 7.1.7. Message Authentication Code Algorithms 1048 Message authentication code algorithms are used in AuthenticatedData 1049 in the macAlgorithm field. The message authentication code 1050 algorithms used in this document are HMAC with SHA-1, HMAC with SHA- 1051 224, HMAC with SHA-256, HMAC with SHA-384, and HMAC with SHA-512. 1052 The object identifiers and parameters associated with these 1053 algorithms are found in [HMAC-SHA1] and [HMAC-SHA2]. 1055 7.1.8. Key Derivation Algorithm 1057 The KDF used in this document is as specified in 3.6.1 of [SEC1]. 1058 The hash algorithm is identified in key agreement algorithm. For 1059 example, dhSinglePass-stdDH-sha256kdf-scheme uses the KDF from [SEC1] 1060 but uses SHA-256 instead of SHA-1. 1062 7.2. Other Syntax 1064 The following additional syntax is used here. 1066 When using ECDSA with SignedData, ECDSA signatures are encoded using 1067 the type: 1069 ECDSA-Sig-Value ::= SEQUENCE { 1070 r INTEGER, 1071 s INTEGER } 1073 ECDSA-Sig-Value is specified in [PKI-ALG]. Within CMS, ECDSA-Sig- 1074 Value is DER-encoded and placed within a signature field of 1075 SignedData. 1077 When using ECDH and ECMQV with EnvelopedData, AuthenticatedData, and 1078 AuthEnvelopedData, ephemeral and static public keys are encoded using 1079 the type ECPoint. Implementations MUST support uncompressed keys, MAY 1080 support compressed keys, and MUST NOT support hybrid keys. 1082 ECPoint ::= OCTET STRING 1084 When using ECMQV with EnvelopedData, AuthenticatedData, and 1085 AuthEnvelopedData, the sending agent's ephemeral public key and 1086 additional keying material are encoded using the type: 1088 MQVuserKeyingMaterial ::= SEQUENCE { 1089 ephemeralPublicKey OriginatorPublicKey, 1090 addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL } 1092 The ECPoint syntax is used to represent the ephemeral public key and 1093 is placed in the ephemeralPublicKey publicKey field. The additional 1094 user keying material is placed in the addedukm field. Then the 1095 MQVuserKeyingMaterial value is DER-encoded and placed within the ukm 1096 field of EnvelopedData, AuthenticatedData, or AuthEnvelopedData. 1098 When using ECDH or ECMQV with EnvelopedData, AuthenticatedData, or 1099 AuthEnvelopedData, the key-encryption keys are derived by using the 1100 type: 1102 ECC-CMS-SharedInfo ::= SEQUENCE { 1103 keyInfo AlgorithmIdentifier, 1104 entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL, 1105 suppPubInfo [2] EXPLICIT OCTET STRING } 1107 The fields of ECC-CMS-SharedInfo are as follows: 1109 keyInfo contains the object identifier of the key-encryption 1110 algorithm (used to wrap the CEK) and associated parameters. In 1111 this specification, 3DES wrap has NULL parameters while the AES 1112 wraps have absent parameters. 1114 entityUInfo optionally contains additional keying material 1115 supplied by the sending agent. When used with ECDH and CMS, the 1116 entityUInfo field contains the octet string ukm. When used with 1117 ECMQV and CMS, the entityUInfo contains the octet string addedukm 1118 (encoded in MQVuserKeyingMaterial). 1120 suppPubInfo contains the length of the generated KEK, in bits, 1121 represented as a 32 bit number, as in [CMS-DH] and [CMS-AES]. 1122 (E.g. for AES-256 it would be 00 00 01 00.) 1124 Within CMS, ECC-CMS-SharedInfo is DER-encoded and used as input to 1125 the key derivation function, as specified in Section 3.6.1 of [SEC1]. 1127 NOTE: ECC-CMS-SharedInfo differs from the OtherInfo specified in 1128 [CMS-DH]. Here, a counter value is not included in the keyInfo field 1129 because the key derivation function specified in Section 3.6.1 of 1130 [SEC1] ensures that sufficient keying data is provided. 1132 8. Recommended Algorithms and Elliptic Curves 1134 It is RECOMMENDED that implementations of this specification support 1135 SignedData and EnvelopedData. Support for AuthenticatedData and 1136 AuthEnvelopedData is OPTIONAL. 1138 In order to encourage interoperability, implementations SHOULD use 1139 the elliptic curve domain parameters specified by [PKI-ALG]. 1141 Implementations that support SignedData with ECDSA: 1143 - MUST support ECDSA with SHA-256; and, 1145 - MAY support ECDSA with SHA-1, ECDSA with SHA-224, ECDSA with SHA- 1146 384, and ECDSA with SHA-512; other digital signature algorithms 1147 MAY also be supported. 1149 When using ECDSA, to promote interoperability it is RECOMMENDED that 1150 the P-192, P-224, and the P-256 curves be used with SHA-256, the P- 1151 384 curve be used with SHA-384, and the P-521 curve be used with SHA- 1152 512. 1154 If EnvelopedData is supported, then ephemeral-static ECDH standard 1155 primitive MUST be supported. Support for ephemeral-static ECDH co- 1156 factor is OPTIONAL and support for 1-Pass ECMQV is also OPTIONAL. 1158 Implementations that support EnvelopedData with the ephemeral-static 1159 ECDH standard primitive: 1161 - MUST support the dhSinglePass-stdDH-sha256kdf-scheme key 1162 agreement algorithm, the id-aes128-wrap key wrap algorithm, and 1163 the id-aes128-cbc content encryption algorithm; and, 1165 - MAY support the dhSinglePass-stdDH-sha1kdf-scheme, dhSinglePass- 1166 stdDH-sha224kdf-scheme, dhSinglePass-stdDH-sha384kdf-scheme and 1167 dhSinglePass-stdDH-sha512kdf-scheme key agreement algorithms, 1168 the id-alg-CMS3DESwrap, id-aes192-wrap, and id-aes256-wrap key 1169 wrap algorithms and the des-ede3-cbc, id-aes192-cbc, and id- 1170 aes256-cbc content encryption algorithms; other algorithms MAY 1171 also be supported. 1173 Implementations that support EnvelopedData with the ephemeral-static 1174 ECDH cofactor primitive: 1176 - MUST support the dhSinglePass-cofactorDH-sha256kdf-scheme key 1177 agreement algorithm, the id-aes128-wrap key wrap algorithm, and 1178 the id-aes128-cbc content encryption algorithm; and, 1180 - MAY support the dhSinglePass-cofactorDH-sha1kdf-scheme, 1181 dhSinglePass-cofactorDH-sha224kdf-scheme, dhSinglePass- 1182 cofactorDH-sha384kdf-scheme, and dhSinglePass-cofactorDH- 1183 sha512kdf-scheme key agreement, the id-alg-CMS3DESwrap, id- 1184 aes192-wrap, and id-aes256-wrap key wrap algorithms and the des- 1185 ede3-cbc, id-aes192-cbc, and id-aes256-cbc content encryption 1186 algorithms; other algorithms MAY also be supported. 1188 Implementations that support EnvelopedData with 1-Pass ECMQV: 1190 - MUST support the mqvSinglePass-sha256kdf-scheme key agreement 1191 algorithm, the id-aes128-wrap key wrap algorithm, and the id- 1192 aes128-cbc content encryption algorithm; and, 1194 - MAY support mqvSinglePass-sha1kdf-scheme, mqvSinglePass- 1195 sha224kdf-scheme, mqvSinglePass-sha384kdf-scheme, and 1196 mqvSinglePass-sha512kdf-scheme key agreement algorithms, the id- 1197 alg-CMS3DESwrap, id-aes192-wrap, and id-aes256-wrap key wrap 1198 algorithms and the des-ede3-cbc, id-aes192-cbc, and id-aes256- 1199 cbc content encryption algorithms; other algorithms MAY also be 1200 supported. 1202 Implementations that support AuthenticatedData with 1-Pass ECMQV: 1204 - MUST support the mqvSinglePass-sha256kdf-scheme key agreement, 1205 the id-aes128-wrap key wrap, the id-sha256 message digest, and 1206 id-hmacWithSHA256 message authentication code algorithms; and, 1208 - MAY support the mqvSinglePass-sha1kdf-scheme, mqvSinglePass- 1209 sha224kdf-scheme, mqvSinglePass-sha384kdf-scheme, mqvSinglePass- 1210 sha512kdf-scheme key agreement algorithms, the id-alg- 1211 CMS3DESwrap, id-aes192-wrap, and id-aes256-wrap key wrap 1212 algorithms, the id-sha1, id-sha224, id-sha384, and id-sha512, 1213 message digest algorithms, and the hmac-SHA1, id-hmacWithSHA224, 1214 id-hmacWithSHA384, and id-hmacWithSHA512 message authentication 1215 code algorithms; other algorithms MAY also be supported. 1217 Implementations that support AuthEnvelopedData with 1-Pass ECMQV: 1219 - MUST support the mqvSinglePass-sha256kdf-scheme key agreement, 1220 the id-aes128-wrap key wrap, and the id-aes128-ccm 1221 authenticated-content encryption; and, 1223 - MAY support the mqvSinglePass-sha1kdf-scheme, mqvSinglePass- 1224 sha224kdf-scheme, mqvSinglePass-sha384kdf-scheme, and 1225 mqvSinglePass-sha512kdf-scheme key agreement algorithms, the id- 1226 alg-CMS3DESwrap, id-aes192-wrap, and id-aes256-wrap key wrap 1227 algorithms, the id-aes192-ccm and id-aes256-ccm authenticated- 1228 content encryption algorithms; other algorithms MAY also be 1229 supported. 1231 9. Security Considerations 1233 Cryptographic algorithms will be broken or weakened over time. 1234 Implementers and users need to check that the cryptographic 1235 algorithms listed in this document continue to provide the expected 1236 level of security. The IETF from time to time may issue documents 1237 dealing with the current state of the art. 1239 Cryptographic algorithms rely on random numbers. See [RANDOM] for 1240 guidance on generation of random numbers. 1242 Receiving agents that validate signatures and sending agents that 1243 encrypt messages need to be cautious of cryptographic processing 1244 usage when validating signatures and encrypting messages using keys 1245 larger than those mandated in this specification. An attacker could 1246 send keys and/or certificates with keys which would result in 1247 excessive cryptographic processing, for example keys larger than 1248 those mandated in this specification, which could swamp the 1249 processing element. Agents which use such keys without first 1250 validating the certificate to a trust anchor are advised to have some 1251 sort of cryptographic resource management system to prevent such 1252 attacks. 1254 Using secret keys of an appropriate size is crucial to the security 1255 of a Diffie-Hellman exchange. For elliptic curve groups, the size of 1256 the secret key must be equal to the size of n (the order of the group 1257 generated by the point g). Using larger secret keys provides 1258 absolutely no additional security, and using smaller secret keys is 1259 likely to result in dramatically less security. (See [SP800-56A] for 1260 more information on selecting secret keys.) 1262 This specification is based on [CMS], [CMS-AES], [CMS-AESCG], [CMS- 1263 ALG], [CMS-AUTHENV], [CMS-DH], [CMS-SHA2], [FIPS180-3], [FIPS186-3], 1264 [HMAC-SHA1], and [HMAC-SHA2], and the appropriate security 1265 considerations of those documents apply. 1267 In addition, implementers of AuthenticatedData and AuthEnvelopedData 1268 should be aware of the concerns expressed in [BON] when using 1269 AuthenticatedData and AuthEnvelopedData to send messages to more than 1270 one recipient. Also, users of MQV should be aware of the 1271 vulnerability described in [K]. 1273 When implementing EnvelopedData, AuthenticatedData, and 1274 AuthEnvelopedData, there are five algorithm related choices that need 1275 to be made: 1277 1) What is the public key size? 1278 2) What is the KDF? 1279 3) What is the key wrap algorithm? 1280 4) What is the content encryption algorithm? 1281 5) What is the curve? 1283 Consideration must be given to strength of the security provided by 1284 each of these choices. Security is measured in bits, where a strong 1285 symmetric cipher with a key of X bits is said to provide X bits of 1286 security. It is recommended that the bits of security provided by 1287 each are roughly equivalent. The following table provides comparable 1288 minimum bits of security [SP800-57] for the ECDH/ECMQV key sizes, 1289 KDFs, key wrapping algorithms, and content encryption algorithms. It 1290 also lists curves [PKI-ALG] for the key sizes. 1292 Minimum | ECDH or | Key | Key | Content | Curves 1293 Bits of | ECQMV | Derivation | Wrap | Encryption | 1294 Security | Key Size | Function | Alg. | Alg. | 1295 ---------+----------+------------+----------+-------------+---------- 1296 80 | 160-223 | SHA-1 | 3DES | 3DES CBC | sect163k1 1297 | | SHA-224 | AES-128 | AES-128 CBC | secp163r2 1298 | | SHA-256 | AES-192 | AES-192 CBC | secp192r1 1299 | | SHA-384 | AES-256 | AES-256 CBC | 1300 | | SHA-512 | | | 1301 ---------+----------+------------+----------+-------------+--------- 1302 112 | 224-255 | SHA-1 | 3DES | 3DES CBC | secp224r1 1303 | | SHA-224 | AES-128 | AES-128 CBC | sect233k1 1304 | | SHA-256 | AES-192 | AES-192 CBC | sect233r1 1305 | | SHA-384 | AES-256 | AES-256 CBC | 1306 | | SHA-512 | | | 1307 ---------+----------+------------+----------+-------------+--------- 1308 128 | 256-383 | SHA-1 | AES-128 | AES-128 CBC | secp256r1 1309 | | SHA-224 | AES-192 | AES-192 CBC | sect283k1 1310 | | SHA-256 | AES-256 | AES-256 CBC | sect283r1 1311 | | SHA-384 | | | 1312 | | SHA-512 | | | 1313 ---------+----------+------------+----------+-------------+--------- 1314 192 | 384-511 | SHA-224 | AES-192 | AES-192 CBC | secp384r1 1315 | | SHA-256 | AES-256 | AES-256 CBC | sect409k1 1316 | | SHA-384 | | | sect409r1 1317 | | SHA-512 | | | 1318 ---------+----------+------------+----------+-------------+--------- 1319 256 | 512+ | SHA-256 | AES-256 | AES-256 CBC | secp521r1 1320 | | SHA-384 | | | sect571k1 1321 | | SHA-512 | | | sect571r1 1322 ---------+----------+------------+----------+-------------+--------- 1323 To promote interoperability, the following choices are RECOMMENDED: 1325 Minimum | ECDH or | Key | Key | Content | Curve 1326 Bits of | ECQMV | Derivation | Wrap | Encryption | 1327 Security | Key Size | Function | Alg. | Alg. | 1328 ---------+----------+------------+----------+-------------+---------- 1329 80 | 192 | SHA-256 | 3DES | 3DES CBC | secp192r1 1330 ---------+----------+------------+----------+-------------+---------- 1331 112 | 224 | SHA-256 | 3DES | 3DES CBC | secp224r1 1332 ---------+----------+------------+----------+-------------+---------- 1333 128 | 256 | SHA-256 | AES-128 | AES-128 CBC | secp256r1 1334 ---------+----------+------------+----------+-------------+---------- 1335 192 | 384 | SHA-384 | AES-256 | AES-256 CBC | secp384r1 1336 ---------+----------+------------+----------+-------------+---------- 1337 256 | 512+ | SHA-512 | AES-256 | AES-256 CBC | secp521r1 1338 ---------+----------+------------+----------+-------------+---------- 1340 When implementing SignedData, there are three algorithm related 1341 choices that need to be made: 1343 1) What is the public key size? 1344 2) What is the hash algorithm? 1345 3) What is the curve? 1347 Consideration must be given to the bits of security provided by each 1348 of these choices. Security is measured in bits, where a strong 1349 symmetric cipher with a key of X bits is said to provide X bits of 1350 security. It is recommended that the bits of security provided by 1351 each choice are roughly equivalent. The following table provides 1352 comparable minimum bits of security [SP800-57] for the ECDSA key 1353 sizes and message digest algorithms. It also lists curves [PKI-ALG] 1354 for the key sizes. 1356 Minimum | ECDSA | Message | Curve 1357 Bits of | Key Size | Digest | 1358 Security | | Algorithm | 1359 ---------+----------+-----------+----------- 1360 80 | 160-223 | SHA-1 | sect163k1 1361 | | SHA-224 | secp163r2 1362 | | SHA-256 | secp192r1 1363 | | SHA-384 | 1364 | | SHA-512 | 1365 ---------+----------+-----------+----------- 1366 112 | 224-255 | SHA-224 | secp224r1 1367 | | SHA-256 | sect233k1 1368 | | SHA-384 | sect233r1 1369 | | SHA-512 | 1370 ---------+----------+-----------+----------- 1371 128 | 256-383 | SHA-256 | secp256r1 1372 | | SHA-384 | sect283k1 1373 | | SHA-512 | sect283r1 1374 ---------+----------+-----------+----------- 1375 192 | 384-511 | SHA-384 | secp384r1 1376 | | SHA-512 | sect409k1 1377 | | | sect409r1 1378 ---------+----------+-----------+----------- 1379 256 | 512+ | SHA-512 | secp521r1 1380 | | | sect571k1 1381 | | | sect571r1 1382 ---------+----------+-----------+----------- 1384 To promote interoperability, the following choices are RECOMMENDED: 1386 Minimum | ECDSA | Message | Curve 1387 Bits of | Key Size | Digest | 1388 Security | | Algorithm | 1389 ---------+----------+-----------+----------- 1390 80 | 192 | SHA-256 | sect192r1 1391 ---------+----------+-----------+----------- 1392 112 | 224 | SHA-256 | secp224r1 1393 ---------+----------+-----------+----------- 1394 128 | 256 | SHA-256 | secp256r1 1395 ---------+----------+-----------+----------- 1396 192 | 384 | SHA-384 | secp384r1 1397 ---------+----------+-----------+----------- 1398 256 | 512+ | SHA-512 | secp521r1 1399 ---------+----------+-----------+----------- 1401 10. IANA Considerations 1403 This document makes extensive use of object identifiers to register 1404 originator public key types and algorithms. The algorithm object 1405 identifiers are registered in the ANSI X9.62, ANSI X9.63, NIST, RSA, 1406 and SECG arcs. Additionally, object identifiers are used to identify 1407 the ASN.1 modules found in Appendix A. These are defined in an arc 1408 delegated by IANA to the SMIME Working Group. No further action by 1409 IANA is necessary for this document or any anticipated updates. 1411 11. References 1413 11.1. Normative 1415 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 1416 3852, July 2004. 1418 [CMS-AES] Schaad, J., "Use of the Advanced Encryption Standard 1419 (AES) Encryption Algorithm in Cryptographic Message 1420 Syntax (CMS)", RFC 3565, July 2003. 1422 [CMS-AESCG] Housley, R., "Using AES-CCM and AES-GCM Authenticated 1423 Encryption in the Cryptographic Message Syntax 1424 (CMS)", RFC 5084, November 2007. 1426 [CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS) 1427 Algorithms", RFC 3370, August 2002. 1429 [CMS-ASN] Hoffman, P., and J. Schaad, "New ASN.1 Modules for 1430 CMS", draft-ietf-smime-new-asn1, work-in-progress. 1432 [CMS-AUTHENV] Housley, R. "Cryptographic Message Syntax (CMS) 1433 Authenticated-Enveloped-Data Content Type", RFC 5083, 1434 November 2007. 1436 [CMS-DH] Rescorla, E., "Diffie-Hellman Key Agreement Method", 1437 RFC 2631, June 1999. 1439 [CMS-SHA2] Turner, S., "Using SHA2 Algorithms with Cryptographic 1440 Message Syntax", draft-ietf-smime-sha2, work-in- 1441 progress. 1443 [FIPS180-3] National Institute of Standards and Technology 1444 (NIST), FIPS Publication 180-3: Secure Hash Standard, 1445 October 2008. 1447 [FIPS186-3] National Institute of Standards and Technology 1448 (NIST), FIPS Publication 186-3: Digital Signature 1449 Standard, (draft) November 2008. 1451 [HMAC-SHA1] Krawczyk, M., Bellare, M., and R. Canetti, "HMAC: 1452 Keyed-Hashing for Message Authentication", RFC 2104, 1453 February 1997. 1455 [HMAC-SHA2] Nystrom, M., "Identifiers and Test Vectors for HMAC- 1456 SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA- 1457 512", RFC 4231, December 2005. 1459 [MUST] Bradner, S., "Key Words for Use in RFCs to Indicate 1460 Requirement Levels", BCP 14, RFC 2119, March 1997. 1462 [MSG] Ramsdell, B., and S. Turner, "S/MIME Version 3.2 1463 Message Specification", draft-ietf-smime-3851bis, 1464 work-in-progress. 1466 [PKI] Cooper, D., Santesson, S., Farrell, S., Boeyen, S. 1467 Housley, R., and W. Polk, "Internet X.509 Public Key 1468 Infrastructure Certificate and Certificate Revocation 1469 List (CRL) Profile", RFC 5280, May 2008. 1471 [PKI-ALG] Turner, S., Brown, D., Yiu, K., Housley, R., and W. 1472 Polk, "Elliptic Curve Cryptography Subject Public Key 1473 Information", draft-ietf-pkix-ecc-subpubkeyinfo, 1474 work-in-progress. 1476 [RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller, 1477 "Randomness Recommendations for Security", RFC 4086, 1478 June 2005. 1480 [RSAOAEP] Schaad, J., Kaliski, B., and R. Housley, "Additional 1481 Algorithms and Identifiers for RSA Cryptography for 1482 use in the Internet X.509 Public Key Infrastructure 1483 Certificate and Certificate Revocation List (CRL) 1484 Profile", RFC 4055, June 2005. 1486 [SEC1] SECG, "Elliptic Curve Cryptography", Standards for 1487 Efficient Cryptography Group, 2000. Available from 1488 www.secg.org/collateral/sec1.pdf. 1490 [SP800-56A] National Institute of Standards and Technology 1491 (NIST), Special Publication 800-56A: Recommendation 1492 Pair-Wise Key Establishment Schemes Using Discrete 1493 Logarithm Cryptography (Revised), March 2007. 1495 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824- 1496 1:2002. Information Technology - Abstract Syntax 1497 Notation One. 1499 11.2. Informative 1501 [BON] D. Boneh, "The Security of Multicast MAC", 1502 Presentation at Selected Areas of Cryptography 2000, 1503 Center for Applied Cryptographic Research, University 1504 of Waterloo, 2000. Paper version available from 1505 http://crypto.stanford.edu/~dabo/papers/mmac.ps 1507 [CERTCAP] Santesson, S., "X.509 Certificate Extension for 1508 Secure/Multipurpose Internet Mail Extensions (S/MIME) 1509 Capabilities", RFC 4262, December 2005. 1511 [CMS-ECC] Blake-Wilson, S., Brown, D., and P. Lambert, "Use of 1512 Elliptic Curve Cryptography (ECC) Algorithms in 1513 Cryptographic Message Syntax (CMS)", RFC 3278, April 1514 2002. 1516 [CMS-KEA] Pawling, J., "CMS KEA and SKIPJACK Conventions", RFC 1517 2876, July 2000. 1519 [K] B. Kaliski, "MQV Vulnerability", Posting to ANSI X9F1 1520 and IEEE P1363 newsgroups, 1998. 1522 [PKI-ASN] Hoffman, P., and J. Schaad, "New ASN.1 Modules for 1523 PKIX", draft-ietf-pkix-new-asn1, work-in-progress. 1525 [SP800-57] National Institute of Standards and Technology 1526 (NIST), Special Publication 800-57: Recommendation 1527 for Key Management - Part 1 (Revised), March 2007. 1529 [X.681] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824- 1530 2:2002. Information Technology - Abstract Syntax 1531 Notation One: Information Object Specification. 1533 [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824- 1534 3:2002. Information Technology - Abstract Syntax 1535 Notation One: Constraint Specification. 1537 [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824- 1538 4:2002. Information Technology - Abstract Syntax 1539 Notation One: Parameterization of ASN.1 1540 Specifications, 2002. 1542 Appendix A ASN.1 Modules 1544 Appendix A.1 provides the normative ASN.1 definitions for the 1545 structures described in this specification using ASN.1 as defined in 1546 [X.680] for compilers that support the 1988 ASN.1. 1548 Appendix A.2 provides an informative ASN.1 definitions for the 1549 structures described in this specification using ASN.1 as defined in 1550 [X.680], [X.681], [X.682], and [X.683] for compilers that support the 1551 2002 ASN.1. This appendix contains the same information as Appendix 1552 A.1 in a more recent (and precise) ASN.1 notation, however Appendix 1553 A.1 takes precedence in case of conflict. 1555 NOTE: The values for the TBAs will be included during AUTH48. 1557 //** RFC Editor: Remove this note prior to publication **// 1559 Appendix A.1 1988 ASN.1 Module 1561 SMIMEECCAlgs-1988 1562 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1563 smime(16) modules(0) TBA1 } 1565 DEFINITIONS IMPLICIT TAGS ::= 1567 BEGIN 1569 -- EXPORTS ALL 1571 IMPORTS 1573 -- From [PKI] 1575 AlgorithmIdentifier 1576 FROM PKIX1Explicit88 1577 { iso(1) identified-organization(3) dod(6) 1578 internet(1) security(5) mechanisms(5) pkix(7) mod(0) 1579 pkix1-explicit(18) } 1581 -- From [RSAOAEP] 1583 id-sha224, id-sha256, id-sha384, id-sha512 1584 FROM PKIX1-PSS-OAEP-Algorithms 1585 { iso(1) identified-organization(3) dod(6) internet(1) 1586 security(5) mechanisms(5) pkix(7) id-mod(0) 1587 id-mod-pkix1-rsa-pkalgs(33) } 1589 -- From [PKI-ALG] 1591 id-sha1, ecdsa-with-SHA1, ecdsa-with-SHA224, 1592 ecdsa-with-SHA256, ecdsa-with-SHA384, ecdsa-with-SHA512, 1593 id-ecPublicKey, ECDSA-Sig-Value, ECPoint, ECParameters 1594 FROM PKIXAlgIDs-2008 1595 { iso(1) identified-organization(3) dod(6) internet(1) 1596 security(5) mechanisms(5) pkix(7) id-mod(0) TBA2 } 1598 -- From [CMS] 1600 OriginatorPublicKey, UserKeyingMaterial 1601 FROM CryptographicMessageSyntax2004 1602 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1603 smime(16) modules(0) cms-2004(24) } 1605 -- From [CMS-ALG] 1607 hMAC-SHA1, id-hmacWithSHA224, id-hmacWithSHA256, id-hmacWithSHA384, 1608 id-hmacWithSHA512, des-ede3-cbc, id-alg-CMS3DESwrap, CBCParameter 1609 FROM CryptographicMessageSyntaxAlgorithms 1610 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1611 smime(16) modules(0) cmsalg-2008(TBA3) } 1613 -- From [CMS-AES] 1615 id-aes128-CBC, id-aes192-CBC, id-aes256-CBC, AES-IV, 1616 id-aes128-wrap, id-aes192-wrap, id-aes256-wrap 1617 FROM CMSAesRsaesOaep 1618 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1619 smime(16) modules(0) id-mod-cms-aes(19) } 1621 -- From [CMS-AESCG] 1623 id-aes128-CCM, id-aes192-CCM, id-aes256-CCM, CCMParameters 1624 id-aes128-GCM, id-aes192-GCM, id-aes256-GCM, GCMParameters 1625 FROM CMS-AES-CCM-and-AES-GCM 1626 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1627 smime(16) modules(0) id-mod-cms-aes(32) } 1629 ; 1631 -- 1632 -- Message Digest Algorithms 1633 -- 1635 -- id-sha1 Parameters are preferred absent 1636 -- id-sha224 Parameters are preferred absent 1637 -- id-sha256 Parameters are preferred absent 1638 -- id-sha384 Parameters are preferred absent 1639 -- id-sha512 Parameters are preferred absent 1641 -- 1642 -- Signature Algorithms 1643 -- 1645 -- ecdsa-with-SHA1 Parameters are NULL 1646 -- ecdsa-with-SHA224 Parameters are absent 1647 -- ecdsa-with-SHA256 Parameters are absent 1648 -- ecdsa-with-SHA384 Parameters are absent 1649 -- ecdsa-with-SHA512 Parameters are absent 1651 -- ECDSA Signature Value 1652 -- Contents of SignatureValue OCTET STRING 1654 -- ECDSA-Sig-Value ::= SEQUENCE { 1655 -- r INTEGER, 1656 -- s INTEGER 1657 -- } 1659 -- 1660 -- Key Agreement Algorithms 1661 -- 1663 x9-63-scheme OBJECT IDENTIFIER ::= { 1664 iso(1) identified-organization(3) tc68(133) country(16) x9(840) 1665 x9-63(63) schemes(0) } 1667 secg-scheme OBJECT IDENTIFIER ::= { 1668 iso(1) identified-organization(3) certicom(132) schemes(1) } 1670 -- 1671 -- Diffie-Hellman Single Pass, Standard, with KDFs 1672 -- 1674 -- Parameters are always present and indicate the key wrap algorithm 1675 -- with KeyWrapAlgorithm. 1677 dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 1678 x9-63-scheme 2 } 1680 dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 1681 secg-scheme 11 0 } 1683 dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 1684 secg-scheme 11 1 } 1686 dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 1687 secg-scheme 11 2 } 1689 dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 1690 secg-scheme 11 3 } 1692 -- 1693 -- Diffie-Hellman Single Pass, Cofactor, with KDFs 1694 -- 1696 dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 1697 x9-63-scheme 3 } 1699 dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 1700 secg-scheme 14 0 } 1702 dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 1703 secg-scheme 14 1 } 1705 dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 1706 secg-scheme 14 2 } 1708 dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 1709 secg-scheme 14 3 } 1711 -- 1712 -- MQV Single Pass, Cofactor, with KDFs 1713 -- 1715 mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= { 1716 x9-63-scheme 16 } 1718 mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= { 1719 secg-scheme 15 0 } 1721 mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= { 1722 secg-scheme 15 1 } 1724 mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= { 1725 secg-scheme 15 2 } 1727 mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= { 1728 secg-scheme 15 3 } 1730 -- 1731 -- Key Wrap Algorithms 1732 -- 1734 KeyWrapAlgorithm ::= AlgorithmIdentifier 1736 -- id-alg-CMS3DESwrap Parameters are NULL 1737 -- id-aes128-wrap Parameters are absent 1738 -- id-aes192-wrap Parameters are absent 1739 -- id-aes256-wrap Parameters are absent 1741 -- 1742 -- Content Encryption Algorithms 1743 -- 1745 -- des-ede3-cbc Parameters are CBCParameter 1746 -- id-aes128-CBC Parameters are AES-IV 1747 -- id-aes192-CBC Parameters are AES-IV 1748 -- id-aes256-CBC Parameters are AES-IV 1749 -- id-aes128-CCM Parameters are CCMParameters 1750 -- id-aes192-CCM Parameters are CCMParameters 1751 -- id-aes256-CCM Parameters are CCMParameters 1752 -- id-aes128-GCM Parameters are GCMParameters 1753 -- id-aes192-GCM Parameters are GCMParameters 1754 -- id-aes256-GCM Parameters are GCMParameters 1756 -- 1757 -- Message Authentication Code Algorithms 1758 -- 1760 -- hMAC-SHA1 Parameters are preferred absent 1761 -- id-hmacWithSHA224 Parameters are absent 1762 -- id-hmacWithSHA256 Parameters are absent 1763 -- id-hmacWithSHA384 Parameters are absent 1764 -- id-hmacWithSHA512 Parameters are absent 1765 -- 1766 -- Originator Public Key Algorithms 1767 -- 1769 -- id-ecPublicKey Parameters are absent, NULL, or ECParameters 1771 -- Format for both ephemeral and static public keys 1773 -- ECPoint ::= OCTET STRING 1775 -- ECParameters ::= CHOICE { 1776 -- namedCurve OBJECT IDENTIFIER 1777 -- commented out in [PKI-ALG] implicitCurve NULL 1778 -- commented out in [PKI-ALG] specifiedCurve SpecifiedECDomain 1779 -- commented out in [PKI-ALG] Extensible 1780 -- } 1781 -- implicitCurve and specifiedCurve MUST NOT be used in PKIX. 1782 -- Details for SpecifiedECDomain can be found in [X9.62]. 1783 -- Any future additions to this CHOICE should be coordinated 1784 -- with ANSI X9. 1786 -- Format of KeyAgreeRecipientInfo ukm field when used with 1787 -- ECMQV 1789 MQVuserKeyingMaterial ::= SEQUENCE { 1790 ephemeralPublicKey OriginatorPublicKey, 1791 addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL 1792 } 1794 -- 'SharedInfo' for input to KDF when using ECDH and ECMQV with 1795 -- EnvelopedData, AuthenticatedData, or AuthEnvelopedData 1797 ECC-CMS-SharedInfo ::= SEQUENCE { 1798 keyInfo AlgorithmIdentifier, 1799 entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL, 1800 suppPubInfo [2] EXPLICIT OCTET STRING 1801 } 1802 -- 1803 -- S/MIME Capabilities 1804 -- An identifier followed by type. 1805 -- 1807 -- 1808 -- S/MIME Capabilities: Message Digest Algorithms 1809 -- 1811 -- Found in [CMS-SHA2]. 1813 -- 1814 -- S/MIME Capabilities: Signature Algorithms 1815 -- 1817 -- ecdsa-with-SHA1 Type NULL 1818 -- ecdsa-with-SHA224 Type absent 1819 -- ecdsa-with-SHA256 Type absent 1820 -- ecdsa-with-SHA384 Type absent 1821 -- ecdsa-with-SHA512 Type absent 1823 -- 1824 -- S/MIME Capabilities: ECDH, Single Pass, Standard 1825 -- 1827 -- dhSinglePass-stdDH-sha1kdf Type is the KeyWrapAlgorithm 1828 -- dhSinglePass-stdDH-sha224kdf Type is the KeyWrapAlgorithm 1829 -- dhSinglePass-stdDH-sha256kdf Type is the KeyWrapAlgorithm 1830 -- dhSinglePass-stdDH-sha384kdf Type is the KeyWrapAlgorithm 1831 -- dhSinglePass-stdDH-sha512kdf Type is the KeyWrapAlgorithm 1833 -- 1834 -- S/MIME Capabilities: ECDH, Single Pass, Cofactor 1835 -- 1837 -- dhSinglePass-cofactorDH-sha1kdf Type is the KeyWrapAlgorithm 1838 -- dhSinglePass-cofactorDH-sha224kdf Type is the KeyWrapAlgorithm 1839 -- dhSinglePass-cofactorDH-sha256kdf Type is the KeyWrapAlgorithm 1840 -- dhSinglePass-cofactorDH-sha384kdf Type is the KeyWrapAlgorithm 1841 -- dhSinglePass-cofactorDH-sha512kdf Type is the KeyWrapAlgorithm 1842 -- 1843 -- S/MIME Capabilities: ECMQV, Single Pass, Standard 1844 -- 1846 -- mqvSinglePass-sha1kdf Type is the KeyWrapAlgorithm 1847 -- mqvSinglePass-sha224kdf Type is the KeyWrapAlgorithm 1848 -- mqvSinglePass-sha256kdf Type is the KeyWrapAlgorithm 1849 -- mqvSinglePass-sha384kdf Type is the KeyWrapAlgorithm 1850 -- mqvSinglePass-sha512kdf Type is the KeyWrapAlgorithm 1852 END 1854 Appendix A.2 2004 ASN.1 Module 1856 SMIMEECCAlgs-2008 1857 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1858 smime(16) modules(0) TBA4 } 1860 DEFINITIONS IMPLICIT TAGS ::= 1862 BEGIN 1864 -- EXPORTS ALL 1866 IMPORTS 1868 -- From [PKI-ALG] 1870 mda-sha1, sa-ecdsaWithSHA1, sa-ecdsaWithSHA224, sa-ecdsaWithSHA256, 1871 sa-ecdsaWithSHA384, sa-ecdsaWithSHA512, id-ecPublicKey, 1872 ECDSA-Sig-Value, ECPoint, ECParameters 1873 FROM PKIXAlgIDs-2008 1874 { iso(1) identified-organization(3) dod(6) internet(1) 1875 security(5) mechanisms(5) pkix(7) id-mod(0) TBA5 } 1877 -- FROM [PKI-ASN] 1879 KEY-WRAP, SIGNATURE-ALGORITHM, DIGEST-ALGORITHM, ALGORITHM, 1880 PUBLIC-KEY, MAC-ALGORITHM, CONTENT-ENCRYPTION, KEY-AGREE 1881 FROM AlgorithmInformation 1882 { iso(1) identified-organization(3) dod(6) internet(1) 1883 security(5) mechanisms(5) pkix(7) id-mod(0) 1884 id-mod-algorithmInformation(TBA6) } 1886 -- From [PKI-ASN] 1888 mda-sha224, mda-sha256, mda-sha384, mda-sha512 1889 FROM PKIX1-PSS-OAEP-Algorithms 1890 { iso(1) identified-organization(3) dod(6) internet(1) 1891 security(5) mechanisms(5) pkix(7) id-mod(0) TBA7 } 1893 -- From [CMS] 1895 OriginatorPublicKey, UserKeyingMaterial 1896 FROM CryptographicMessageSyntax2004 1897 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1898 smime(16) modules(0) cms-2004(24) } 1900 -- From [CMS-ASN] 1902 maca-hMAC-SHA1, maca-hMAC-SHA224, maca-hMAC-SHA256, maca-hMAC-SHA384, 1903 maca-hMAC-SHA512, cea-des-ede3-cbc, kwa-3DESWrap, CBCParameter 1904 FROM CryptographicMessageSyntaxAlgorithms 1905 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1906 smime(16) modules(0) cmsalg-2001(16) } 1908 -- From [CMS-ASN] 1910 cea-aes128-CBC, cea-aes192-CBC, cea-aes256-CBC, kwa-aes128-wrap, 1911 kwa-aes192-wrap, kwa-aes256-wrap 1912 FROM CMSAesRsaesOaep 1913 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1914 smime(16) modules(0) id-mod-cms-aes(19) } 1916 -- From [CMS-ASN] 1918 cea-aes128-ccm, cea-aes192-ccm, cea-aes256-ccm, cea-aes128-gcm, 1919 cea-aes192-gcm, cea-aes256-gcm 1920 FROM CMS-AES-CCM-and-AES-GCM 1921 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1922 smime(16) modules(0) cms-aes-ccm-and-gcm(32) } 1924 ; 1925 -- Constrains the SignedData digestAlgorithms field 1926 -- Constrains the SignedData SignerInfo digestAlgorithm field 1927 -- Constrains the AuthenticatedData digestAlgorithm field 1929 -- MessageDigestAlgs DIGEST-ALGORITHM ::= { 1930 -- mda-sha1 | 1931 -- mda-sha224 | 1932 -- mda-sha256 | 1933 -- mda-sha384 | 1934 -- mda-sha512, 1935 -- ... -- Extensible 1936 -- } 1938 -- Constrains the SignedData SignerInfo signatureAlgorithm field 1940 -- SignatureAlgs SIGNATURE-ALGORITHM ::= { 1941 -- sa-ecdsaWithSHA1 | 1942 -- sa-ecdsaWithSHA224 | 1943 -- sa-ecdsaWithSHA256 | 1944 -- sa-ecdsaWithSHA384 | 1945 -- sa-ecdsaWithSHA512, 1946 -- ... -- Extensible 1947 -- } 1949 -- ECDSA Signature Value 1950 -- Contents of SignatureValue OCTET STRING 1952 -- ECDSA-Sig-Value ::= SEQUENCE { 1953 -- r INTEGER, 1954 -- s INTEGER 1955 -- } 1957 -- 1958 -- Key Agreement Algorithms 1959 -- 1961 -- Constrains the EnvelopedData RecipientInfo KeyAgreeRecipientInfo 1962 -- keyEncryption Algorithm field 1963 -- Constrains the AuthenticatedData RecipientInfo 1964 -- KeyAgreeRecipientInfo keyEncryption Algorithm field 1965 -- Constrains the AuthEnvelopedData RecipientInfo 1966 -- KeyAgreeRecipientInfo keyEncryption Algorithm field 1968 -- DH variants are not used with AuthenticatedData or 1969 -- AuthEnvelopedData 1970 KeyAgreementAlgs KEY-AGREE ::= { 1971 kaa-dhSinglePass-stdDH-sha1kdf-scheme | 1972 kaa-dhSinglePass-stdDH-sha224kdf-scheme | 1973 kaa-dhSinglePass-stdDH-sha256kdf-scheme | 1974 kaa-dhSinglePass-stdDH-sha384kdf-scheme | 1975 kaa-dhSinglePass-stdDH-sha512kdf-scheme | 1976 kaa-dhSinglePass-cofactorDH-sha1kdf-scheme | 1977 kaa-dhSinglePass-cofactorDH-sha224kdf-scheme | 1978 kaa-dhSinglePass-cofactorDH-sha256kdf-scheme | 1979 kaa-dhSinglePass-cofactorDH-sha384kdf-scheme | 1980 kaa-dhSinglePass-cofactorDH-sha512kdf-scheme | 1981 kaa-mqvSinglePass-sha1kdf-scheme | 1982 kaa-mqvSinglePass-sha224kdf-scheme | 1983 kaa-mqvSinglePass-sha256kdf-scheme | 1984 kaa-mqvSinglePass-sha384kdf-scheme | 1985 kaa-mqvSinglePass-sha512kdf-scheme, 1986 ... -- Extensible 1987 } 1989 x9-63-scheme OBJECT IDENTIFIER ::= { 1990 iso(1) identified-organization(3) tc68(133) country(16) x9(840) 1991 x9-63(63) schemes(0) } 1993 secg-scheme OBJECT IDENTIFIER ::= { 1994 iso(1) identified-organization(3) certicom(132) schemes(1) } 1996 -- 1997 -- Diffie-Hellman Single Pass, Standard, with KDFs 1998 -- 2000 -- Parameters are always present and indicate the Key Wrap Algorithm 2002 kaa-dhSinglePass-stdDH-sha1kdf-scheme KEY-AGREE ::= { 2003 IDENTIFIER dhSinglePass-stdDH-sha1kdf-scheme 2004 PARAMS TYPE KeyWrapAlgorithm ARE required 2005 UKM TYPE -- unencoded data -- IS preferredPresent 2006 SMIME CAPS { TYPE KeyWrapAlgorithm 2007 IDENTIFIED BY dhSinglePass-stdDH-sha1kdf-scheme } 2008 } 2010 dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 2011 x9-63-scheme 2 } 2013 kaa-dhSinglePass-stdDH-sha224kdf-scheme KEY-AGREE ::= { 2014 IDENTIFIER dhSinglePass-stdDH-sha224kdf-scheme 2015 PARAMS TYPE KeyWrapAlgorithm ARE required 2016 UKM TYPE -- unencoded data -- IS preferredPresent 2017 SMIME CAPS { TYPE KeyWrapAlgorithm 2018 IDENTIFIED BY dhSinglePass-stdDH-sha224kdf-scheme } 2019 } 2021 dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 2022 secg-scheme 11 0 } 2024 kaa-dhSinglePass-stdDH-sha256kdf-scheme KEY-AGREE ::= { 2025 IDENTIFIER dhSinglePass-stdDH-sha256kdf-scheme 2026 PARAMS TYPE KeyWrapAlgorithm ARE required 2027 UKM TYPE -- unencoded data -- IS preferredPresent 2028 SMIME CAPS { TYPE KeyWrapAlgorithm 2029 IDENTIFIED BY dhSinglePass-stdDH-sha256kdf-scheme } 2030 } 2032 dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 2033 secg-scheme 11 1 } 2035 kaa-dhSinglePass-stdDH-sha384kdf-scheme KEY-AGREE ::= { 2036 IDENTIFIER dhSinglePass-stdDH-sha384kdf-scheme 2037 PARAMS TYPE KeyWrapAlgorithm ARE required 2038 UKM TYPE -- unencoded data -- IS preferredPresent 2039 SMIME CAPS { TYPE KeyWrapAlgorithm 2040 IDENTIFIED BY dhSinglePass-stdDH-sha384kdf-scheme } 2041 } 2043 dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 2044 secg-scheme 11 2 } 2046 kaa-dhSinglePass-stdDH-sha512kdf-scheme KEY-AGREE ::= { 2047 IDENTIFIER dhSinglePass-stdDH-sha512kdf-scheme 2048 PARAMS TYPE KeyWrapAlgorithm ARE required 2049 UKM TYPE -- unencoded data -- IS preferredPresent 2050 SMIME CAPS { TYPE KeyWrapAlgorithm 2051 IDENTIFIED BY dhSinglePass-stdDH-sha512kdf-scheme } 2052 } 2054 dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 2055 secg-scheme 11 3 } 2057 -- 2058 -- Diffie-Hellman Single Pass, Cofactor, with KDFs 2059 -- 2061 kaa-dhSinglePass-cofactorDH-sha1kdf-scheme KEY-AGREE ::= { 2062 IDENTIFIER dhSinglePass-cofactorDH-sha1kdf-scheme 2063 PARAMS TYPE KeyWrapAlgorithm ARE required 2064 UKM TYPE -- unencoded data -- IS preferredPresent 2065 SMIME CAPS { TYPE KeyWrapAlgorithm 2066 IDENTIFIED BY dhSinglePass-cofactorDH-sha1kdf-scheme } 2067 } 2069 dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 2070 x9-63-scheme 3 } 2072 kaa-dhSinglePass-cofactorDH-sha224kdf-scheme KEY-AGREE ::= { 2073 IDENTIFIER dhSinglePass-cofactorDH-sha224kdf-scheme 2074 PARAMS TYPE KeyWrapAlgorithm ARE required 2075 UKM TYPE -- unencoded data -- IS preferredPresent 2076 SMIME CAPS { TYPE KeyWrapAlgorithm 2077 IDENTIFIED BY 2078 dhSinglePass-cofactorDH-sha224kdf-scheme } 2079 } 2081 dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 2082 secg-scheme 14 0 } 2084 kaa-dhSinglePass-cofactorDH-sha256kdf-scheme KEY-AGREE ::= { 2085 IDENTIFIER dhSinglePass-cofactorDH-sha256kdf-scheme 2086 PARAMS TYPE KeyWrapAlgorithm ARE required 2087 UKM TYPE -- unencoded data -- IS preferredPresent 2088 SMIME CAPS { TYPE KeyWrapAlgorithm 2089 IDENTIFIED BY 2090 dhSinglePass-cofactorDH-sha256kdf-scheme } 2091 } 2093 dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 2094 secg-scheme 14 1 } 2096 kaa-dhSinglePass-cofactorDH-sha384kdf-scheme KEY-AGREE ::= { 2097 IDENTIFIER dhSinglePass-cofactorDH-sha384kdf-scheme 2098 PARAMS TYPE KeyWrapAlgorithm ARE required 2099 UKM TYPE -- unencoded data -- IS preferredPresent 2100 SMIME CAPS { TYPE KeyWrapAlgorithm 2101 IDENTIFIED BY 2102 dhSinglePass-cofactorDH-sha384kdf-scheme } 2103 } 2104 dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 2105 secg-scheme 14 2 } 2107 kaa-dhSinglePass-cofactorDH-sha512kdf-scheme KEY-AGREE ::= { 2108 IDENTIFIER dhSinglePass-cofactorDH-sha512kdf-scheme 2109 PARAMS TYPE KeyWrapAlgorithm ARE required 2110 UKM TYPE -- unencoded data -- IS preferredPresent 2111 SMIME CAPS { TYPE KeyWrapAlgorithm 2112 IDENTIFIED BY 2113 dhSinglePass-cofactorDH-sha512kdf-scheme } 2114 } 2116 dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 2117 secg-scheme 14 3 } 2119 -- 2120 -- MQV Single Pass, Cofactor, with KDFs 2121 -- 2123 kaa-mqvSinglePass-sha1kdf-scheme KEY-AGREE ::= { 2124 IDENTIFIER mqvSinglePass-sha1kdf-scheme 2125 PARAMS TYPE KeyWrapAlgorithm ARE required 2126 UKM TYPE -- unencoded data -- IS preferredPresent 2127 SMIME CAPS { TYPE KeyWrapAlgorithm 2128 IDENTIFIED BY mqvSinglePass-sha1kdf-scheme } 2129 } 2131 mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= { 2132 x9-63-scheme 16 } 2134 kaa-mqvSinglePass-sha224kdf-scheme KEY-AGREE ::= { 2135 IDENTIFIER mqvSinglePass-sha224kdf-scheme 2136 PARAMS TYPE KeyWrapAlgorithm ARE required 2137 UKM TYPE -- unencoded data -- IS preferredPresent 2138 SMIME CAPS { TYPE KeyWrapAlgorithm 2139 IDENTIFIED BY mqvSinglePass-sha224kdf-scheme } 2140 } 2142 mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= { 2143 secg-scheme 15 0 } 2145 kaa-mqvSinglePass-sha256kdf-scheme KEY-AGREE ::= { 2146 IDENTIFIER mqvSinglePass-sha256kdf-scheme 2147 PARAMS TYPE KeyWrapAlgorithm ARE required 2148 UKM TYPE -- unencoded data -- IS preferredPresent 2149 SMIME CAPS { TYPE KeyWrapAlgorithm 2150 IDENTIFIED BY mqvSinglePass-sha256kdf-scheme } 2151 } 2153 mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= { 2154 secg-scheme 15 1 } 2156 kaa-mqvSinglePass-sha384kdf-scheme KEY-AGREE ::= { 2157 IDENTIFIER mqvSinglePass-sha384kdf-scheme 2158 PARAMS TYPE KeyWrapAlgorithm ARE required 2159 UKM TYPE -- unencoded data -- IS preferredPresent 2160 SMIME CAPS { TYPE KeyWrapAlgorithm 2161 IDENTIFIED BY mqvSinglePass-sha384kdf-scheme } 2162 } 2164 mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= { 2165 secg-scheme 15 2 } 2167 kaa-mqvSinglePass-sha512kdf-scheme KEY-AGREE ::= { 2168 IDENTIFIER mqvSinglePass-sha512kdf-scheme 2169 PARAMS TYPE KeyWrapAlgorithm ARE required 2170 UKM TYPE -- unencoded data -- IS preferredPresent 2171 SMIME CAPS { TYPE KeyWrapAlgorithm 2172 IDENTIFIED BY mqvSinglePass-sha512kdf-scheme } 2173 } 2175 mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= { 2176 secg-scheme 15 3 } 2178 -- 2179 -- Key Wrap Algorithms 2180 -- 2182 KeyWrapAlgorithm ::= KeyWrapAlgs 2184 KeyWrapAlgs KEY-WRAP ::= { 2185 kwa-3des | 2186 kwa-aes128 | 2187 kwa-aes192 | 2188 kwa-aes256, 2189 ... -- Extensible 2190 } 2191 -- 2192 -- Content Encryption Algorithms 2193 -- 2195 -- Constrains the EnvelopedData EncryptedContentInfo encryptedContent 2196 -- field and the AuthEnvelopedData EncryptedContentInfo 2197 -- contentEncryptionAlgorithm field 2199 -- ContentEncryptionAlgorithms CONTENT-ENCRYPTION ::= { 2200 -- cea-des-ede3-cbc | 2201 -- cea-aes128-cbc | 2202 -- cea-aes192-cbc | 2203 -- cea-aes256-cbc | 2204 -- cea-aes128-ccm | 2205 -- cea-aes192-ccm | 2206 -- cea-aes256-ccm | 2207 -- cea-aes128-gcm | 2208 -- cea-aes192-gcm | 2209 -- cea-aes256-gcm, 2210 -- ... -- Extensible 2211 -- } 2213 -- des-ede3-cbc and aes*-cbc are used with EnvelopedData and 2214 -- EncryptedData 2215 -- aes*-ccm are used with AuthEnvelopedData 2216 -- aes*-gcm are used with AuthEnvelopedData 2217 -- (where * is 128, 192, and 256) 2219 -- 2220 -- Message Authentication Code Algorithms 2221 -- 2223 -- Constrains the AuthenticatedData 2224 -- MessageAuthenticationCodeAlgorithm field 2225 -- 2227 -- MessageAuthenticationCodeAlgorithms MAC-ALGORITHM ::= { 2228 -- maca-hMAC-SHA1 | 2229 -- maca-hMAC-SHA224 | 2230 -- maca-hMAC-SHA256 | 2231 -- maca-hMAC-SHA384 | 2232 -- maca-hMAC-SHA512, 2233 -- ... -- Extensible 2234 -- } 2235 -- 2236 -- Originator Public Key Algorithms 2237 -- 2239 -- Constraints on KeyAgreeRecipientInfo OriginatorIdentifierOrKey 2240 -- OriginatorPublicKey algorithm field 2242 -- PARAMS are NULL 2244 OriginatorPKAlgorithms PUBLIC-KEY ::= { 2245 opka-ec, 2246 ... -- Extensible 2247 } 2249 opka-ec PUBLIC-KEY ::={ 2250 IDENTIFIER id-ecPublicKey 2251 KEY ECPoint 2252 PARAMS TYPE CHOICE { n NULL, p ECParameters } ARE preferredAbsent 2253 } 2255 -- Format for both ephemeral and static public keys 2257 -- ECPoint ::= OCTET STRING 2259 -- ECParameters ::= CHOICE { 2260 -- namedCurve CURVE.&id({NamedCurve}) 2261 -- commented out in [PKI-ALG] implicitCurve NULL 2262 -- commented out in [PKI-ALG] specifiedCurve SpecifiedECDomain 2263 -- commented out in [PKI-ALG] ... Extensible 2264 -- } 2265 -- implicitCurve and specifiedCurve MUST NOT be used in PKIX. 2266 -- Details for SpecifiedECDomain can be found in [X9.62]. 2267 -- Any future additions to this CHOICE should be coordinated 2268 -- with ANSI X.9. 2270 -- Format of KeyAgreeRecipientInfo ukm field when used with 2271 -- ECMQV 2273 MQVuserKeyingMaterial ::= SEQUENCE { 2274 ephemeralPublicKey OriginatorPublicKey, 2275 addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL 2276 } 2277 -- 'SharedInfo' for input to KDF when using ECDH and ECMQV with 2278 -- EnvelopedData, AuthenticatedData, or AuthEnvelopedData 2280 ECC-CMS-SharedInfo ::= SEQUENCE { 2281 keyInfo AlgorithmIdentifier { KeyWrapAlgorithm }, 2282 entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL, 2283 suppPubInfo [2] EXPLICIT OCTET STRING 2284 } 2286 END 2288 Appendix B Changes since RFC 3278 2290 The following summarizes the changes: 2292 - Abstract: The basis of the document was changed to refer to NIST 2293 FIPS 186-3 and SP800-56A. However, to maintain backwards 2294 compatibility the Key Derivation Function from ANSI/SEC1 is 2295 retained. 2297 - Section 1: A bullet was added to address AuthEnvelopedData. 2299 - Section 2.1: A sentence was added to indicate FIPS180-3 is used 2300 with ECDSA. Replaced reference to ANSI X9.62 with FIPS186-3. 2302 - Section 2.1.1: The permitted digest algorithms were expanded from 2303 SHA-1 to SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. 2305 - Section 2.1.2 and 2.1.3: The bullet addressing integer "e" was 2306 deleted. 2308 - Section 3: Added explanation of why static-static ECDH is not 2309 included. 2311 - Section 3.1: The reference for DH was changed from RFC 3852 to 2312 RFC 3370. Provided text to indicate fields of EnvelopedData are 2313 as in CMS. 2315 - Section 3.1.1: The text was updated to include description of all 2316 KeyAgreeRecipientInfo fields. Parameters for id-ecPublicKey 2317 field changed from NULL to absent or ECParameter. Additional 2318 information about ukm was added. 2320 - Section 3.2: The sentence describing the advantages of 1-Pass 2321 ECMQV was rewritten. 2323 - Section 3.2.1: The text was updated to include description of all 2324 fields. Parameters for id-ecPublicKey field changed from NULL 2325 to absent or ECPoint. 2327 - Sections 3.2.2 and 4.1.2: The re-use of ephemeral keys paragraph 2328 was reworded. 2330 - Section 4.1: The sentences describing the advantages of 1-Pass 2331 ECMQV was moved to Section 4. 2333 - Section 4.1.2: The note about the attack was moved to Section 4. 2335 - Section 4.2: This section was added to address AuthEnvelopedData 2336 with ECMQV. 2338 - Section 5: This section was moved to Section 8. The 1st 2339 paragraph was modified to recommend both SignedData and 2340 EnvelopedData. The requirements were updated for hash 2341 algorithms and recommendations for matching curves and hash 2342 algorithms. Also the requirements were expanded to indicate 2343 which ECDH and ECMQV variants, key wrap algorithms, and content 2344 encryption algorithms are required for each of the content types 2345 used in this document. The permitted digest algorithms used in 2346 key derivations functions (KDFs) were expanded from SHA-1 to 2347 SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. 2349 - Section 6 (formerly 7): This section was updated to allow for 2350 SMIMECapabilities to be present in certificates. The S/MIME 2351 capabilities for ECDSA with SHA-224, SHA-256, SHA-384, and SHA- 2352 512 were added to the list of S/MIME Capabilities. Also updated 2353 to include S/MIME capabilities for ECDH and ECMQV using the SHA- 2354 224, SHA-256, SHA-384, and SHA-512 algorithms as the KDF. 2356 - Section 7.1 (formerly 8.1): Added sub-sections for digest, 2357 signature, originator public key, key agreement, content 2358 encryption, key wrap, and message authentication code 2359 algorithms. Pointed to algorithms and parameters in appropriate 2360 documents for: SHA-224, SHA-256, SHA-384, and SHA-512 as well as 2361 SHA-224, SHA-256, SHA-384, and SHA-512 with ECDSA. Also added 2362 algorithm identifiers for ECDH std, ECDH cofactor, and ECMQV 2363 with SHA-224, SHA-256, SHA-384, and SHA-512 algorithms as the 2364 KDF. Changed id-ecPublicKey parameters to be absent, NULL, or 2365 ECParameters, and if present the originator's ECParameters must 2366 match the recipient's ECParameters. 2368 - Section 7.2 (formerly 8.2): Updated to include AuthEnvelopedData. 2369 Also, added text to address support requirement for compressed, 2370 uncompressed, and hybrid keys, changed pointers from ANSI X9.61 2371 to PKIX (where ECDSA-Sig-Value is imported), changed pointers 2372 from SECG to NIST specs, and updated example of suppPubInfo to 2373 be AES-256. keyInfo's parameters changed from NULL to any 2374 associated parameters (AES wraps have absent parameters). 2376 - Section 9: Replaced text, which was a summary paragraph, with an 2377 updated security considerations section. Paragraph referring to 2378 definitions of SHA-224, SHA-256, SHA-384, and SHA-512 is 2379 deleted. 2381 - Updated references. 2383 - Added ASN.1 modules. 2385 - Updated acknowledgements section. 2387 Acknowledgements 2389 The methods described in this document are based on work done by the 2390 ANSI X9F1 working group. The authors wish to extend their thanks to 2391 ANSI X9F1 for their assistance. The authors also wish to thank Peter 2392 de Rooij for his patient assistance. The technical comments of 2393 Francois Rousseau were valuable contributions. 2395 Many thanks go out to the other authors of RFC 3278: Simon Blake- 2396 Wilson and Paul Lambert. Without RFC 3278 this version wouldn't 2397 exist. 2399 The authors also wish to thank Alfred Hoenes, Paul Hoffman, Russ 2400 Housley, and Jim Schaad for their valuable input. 2402 Author's Addresses 2404 Sean Turner 2406 IECA, Inc. 2407 3057 Nutley Street, Suite 106 2408 Fairfax, VA 22031 2409 USA 2411 Email: turners@ieca.com 2413 Daniel R. L. Brown 2415 Certicom Corp 2416 5520 Explorer Drive #400 2417 Mississauga, ON L4W 5L1 2418 CANADA 2420 Email: dbrown@certicom.com