idnits 2.17.00 (12 Aug 2021) /tmp/idnits60506/draft-ietf-smime-3278bis-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2425. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2436. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2443. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2449. 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 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 (December 11, 2008) is 4908 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 2271 -- Looks like a reference, but probably isn't: '2' on line 2272 ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) == Outdated reference: draft-ietf-smime-new-asn1 has been published as RFC 5911 == Outdated reference: draft-ietf-smime-sha2 has been published as RFC 5754 == Outdated reference: draft-ietf-smime-3851bis has been published as RFC 5751 == Outdated reference: draft-ietf-pkix-ecc-subpubkeyinfo has been published as RFC 5480 -- Obsolete informational reference (is this intentional?): RFC 3278 (ref. 'CMS-ECC') (Obsoleted by RFC 5753) == Outdated reference: draft-ietf-pkix-new-asn1 has been published as RFC 5912 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 10 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 December 11, 2008 4 Obsoletes: 3278 (once approved) 5 Expires: June 11, 2009 7 Use of Elliptic Curve Cryptography (ECC) Algorithms 8 in Cryptographic Message Syntax (CMS) 9 draft-ietf-smime-3278bis-04.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on June 11, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document describes how to use Elliptic Curve Cryptography (ECC) 43 public-key algorithms in the Cryptographic Message Syntax (CMS). The 44 ECC algorithms support the creation of digital signatures and the 45 exchange of keys to encrypt or authenticate content. The definition 46 of the algorithm processing is based on the NIST FIPS 186-3 for 47 digital signature, NIST SP800-56A and SEC1 for key agreement, RFC 48 3370 and RFC 3565 for key wrap and content encryption, NIST FIPS 180- 49 3 for message digest, SEC1 for key derivation, and RFC 2104 and RFC 50 4231 for message authentication code standards. This document 51 obsoletes RFC 3278. 53 Discussion 55 This draft is being discussed on the 'ietf-smime' mailing list. To 56 subscribe, send a message to ietf-smime-request@imc.org with the 57 single word subscribe in the body of the message. There is a Web site 58 for the mailing list at . 60 Table of Contents 62 1. Introduction...................................................3 63 1.1. Requirements Terminology..................................3 64 2. SignedData using ECC...........................................3 65 2.1. SignedData using ECDSA....................................3 66 3. EnvelopedData using ECC Algorithms.............................5 67 3.1. EnvelopedData using (ephemeral-static) ECDH...............5 68 3.2. EnvelopedData using 1-Pass ECMQV..........................7 69 4. AuthenticatedData and AuthEnvelopedData using ECC.............10 70 4.1. AuthenticatedData using 1-pass ECMQV.....................10 71 4.2. AuthEnvelopedData using 1-pass ECMQV.....................11 72 5. Certificates using ECC........................................12 73 6. SMIMECapabilities Attribute and ECC...........................12 74 7. ASN.1 Syntax..................................................20 75 7.1. Algorithm Identifiers....................................20 76 7.2. Other Syntax.............................................24 77 8. Recommended Algorithms and Elliptic Curves....................25 78 9. Security Considerations.......................................28 79 10. IANA Considerations..........................................33 80 11. References...................................................33 81 11.1. Normative...............................................33 82 11.2. Informative.............................................35 83 Appendix A ASN.1 Modules.........................................36 84 Appendix A.1 1988 ASN.1 Module................................36 85 Appendix A.2 2004 ASN.1 Module................................43 86 Appendix B Changes since RFC 3278................................53 87 Acknowledgements.................................................56 88 Author's Addresses...............................................56 90 1. Introduction 92 The Cryptographic Message Syntax (CMS) is cryptographic algorithm 93 independent. This specification defines a profile for the use of 94 Elliptic Curve Cryptography (ECC) public key algorithms in the CMS. 95 The ECC algorithms are incorporated into the following CMS content 96 types: 98 - 'SignedData' to support ECC-based digital signature methods 99 (ECDSA) to sign content; 101 - 'EnvelopedData' to support ECC-based public-key agreement 102 methods (ECDH and ECMQV) to generate pairwise key-encryption 103 keys to encrypt content-encryption keys used for content 104 encryption; 106 - 'AuthenticatedData' to support ECC-based public-key agreement 107 methods (ECMQV) to generate pairwise key-encryption keys to 108 encrypt message-authentication keys used for content 109 authentication and integrity; and, 111 - 'AuthEnvelopedData' to support ECC-based public-key agreement 112 methods (ECMQV) to generate pairwise key-encryption keys to 113 encrypt message-authentication and content-encryption keys used 114 for content authentication, integrity, and encryption. 116 Certification of EC public keys is also described to provide public- 117 key distribution in support of the specified techniques. 119 The document will obsolete [CMS-ECC]. The technical changes 120 performed since RFC 3278 are detailed in Appendix B. 122 1.1. Requirements Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [MUST]. 128 2. SignedData using ECC 130 This section describes how to use ECC algorithms with the CMS 131 SignedData format to sign data. 133 2.1. SignedData using ECDSA 135 This section describes how to use the Elliptic Curve Digital 136 Signature Algorithm (ECDSA) with SignedData. ECDSA is specified in 138 [FIPS186-3]. The method is the elliptic curve analog of the Digital 139 Signature Algorithm (DSA) [FIPS186-3]. ECDSA is used with the Secure 140 Hash Algorithm (SHA) [FIPS180-3]. 142 In an implementation that uses ECDSA with CMS SignedData, the 143 following techniques and formats MUST be used. 145 2.1.1. Fields of the SignedData 147 When using ECDSA with SignedData, the fields of SignerInfo are as in 148 [CMS], but with the following restrictions: 150 - digestAlgorithm MUST contain the algorithm identifier of the hash 151 algorithm (see Section 7.1.1) which MUST be one of the 152 following: id-sha1, id-sha224, id-sha256, id-sha384, or id- 153 sha512. 155 - signatureAlgorithm contains the signature algorithm identifier 156 (see Section 7.1.3): ecdsa-with-SHA1, ecdsa-with-SHA224, ecdsa- 157 with-SHA256, ecdsa-with-SHA384, or ecdsa-with-SHA512. 159 - signature MUST contain the DER encoding (as an octet string) of a 160 value of the ASN.1 type ECDSA-Sig-Value (see Section 7.2). 162 When using ECDSA, the SignedData certificates field MAY include the 163 certificate(s) for the EC public key(s) used in the generation of the 164 ECDSA signatures in SignedData. ECC certificates are discussed in 165 Section 5. 167 2.1.2. Actions of the sending agent 169 When using ECDSA with SignedData, the sending agent uses the message 170 digest calculation process and signature generation process for 171 SignedData that are specified in [CMS]. To sign data, the sending 172 agent uses the signature method specified in [FIPS186-3]. 174 The sending agent encodes the resulting signature using the 175 ECDSA-Sig-Value syntax (see Section 7.2) and places it in the 176 SignerInfo signature field. 178 2.1.3. Actions of the receiving agent 180 When using ECDSA with SignedData, the receiving agent uses the 181 message digest calculation process and signature verification process 182 for SignedData that are specified in [CMS]. To verify SignedData, 183 the receiving agent uses the signature verification method specified 184 in [FIPS186-3]. 186 In order to verify the signature, the receiving agent retrieves the 187 integers r and s from the SignerInfo signature field of the received 188 message. 190 3. EnvelopedData using ECC Algorithms 192 This section describes how to use ECC algorithms with the CMS 193 EnvelopedData format. 195 This document does not specify the static-static ECDH, method C(0,2, 196 ECC CDH) from [SP800-56A]. Static-static ECDH is analogous to 197 static-static DH, which is specified in [CMS-ALG]. Ephemeral-static 198 ECDH and 1-Pass ECMQV were specified because they provide better 199 security due to the originator's ephemeral contribution to the key 200 agreement scheme. 202 3.1. EnvelopedData using (ephemeral-static) ECDH 204 This section describes how to use the ephemeral-static Elliptic Curve 205 Diffie-Hellman (ECDH) key agreement algorithm with EnvelopedData, 206 method C(1, 1, ECC CDH) from [SP800-56A] and ECDH with the standard 207 primitive from Section 3.3.1 [SEC1]. Ephemeral-static ECDH is the 208 elliptic curve analog of the ephemeral-static Diffie-Hellman key 209 agreement algorithm specified jointly in the documents [CMS-ALG] and 210 [CMS-DH]. 212 If an implementation uses ECDH with CMS EnvelopedData, then the 213 following techniques and formats MUST be used. 215 The fields of EnvelopedData are as in [CMS], as ECDH is a key 216 agreement algorithm the RecipientInfo kari choice is used. 218 3.1.1. Fields of KeyAgreeRecipientInfo 220 When using ephemeral-static ECDH with EnvelopedData, the fields of 221 KeyAgreeRecipientInfo are as follows: 223 - version MUST be 3. 225 - originator MUST be the alternative originatorKey. The 226 originatorKey algorithm field MUST contain the id-ecPublicKey 227 object identifier (see Section 7.1.3). The parameters 228 associated with id-ecPublicKey MUST be absent or ECParameters. 229 NOTE: The previous version of this document required NULL to be 230 present, support for this legacy form is OPTIONAL. The 231 originatorKey publicKey field MUST contain the value of the 232 ASN.1 type ECPoint (see Section 7.2), which represents the 233 sending agent's ephemeral EC public key. The ECPoint in 234 uncompressed form MUST be supported. 236 - ukm MAY be present or absent. However, message originators 237 SHOULD include the ukm. As specified in RFC 3852 [CMS], 238 implementations MUST support ukm message recipient processing, 239 so interoperability is not a concern if the ukm is present or 240 absent. The ukm is placed in the entityUInfo field of the ECC- 241 CMS-SharedInfo structure. When present, the ukm is used to 242 ensure that a different key-encryption key is generated, even 243 when the ephemeral private key is improperly used more than 244 once, by using the ECC-CMS-SharedInfo as an input to the key 245 derivation function (see Section 7.2). 247 - keyEncryptionAlgorithm MUST contain the key encryption algorithm, 248 which in this case is a key agreement algorithm, object 249 identifier (see Section 7.1.4). The parameters field contains 250 KeyWrapAlgorithm. The KeyWrapAlgorithm is the algorithm 251 identifier that indicates the symmetric encryption algorithm 252 used to encrypt the content-encryption key (CEK) with the key- 253 encryption key (KEK) and any associated parameters (see Section 254 7.1.5). Algorithm requirements are found in Section 8. 256 - recipientEncryptedKeys contains an identifier and an encrypted 257 key for each recipient. The RecipientEncryptedKey 258 KeyAgreeRecipientIdentifier MUST contain either the 259 issuerAndSerialNumber identifying the recipient's certificate or 260 the RecipientKeyIdentifier containing the subject key identifier 261 from the recipient's certificate. In both cases, the 262 recipient's certificate contains the recipient's static ECDH 263 public key. RecipientEncryptedKey EncryptedKey MUST contain the 264 content-encryption key encrypted with the ephemeral-static, 265 ECDH-generated pairwise key-encryption key using the algorithm 266 specified by the KeyWrapAlgorithm. 268 3.1.2. Actions of the sending agent 270 When using ephemeral-static ECDH with EnvelopedData, the sending 271 agent first obtains the recipient's EC public key and domain 272 parameters (e.g. from the recipient's certificate). The sending 273 agent then determines an integer "keydatalen", which is the 274 KeyWrapAlgorithm symmetric key-size in bits, and also a bit string 275 "SharedInfo", which is the DER encoding of ECC-CMS-SharedInfo (see 276 Section 7.2). The sending agent then performs the key deployment and 277 the key agreement operation of the Elliptic Curve Diffie-Hellman 278 Scheme specified in [SP800-56A] or [SEC1]; in either case, use the 279 KDF defined in Section 3.6.1 of [SEC1] with the has algorithm 280 identified in the key agreement algorithm. As a result the sending 281 agent obtains: 283 - an ephemeral public key, which is represented as a value of the 284 type ECPoint (see Section 7.2), encapsulated in a bit string and 285 placed in the KeyAgreeRecipientInfo originator field, and 287 - a shared secret bit string "K", which is used as the pairwise 288 key-encryption key for that recipient, as specified in [CMS]. 290 In a single message, if there are multiple layers for a recipient, 291 then the ephemeral public key can be reused by the originator for 292 that recipient in each of the different layers. 294 3.1.3. Actions of the receiving agent 296 When using ephemeral-static ECDH with EnvelopedData, the receiving 297 agent determines the bit string "SharedInfo", which is the DER 298 encoding of ECC-CMS-SharedInfo (see Section 7.2), and the integer 299 "keydatalen" from the key-size, in bits, of the KeyWrapAlgorithm. The 300 receiving agent retrieves the ephemeral EC public key from the bit 301 string KeyAgreeRecipientInfo originator, with a value of the type 302 ECPoint (see Section 7.2) encapsulated as a bit string, and if 303 present, originally supplied additional user key material from the 304 ukm field. The receiving agent performs the key agreement operation 305 of the Elliptic Curve Diffie-Hellman Scheme specified in [SP800-56A] 306 or [SEC1]; in either case, use the KDF defined in Section 3.6.1 of 307 [SEC1]. As a result, the receiving agent obtains a shared secret bit 308 string "K", which is used as the pairwise key-encryption key to 309 unwrap the CEK. 311 3.2. EnvelopedData using 1-Pass ECMQV 313 This section describes how to use the 1-Pass elliptic curve MQV 314 (ECMQV) key agreement algorithm with EnvelopedData, method 315 C(1, 2, ECC MQV) from [SP800-56A]. Like the KEA algorithm [CMS-KEA], 316 1-Pass ECMQV uses three key pairs: an ephemeral key pair, a static 317 key pair of the sending agent, and a static key pair of the receiving 318 agent. Using an algorithm with the sender static key pair allows for 319 knowledge of the message creator, this means that authentication can, 320 in some circumstances, be obtained for AuthEnvelopedData and 321 AuthenticatedData. This means that 1-Pass ECMQV can be a common 322 algorithm for EnvelopedData, AuthenticatedData and AuthEnvelopedData, 323 while ECDH can only be used in EnvelopedData. 325 If an implementation uses 1-Pass ECMQV with CMS EnvelopedData, then 326 the following techniques and formats MUST be used. 328 The fields of EnvelopedData are as in [CMS], as 1-Pass ECMQV is a key 329 agreement algorithm the RecipientInfo kari choice is used. When 330 using 1-Pass ECMQV, the EnvelopedData originatorInfo field MAY 331 include the certificate(s) for the EC public key(s) used in the 332 formation of the pairwise key. ECC certificates are discussed in 333 Section 5. 335 3.2.1. Fields of KeyAgreeRecipientInfo 337 When using 1-Pass ECMQV with EnvelopedData, the fields of 338 KeyAgreeRecipientInfo are: 340 - version MUST be 3. 342 - originator identifies the static EC public key of the sender. It 343 SHOULD be one of the alternatives, issuerAndSerialNumber or 344 subjectKeyIdentifier, and point to one of the sending agent's 345 certificates. 347 - ukm MUST be present. The ukm field is an octet string which MUST 348 contain the DER encoding of the type MQVuserKeyingMaterial (see 349 Section 7.2). The MQVuserKeyingMaterial ephemeralPublicKey 350 algorithm field MUST contain the id-ecPublicKey object 351 identifier (see Section 7.1.3). The parameters associated with 352 id-ecPublicKey MUST be absent or ECParameters. NOTE: The 353 previous version of this document required NULL to be present, 354 support for this legacy form is OPTIONAL. The 355 MQVuserKeyingMaterial ephemeralPublicKey publicKey field MUST 356 contain the DER-encoding of the ASN.1 type ECPoint (see Section 357 7.2) representing the sending agent's ephemeral EC public key. 358 The MQVuserKeyingMaterial addedukm field, if present, contains 359 additional user keying material from the sending agent. 361 - keyEncryptionAlgorithm MUST contain the key encryption algorithm, 362 which in this case is a key agreement algorithm, object 363 identifier (see Section 7.1.4). The parameters field contains 364 KeyWrapAlgorithm. The KeyWrapAlgorithm indicates the symmetric 365 encryption algorithm used to encrypt the CEK with the KEK 366 generated using the 1-Pass ECMQV algorithm and any associated 367 parameters (see Section 7.1.5). Algorithm requirements are 368 found in Section 8. 370 - recipientEncryptedKeys contains an identifier and an encrypted 371 key for each recipient. The RecipientEncryptedKey 372 KeyAgreeRecipientIdentifier MUST contain either the 373 issuerAndSerialNumber identifying the recipient's certificate or 374 the RecipientKeyIdentifier containing the subject key identifier 375 from the recipient's certificate. In both cases, the 376 recipient's certificate contains the recipient's static ECMQV 377 public key. RecipientEncryptedKey EncryptedKey MUST contain the 378 content-encryption key encrypted with the 1-Pass ECMQV-generated 379 pairwise key-encryption key using the algorithm specified by the 380 KeyWrapAlgorithm. 382 3.2.2. Actions of the sending agent 384 When using 1-Pass ECMQV with EnvelopedData, the sending agent first 385 obtains the recipient's EC public key and domain parameters (e.g. 386 from the recipient's certificate), and checks that the domain 387 parameters are the same as the sender's domain parameters. The 388 sending agent then determines an integer "keydatalen", which is the 389 KeyWrapAlgorithm symmetric key-size in bits, and also a bit string 390 "SharedInfo", which is the DER encoding of ECC-CMS-SharedInfo (see 391 Section 7.2). The sending agent then performs the key deployment and 392 key agreement operations of the Elliptic Curve MQV Scheme specified 393 in [SP800-56A], but uses the KDF defined in Section 3.6.1 of [SEC1]. 394 As a result, the sending agent obtains: 396 - an ephemeral public key, which is represented as a value of type 397 ECPoint (see Section 7.2), encapsulated in a bit string, placed 398 in an MQVuserKeyingMaterial ephemeralPublicKey publicKey field 399 (see Section 7.2), and 401 - a shared secret bit string "K", which is used as the pairwise 402 key-encryption key for that recipient, as specified in [CMS]. 404 In a single message, if there are multiple layers for a recipient, 405 then the ephemeral public key can be reused by the originator for 406 that recipient in each of the different layers. 408 3.2.3. Actions of the receiving agent 410 When using 1-Pass ECMQV with EnvelopedData, the receiving agent 411 determines the bit string "SharedInfo", which is the DER encoding of 412 ECC-CMS-SharedInfo (see Section 7.2), and the integer "keydatalen" 413 from the key-size, in bits, of the KeyWrapAlgorithm. The receiving 414 agent then retrieves the static and ephemeral EC public keys of the 415 originator, from the originator and ukm fields as described in 416 Section 3.2.1, and its static EC public key identified in the rid 417 field and checks that the originator's domain parameters are the same 418 as the recipient's domain parameters. The receiving agent then 419 performs the key agreement operation of the Elliptic Curve MQV Scheme 420 [SP800-56A], but uses the KDF defined in Section 3.6.1 of [SEC1]. As 421 a result, the receiving agent obtains a shared secret bit string "K" 422 which is used as the pairwise key-encryption key to unwrap the CEK. 424 4. AuthenticatedData and AuthEnvelopedData using ECC 426 This section describes how to use ECC algorithms with the CMS 427 AuthenticatedData format. AuthenticatedData lacks non-repudiation, 428 and so in some instances is preferable to SignedData. (For example, 429 the sending agent might not want the message to be authenticated when 430 forwarded.) 432 This section also describes how to use ECC algorithms with the CMS 433 AuthEnvelopedData format [CMS-AUTHENV]. AuthEnvelopedData supports 434 authentication and encryption, and in some instances is preferable to 435 signing and then encrypting data. 437 For both AuthenticatedData and AuthEnvelopedData, data origin 438 authentication with 1-Pass ECMQV can only be provided when there is 439 one and only one recipient. When there are multiple recipients, an 440 attack is possible where one recipient modifies the content without 441 other recipients noticing [BON]. A sending agent who is concerned 442 with such an attack SHOULD use a separate AuthenticatedData or 443 AuthEnvelopedData for each recipient. 445 Using an algorithm with the sender static key pair allows for 446 knowledge of the message creator; this means that authentication can, 447 in some circumstances, be obtained for AuthEnvelopedData and 448 AuthenticatedData. This means that 1-Pass ECMQV can be a common 449 algorithm for EnvelopedData, AuthenticatedData, and AuthEnvelopedData 450 while ECDH can only be used in EnvelopedData. 452 4.1. AuthenticatedData using 1-pass ECMQV 454 This section describes how to use the 1-Pass elliptic curve MQV 455 (ECMQV) key agreement algorithm with AuthenticatedData. ECMQV is 456 method C(1, 2, ECC MQV) from [SP800-56A]. 458 When using ECMQV with AuthenticatedData, the fields of 459 AuthenticatedData are as in [CMS], but with the following 460 restrictions: 462 - macAlgorithm MUST contain the algorithm identifier of the message 463 authentication code (MAC) algorithm (see Section 7.1.7) which 464 MUST be one of the following: hmac-SHA1, id-hmacWITHSHA224, id- 465 hmacWITHSHA256, id-hmacWITHSHA384, or id-hmacWITHSHA512. 467 - digestAlgorithm MUST contain the algorithm identifier of the hash 468 algorithm (see Section 7.1.1) which MUST be one of the 469 following: id-sha1, id-sha224, id-sha256, id-sha384, and id- 470 sha512. 472 As 1-Pass ECMQV is a key agreement algorithm, the RecipientInfo kari 473 choice is used in the AuthenticatedData. When using 1-Pass ECMQV, 474 the AuthenticatedData originatorInfo field MAY include the 475 certificate(s) for the EC public key(s) used in the formation of the 476 pairwise key. ECC certificates are discussed in Section 5. 478 4.1.1. Fields of the KeyAgreeRecipientInfo 480 The AuthenticatedData KeyAgreeRecipientInfo fields are used in the 481 same manner as the fields for the corresponding EnvelopedData 482 KeyAgreeRecipientInfo fields of Section 3.2.1 of this document. 484 4.1.2. Actions of the sending agent 486 The sending agent uses the same actions as for EnvelopedData with 487 1-Pass ECMQV, as specified in Section 3.2.2 of this document. 489 In a single message, if there are multiple layers for a recipient, 490 then the ephemeral public key can be reused by the originator for 491 that recipient in each of the different layers. 493 4.1.3. Actions of the receiving agent 495 The receiving agent uses the same actions as for EnvelopedData with 496 1-Pass ECMQV, as specified in Section 3.2.3 of this document. 498 4.2. AuthEnvelopedData using 1-pass ECMQV 500 This section describes how to use the 1-Pass elliptic curve MQV 501 (ECMQV) key agreement algorithm with AuthEnvelopedData. ECMQV is 502 method C(1, 2, ECC MQV) from [SP800-56A]. 504 When using ECMQV with AuthEnvelopedData, the fields of 505 AuthenticatedData are as in [CMS-AUTHENV]. 507 As 1-Pass ECMQV is a key agreement algorithm, the RecipientInfo kari 508 choice is used. When using 1-Pass ECMQV, the AuthEnvelopedData 509 originatorInfo field MAY include the certificate(s) for the EC public 510 key used in the formation of the pairwise key. ECC certificates are 511 discussed in Section 5. 513 4.2.1. Fields of the KeyAgreeRecipientInfo 515 The AuthEnvelopedData KeyAgreeRecipientInfo fields are used in the 516 same manner as the fields for the corresponding EnvelopedData 517 KeyAgreeRecipientInfo fields of Section 3.2.1 of this document. 519 4.2.2. Actions of the sending agent 521 The sending agent uses the same actions as for EnvelopedData with 1- 522 Pass ECMQV, as specified in Section 3.2.2 of this document. 524 In a single message, if there are multiple layers for a recipient, 525 then the ephemeral public key can be reused by the originator for 526 that recipient in each of the different layers. 528 4.2.3. Actions of the receiving agent 530 The receiving agent uses the same actions as for EnvelopedData with 531 1-Pass ECMQV, as specified in Section 3.2.3 of this document. 533 5. Certificates using ECC 535 Internet X.509 certificates [PKI] can be used in conjunction with 536 this specification to distribute agents' public keys. The use of ECC 537 algorithms and keys within X.509 certificates is specified in [PKI- 538 ALG]. 540 6. SMIMECapabilities Attribute and ECC 542 A sending agent MAY announce to receiving agents that it supports one 543 or more of the ECC algorithms specified in this document by using the 544 SMIMECapabilities signed attribute [MSG] in either a signed message 545 or a certificate [CERTCAP]. 547 The SMIMECapabilities attribute value indicates support for one of 548 the ECDSA signature algorithms in a SEQUENCE with the capabilityID 549 field containing the object identifier ecdsa-with-SHA1 with NULL 550 parameters and ecdsa-with-SHA1* (where * is 224, 256, 384, or 512) 551 with absent parameters. The DER encodings are: 553 ecdsa-with-SHA1: 30 0b 06 07 2a 86 48 ce 3d 04 01 05 00 555 ecdsa-with-SHA224: 30 0a 06 08 2a 86 48 ce 3d 04 03 01 557 ecdsa-with-SHA256: 30 0a 06 08 2a 86 48 ce 3d 04 03 02 559 ecdsa-with-SHA384: 30 0a 06 08 2a 86 48 ce 3d 04 03 03 561 ecdsa-with-SHA512: 30 0a 06 08 2a 86 48 ce 3d 04 03 04 563 NOTE: The S/MIMECapabilities attribute indicates that parameters for 564 ECDSA with SHA-1 are NULL, however, the parameters are absent when 565 used to generate a digital signature. 567 The SMIMECapabilities attribute value indicates support for 568 a) the standard ECDH key agreement algorithm, 569 b) the cofactor ECDH key agreement algorithm, or 570 c) the 1-Pass ECMQV key agreement algorithm 571 is a SEQUENCE with the capabilityID field containing the object 572 identifier 573 a) dhSinglePass-stdDH-sha*kdf-scheme, 574 b) dhSinglePass-cofactorDH-sha*kdf-scheme, or 575 c) mqvSinglePass-sha*kdf-scheme 576 respectively (where * is 1, 224, 256, 384, or 512) with the 577 parameters present. The parameters indicate the supported key- 578 encryption algorithm with the KeyWrapAlgorithm algorithm identifier. 580 The DER encodings that indicate capabilities are as follows (KA is 581 key agreement, KDF is key derivation function, and Wrap is key wrap 582 algorithm): 584 KA=ECDH standard KDF=SHA-1 Wrap=Triple-DES 586 30 1c 06 09 2b 81 05 10 86 48 3f 00 02 30 0f 06 0b 2a 86 48 86 587 f7 0d 01 09 10 03 06 05 00 589 KA=ECDH standard KDF=SHA-224 Wrap=Triple-DES 591 30 19 06 06 2b 81 04 01 0B 00 30 0f 06 0b 2a 86 48 86 f7 0d 01 592 09 10 03 06 05 00 594 KA=ECDH standard KDF=SHA-256 Wrap=Triple-DES 596 30 19 06 06 2b 81 04 01 0B 01 30 0f 06 0b 2a 86 48 86 f7 0d 01 597 09 10 03 06 05 00 599 KA=ECDH standard KDF=SHA-384 Wrap=Triple-DES 601 30 19 06 06 2b 81 04 01 0B 02 30 0f 06 0b 2a 86 48 86 f7 0d 01 602 09 10 03 06 05 00 604 KA=ECDH standard KDF=SHA-512 Wrap=Triple-DES 606 30 19 06 06 2b 81 04 01 0B 03 30 0f 06 0b 2a 86 48 86 f7 0d 01 607 09 10 03 06 05 00 609 KA=ECDH standard KDF=SHA-1 Wrap=AES-128 611 30 1a 06 09 2b 81 05 10 86 48 3f 00 02 30 0d 06 09 60 86 48 01 612 65 03 04 01 05 05 00 614 KA=ECDH standard KDF=SHA-224 Wrap=AES-128 616 30 17 06 06 2b 81 04 01 0B 00 30 0d 06 09 60 86 48 01 65 03 04 617 01 05 05 00 619 KA=ECDH standard KDF=SHA-256 Wrap=AES-128 621 30 17 06 06 2b 81 04 01 0B 01 30 0d 06 09 60 86 48 01 65 03 04 622 01 05 05 00 624 KA=ECDH standard KDF=SHA-384 Wrap=AES-128 626 30 17 06 06 2b 81 04 01 0B 02 30 0d 06 09 60 86 48 01 65 03 04 627 01 05 05 00 629 KA=ECDH standard KDF=SHA-512 Wrap=AES-128 631 30 17 06 06 2b 81 04 01 0B 03 30 0d 06 09 60 86 48 01 65 03 04 632 01 05 05 00 634 KA=ECDH standard KDF=SHA-1 Wrap=AES-192 636 30 1a 06 09 2b 81 05 10 86 48 3f 00 02 30 0d 06 09 60 86 48 01 637 65 03 04 01 2D 05 00 639 KA=ECDH standard KDF=SHA-224 Wrap=AES-192 641 30 17 06 06 2b 81 04 01 0B 00 30 0d 06 09 60 86 48 01 65 03 04 642 01 2D 05 00 644 KA=ECDH standard KDF=SHA-256 Wrap=AES-192 646 30 17 06 06 2b 81 04 01 0B 01 30 0d 06 09 60 86 48 01 65 03 04 647 01 2D 05 00 649 KA=ECDH standard KDF=SHA-384 Wrap=AES-192 651 30 17 06 06 2b 81 04 01 0B 02 30 0d 06 09 60 86 48 01 65 03 04 652 01 2D 05 00 654 KA=ECDH standard KDF=SHA-512 Wrap=AES-192 656 30 17 06 06 2b 81 04 01 0B 03 30 0d 06 09 60 86 48 01 65 03 04 657 01 2D 05 00 659 KA=ECDH standard KDF=SHA-1 Wrap=AES-256 661 30 1a 06 09 2b 81 05 10 86 48 3f 00 02 30 0d 06 09 60 86 48 01 662 65 03 04 01 2D 05 00 664 KA=ECDH standard KDF=SHA-224 Wrap=AES-256 666 30 17 06 06 2b 81 04 01 0B 00 30 0d 06 09 60 86 48 01 65 03 04 667 01 2D 05 00 669 KA=ECDH standard KDF=SHA-256 Wrap=AES-256 671 30 17 06 06 2b 81 04 01 0B 01 30 0d 06 09 60 86 48 01 65 03 04 672 01 2D 05 00 674 KA=ECDH standard KDF=SHA-384 Wrap=AES-256 676 30 17 06 06 2b 81 04 01 0B 02 30 0d 06 09 60 86 48 01 65 03 04 677 01 2D 05 00 679 KA=ECDH standard KDF=SHA-512 Wrap=AES-256 681 30 17 06 06 2b 81 04 01 0B 03 30 0d 06 09 60 86 48 01 65 03 04 682 01 2D 05 00 684 KA=ECDH cofactor KDF=SHA-1 Wrap=Triple-DES 686 30 1c 06 09 2b 81 05 10 86 48 3f 00 03 30 0f 06 0b 2a 86 48 86 687 f7 0d 01 09 10 03 06 05 00 689 KA=ECDH cofactor KDF=SHA-224 Wrap=Triple-DES 691 30 19 06 06 2b 81 04 01 0E 00 30 0f 06 0b 2a 86 48 86 f7 0d 01 692 09 10 03 06 05 00 694 KA=ECDH cofactor KDF=SHA-256 Wrap=Triple-DES 696 30 19 06 06 2b 81 04 01 0E 01 30 0f 06 0b 2a 86 48 86 f7 0d 01 697 09 10 03 06 05 00 699 KA=ECDH cofactor KDF=SHA-384 Wrap=Triple-DES 701 30 19 06 06 2b 81 04 01 0E 02 30 0f 06 0b 2a 86 48 86 f7 0d 01 702 09 10 03 06 05 00 704 KA=ECDH cofactor KDF=SHA-512 Wrap=Triple-DES 706 30 19 06 06 2b 81 04 01 0E 03 30 0f 06 0b 2a 86 48 86 f7 0d 01 707 09 10 03 06 05 00 709 KA=ECDH cofactor KDF=SHA-1 Wrap=AES-128 711 30 1a 06 09 2b 81 05 10 86 48 3f 00 03 30 0d 06 09 60 86 48 01 712 65 03 04 01 05 05 00 714 KA=ECDH cofactor KDF=SHA-224 Wrap=AES-128 716 30 17 06 06 2b 81 04 01 0E 00 30 0d 06 09 60 86 48 01 65 03 04 717 01 05 05 00 719 KA=ECDH cofactor KDF=SHA-256 Wrap=AES-128 721 30 17 06 06 2b 81 04 01 0E 01 30 0d 06 09 60 86 48 01 65 03 04 722 01 05 05 00 724 KA=ECDH cofactor KDF=SHA-384 Wrap=AES-128 726 30 17 06 06 2b 81 04 01 0E 02 30 0d 06 09 60 86 48 01 65 03 04 727 01 05 05 00 729 KA=ECDH cofactor KDF=SHA-512 Wrap=AES-128 731 30 17 06 06 2b 81 04 01 0E 03 30 0d 06 09 60 86 48 01 65 03 04 732 01 05 05 00 734 KA=ECDH cofactor KDF=SHA-1 Wrap=AES-192 736 30 1a 06 09 2b 81 05 10 86 48 3f 00 03 30 0d 06 09 60 86 48 01 737 65 03 04 01 19 05 00 739 KA=ECDH cofactor KDF=SHA-224 Wrap=AES-192 741 30 17 06 06 2b 81 04 01 0E 00 30 0d 06 09 60 86 48 01 65 03 04 742 01 19 05 00 744 KA=ECDH cofactor KDF=SHA-256 Wrap=AES-192 746 30 17 06 06 2b 81 04 01 0E 01 30 0d 06 09 60 86 48 01 65 03 04 747 01 19 05 00 749 KA=ECDH cofactor KDF=SHA-384 Wrap=AES-192 751 30 17 06 06 2b 81 04 01 0E 02 30 0d 06 09 60 86 48 01 65 03 04 752 01 19 05 00 754 KA=ECDH cofactor KDF=SHA-512 Wrap=AES-192 756 30 17 06 06 2b 81 04 01 0E 03 30 0d 06 09 60 86 48 01 65 03 04 757 01 19 05 00 759 KA=ECDH cofactor KDF=SHA-1 Wrap=AES-256 761 30 1a 06 09 2b 81 05 10 86 48 3f 00 03 30 0d 06 09 60 86 48 01 762 65 03 04 01 2D 05 00 764 KA=ECDH cofactor KDF=SHA-224 Wrap=AES-256 766 30 17 06 06 2b 81 04 01 0E 00 30 0d 06 09 60 86 48 01 65 03 04 767 01 2D 05 00 769 KA=ECDH cofactor KDF=SHA-256 Wrap=AES-256 771 30 17 06 06 2b 81 04 01 0E 01 30 0d 06 09 60 86 48 01 65 03 04 772 01 2D 05 00 774 KA=ECDH cofactor KDF=SHA-384 Wrap=AES-256 776 30 17 06 06 2b 81 04 01 0E 02 30 0d 06 09 60 86 48 01 65 03 04 777 01 2D 05 00 779 KA=ECDH cofactor KDF=SHA-512 Wrap=AES-256 781 30 17 06 06 2b 81 04 01 0E 03 30 0d 06 09 60 86 48 01 65 03 04 782 01 2D 05 00 784 KA=ECMQV 1-Pass KDF=SHA-1 Wrap=Triple-DES 786 30 1c 06 09 2b 81 05 10 86 48 3f 00 10 30 0f 06 0b 2a 86 48 86 787 f7 0d 01 09 10 03 06 05 00 789 KA=ECMQV 1-Pass KDF=SHA-224 Wrap=Triple-DES 791 30 19 06 06 2b 81 04 01 0F 00 30 0f 06 0b 2a 86 48 86 f7 0d 01 792 09 10 03 06 05 00 794 KA=ECMQV 1-Pass KDF=SHA-256 Wrap=Triple-DES 796 30 19 06 06 2b 81 04 01 0F 01 30 0f 06 0b 2a 86 48 86 f7 0d 01 797 09 10 03 06 05 00 799 KA=ECMQV 1-Pass KDF=SHA-384 Wrap=Triple-DES 801 30 19 06 06 2b 81 04 01 0F 02 30 0f 06 0b 2a 86 48 86 f7 0d 01 802 09 10 03 06 05 00 804 KA=ECMQV 1-Pass KDF=SHA-512 Wrap=Triple-DES 806 30 19 06 06 2b 81 04 01 0F 03 30 0f 06 0b 2a 86 48 86 f7 0d 01 807 09 10 03 06 05 00 809 KA=ECMQV 1-Pass KDF=SHA-1 Wrap=AES-128 811 30 1a 06 09 2b 81 05 10 86 48 3f 00 10 30 0d 06 09 60 86 48 01 812 65 03 04 01 05 05 00 814 KA=ECMQV 1-Pass KDF=SHA-224 Wrap=AES-128 816 30 17 06 06 2b 81 04 01 0F 00 30 0d 06 09 60 86 48 01 65 03 04 817 01 05 05 00 819 KA=ECMQV 1-Pass KDF=SHA-256 Wrap=AES-128 821 30 17 06 06 2b 81 04 01 0F 01 30 0d 06 09 60 86 48 01 65 03 04 822 01 05 05 00 824 KA=ECMQV 1-Pass KDF=SHA-384 Wrap=AES-128 826 30 17 06 06 2b 81 04 01 0F 02 30 0d 06 09 60 86 48 01 65 03 04 827 01 05 05 00 829 KA=ECMQV 1-Pass KDF=SHA-512 Wrap=AES-128 831 30 17 06 06 2b 81 04 01 0F 03 30 0d 06 09 60 86 48 01 65 03 04 832 01 05 05 00 834 KA=ECMQV 1-Pass KDF=SHA-1 Wrap=AES-192 836 30 1a 06 09 2b 81 05 10 86 48 3f 00 10 30 0d 06 09 60 86 48 01 837 65 03 04 01 2D 05 00 839 KA=ECMQV 1-Pass KDF=SHA-224 Wrap=AES-192 841 30 17 06 06 2b 81 04 01 0F 00 30 0d 06 09 60 86 48 01 65 03 04 842 01 19 05 00 844 KA=ECMQV 1-Pass KDF=SHA-256 Wrap=AES-192 846 30 17 06 06 2b 81 04 01 0F 01 30 0d 06 09 60 86 48 01 65 03 04 847 01 19 05 00 849 KA=ECMQV 1-Pass KDF=SHA-384 Wrap=AES-192 851 30 17 06 06 2b 81 04 01 0F 02 30 0d 06 09 60 86 48 01 65 03 04 852 01 19 05 00 854 KA=ECMQV 1-Pass KDF=SHA-512 Wrap=AES-192 856 30 17 06 06 2b 81 04 01 0F 03 30 0d 06 09 60 86 48 01 65 03 04 857 01 19 05 00 859 KA=ECMQV 1-Pass KDF=SHA-1 Wrap=AES-256 861 30 1a 06 09 2b 81 05 10 86 48 3f 00 10 30 0d 06 09 60 86 48 01 862 65 03 04 01 2D 05 00 864 KA=ECMQV 1-Pass KDF=SHA-224 Wrap=AES-256 866 30 17 06 06 2b 81 04 01 0F 00 30 0d 06 09 60 86 48 01 65 03 04 867 01 2D 05 00 869 KA=ECMQV 1-Pass KDF=SHA-256 Wrap=AES-256 871 30 17 06 06 2b 81 04 01 0F 01 30 0d 06 09 60 86 48 01 65 03 04 872 01 2D 05 00 874 KA=ECMQV 1-Pass KDF=SHA-384 Wrap=AES-256 876 30 17 06 06 2b 81 04 01 0F 02 30 0d 06 09 60 86 48 01 65 03 04 877 01 2D 05 00 879 KA=ECMQV 1-Pass KDF=SHA-512 Wrap=AES-256 881 30 17 06 06 2b 81 04 01 0F 03 30 0d 06 09 60 86 48 01 65 03 04 882 01 2D 05 00 884 NOTE: The S/MIME Capabilities indicate that parameters for the key 885 wrap algorithm AES-* (where * is 128, 192, or 256) are NULL; however, 886 the parameters are absent when used to encrypt/decrypt a content 887 encryption key. 889 NOTE: The S/MIME Capabilities for the supported AES content 890 encryption key sizes are defined in [CMS-AES]. 892 NOTE: The S/MIME Capabilities for the supported MAC algorithms are 893 defined in [CMS-ASN]. 895 7. ASN.1 Syntax 897 The ASN.1 syntax used in this document is gathered in this section 898 for reference purposes. 900 7.1. Algorithm Identifiers 902 This section provides the object identifiers for the algorithms used 903 in this document along with any associated parameters. 905 7.1.1. Digest Algorithms 907 Digest algorithm object identifiers are used in the SignedData 908 digestAlgorithms and digestAlgorithm fields and the AuthenticatedData 909 digestAlgorithm field. The digest algorithms used in this document 910 are: SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. The object 911 identifiers and parameters associated with these algorithms are found 912 in [CMS-ALG] and [CMS-SHA2]. 914 7.1.2. Originator Public Key 916 The KeyAgreeRecipientInfo originator field use the following object 917 identifier to indicate an elliptic curve public key: 919 id-ecPublicKey OBJECT IDENTIFIER ::= { 920 ansi-x9-62 keyType(2) 1 } 922 where 924 ansi-x9-62 OBJECT IDENTIFIER ::= { 925 iso(1) member-body(2) us(840) 10045 } 927 When the object identifier id-ecPublicKey is used here with an 928 algorithm identifier, the associated parameters MUST be either absent 929 or ECParameters. Implementations MUST accept id-ecPublicKey with 930 absent and ECParameters parameters. If ECParameters is present, its 931 value MUST match the recipient's ECParameters. Implementations 932 SHOULD generate absent parameters for the id-ecPublicKey object 933 identifier in the KeyAgreeRecipientInfo originator field. 935 NOTE: [CMS-ECC] indicated the parameters were NULL. Support for this 936 legacy form is OPTIONAL. 938 7.1.3. Signature Algorithms 940 Signature algorithm identifiers are used in the SignedData 941 signatureAlgorithm and signature fields. The signature algorithms 942 used in this document are ECDSA with SHA-1, ECDSA with SHA-224, ECDSA 943 with SHA-256, ECDSA with SHA-384, and ECDSA with SHA-512. The object 944 identifiers and parameters associated with these algorithms are found 945 in [PKI-ALG]. 947 NOTE: [CMS-ECC] indicated the parameters were NULL. Support for NULL 948 parameters is OPTIONAL. 950 7.1.4. Key Agreement Algorithms 952 Key agreement algorithms are used in EnvelopedData, 953 AuthenticatedData, and AuthEnvelopedData in the KeyAgreeRecipientInfo 954 keyEncryptionAlgorithm field. The following object identifiers 955 indicate the key agreement algorithms used in this document: 957 dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 958 x9-63-scheme 2 } 960 dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 961 secg-scheme 11 0 } 963 dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 964 secg-scheme 11 1 } 966 dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 967 secg-scheme 11 2 } 969 dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 970 secg-scheme 11 3 } 972 dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 973 x9-63-scheme 3 } 975 dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 976 secg-scheme 14 0 } 978 dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 979 secg-scheme 14 1 } 981 dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 982 secg-scheme 14 2 } 984 dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 985 secg-scheme 14 3 } 987 mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= { 988 x9-63-scheme 16 } 990 mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= { 991 secg-scheme 15 0 } 993 mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= { 994 secg-scheme 15 1 } 996 mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= { 997 secg-scheme 15 2 } 999 mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= { 1000 secg-scheme 15 3 } 1002 where 1004 x9-63-scheme OBJECT IDENTIFIER ::= { 1005 iso(1) identified-organization(3) tc68(133) country(16) 1006 x9(840) x9-63(63) schemes(0) } 1008 and 1010 secg-scheme OBJECT IDENTIFIER ::= { 1011 iso(1) identified-organization(3) certicom(132) schemes(1) } 1013 When the object identifiers are used here within an algorithm 1014 identifier, the associated parameters field contains KeyWrapAlgorithm 1015 to indicate the key wrap algorithm and any associated parameters. 1017 7.1.5. Key Wrap Algorithms 1019 Key wrap algorithms are used as part of the parameters in the key 1020 agreement algorithm. The key wrap algorithms used in this document 1021 are Triple-DES, AES-128, AES-192, and AES-256. The object 1022 identifiers and parameters for these algorithms are found in [CMS- 1023 ALG] and [CMS-AES]. 1025 7.1.6. Content Encryption Algorithms 1027 Content encryption algorithms are used in EnvelopedData and 1028 AuthEnvelopedData in the EncryptedContentInfo 1029 contentEncryptionAlgorithm field. The content encryption algorithms 1030 used with EnvelopedData in this document are 3-Key Triple DES in CBC 1031 mode, AES-128 in CBC mode, AES-192 in CBC mode, and AES-256 in CBC 1032 mode. The object identifiers and parameters associated with these 1033 algorithms are found in [CMS-ALG] and [CMS-AES]. The content 1034 encryption algorithms used with AuthEnvelopedData in this document 1035 are AES-128 in CCM mode, AES-192 in CCM mode, AES-256 in CCM mode, 1036 AES-128 in GCM mode, AES-192 in GCM mode, and AES-256 in GCM mode. 1037 The object identifiers and parameters associated with these 1038 algorithms are found in [CMS-AESCG]. 1040 7.1.7. Message Authentication Code Algorithms 1042 Message authentication code algorithms are used in AuthenticatedData 1043 in the macAlgorithm field. The message authentication code 1044 algorithms used in this document are HMAC with SHA-1, HMAC with SHA- 1045 224, HMAC with SHA-256, HMAC with SHA-384, and HMAC with SHA-512. 1046 The object identifiers and parameters associated with these 1047 algorithms are found in [HMAC-SHA1] and [HMAC-SHA2]. 1049 7.1.8. Key Derivation Algorithm 1051 The KDF used in this document is as specified in 3.6.1 of [SEC1]. 1052 The hash algorithm is identified in key agreement algorithm. For 1053 example, dhSinglePass-stdDH-sha256kdf-scheme uses the KDF from [SEC1] 1054 but uses SHA-256 instead of SHA-1. 1056 7.2. Other Syntax 1058 The following additional syntax is used here. 1060 When using ECDSA with SignedData, ECDSA signatures are encoded using 1061 the type: 1063 ECDSA-Sig-Value ::= SEQUENCE { 1064 r INTEGER, 1065 s INTEGER } 1067 ECDSA-Sig-Value is specified in [PKI-ALG]. Within CMS, ECDSA-Sig- 1068 Value is DER-encoded and placed within a signature field of 1069 SignedData. 1071 When using ECDH and ECMQV with EnvelopedData, AuthenticatedData, and 1072 AuthEnvelopedData, ephemeral and static public keys are encoded using 1073 the type ECPoint. Implementations MUST support uncompressed keys, MAY 1074 support compressed keys, and MUST NOT support hybrid keys. 1076 ECPoint ::= OCTET STRING 1078 When using ECMQV with EnvelopedData, AuthenticatedData, and 1079 AuthEnvelopedData, the sending agent's ephemeral public key and 1080 additional keying material are encoded using the type: 1082 MQVuserKeyingMaterial ::= SEQUENCE { 1083 ephemeralPublicKey OriginatorPublicKey, 1084 addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL } 1086 The ECPoint syntax is used to represent the ephemeral public key and 1087 is placed in the ephemeralPublicKey.publicKey field. The additional 1088 user keying material is placed in the addedukm field. Then the 1089 MQVuserKeyingMaterial value is DER-encoded and placed within the ukm 1090 field of EnvelopedData, AuthenticatedData, or AuthEnvelopedData. 1092 When using ECDH or ECMQV with EnvelopedData, AuthenticatedData, or 1093 AuthEnvelopedData, the key-encryption keys are derived by using the 1094 type: 1096 ECC-CMS-SharedInfo ::= SEQUENCE { 1097 keyInfo AlgorithmIdentifier, 1098 entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL, 1099 suppPubInfo [2] EXPLICIT OCTET STRING } 1101 The fields of ECC-CMS-SharedInfo are as follows: 1103 keyInfo contains the object identifier of the key-encryption 1104 algorithm (used to wrap the CEK) and associated parameters. In 1105 this specification, 3DES wrap has NULL parameters while the AES 1106 wraps have absent parameters. 1108 entityUInfo optionally contains additional keying material 1109 supplied by the sending agent. When used with ECDH and CMS, the 1110 entityUInfo field contains the octet string ukm. When used with 1111 ECMQV and CMS, the entityUInfo contains the octet string addedukm 1112 (encoded in MQVuserKeyingMaterial). 1114 suppPubInfo contains the length of the generated KEK, in bits, 1115 represented as a 32 bit number, as in [CMS-DH] and [CMS-AES]. 1116 (E.g. for AES-256 it would be 00 00 01 00.) 1118 Within CMS, ECC-CMS-SharedInfo is DER-encoded and used as input to 1119 the key derivation function, as specified in Section 3.6.1 of [SEC1]. 1121 NOTE: ECC-CMS-SharedInfo differs from the OtherInfo specified in 1122 [CMS-DH]. Here, a counter value is not included in the keyInfo field 1123 because the key derivation function specified in Section 3.6.1 of 1124 [SEC1] ensures that sufficient keying data is provided. 1126 8. Recommended Algorithms and Elliptic Curves 1128 It is RECOMMENDED that implementations of this specification support 1129 SignedData and EnvelopedData. Support for AuthenticatedData and 1130 AuthEnvelopedData is OPTIONAL. 1132 In order to encourage interoperability, implementations SHOULD use 1133 the elliptic curve domain parameters specified by [PKI-ALG]. 1135 Implementations that support SignedData with ECDSA: 1137 - MUST support ECDSA with SHA-256; and, 1139 - MAY support ECDSA with SHA-1, ECDSA with SHA-224, ECDSA with SHA- 1140 384, and ECDSA with SHA-512; other digital signature algorithms 1141 MAY also be supported. 1143 When using ECDSA, to promote interoperability it is RECOMMENDED that 1144 the P-192, P-224, and the P-256 curves be used with SHA-256, the P- 1145 384 curve be used with SHA-384, and the P-521 curve be used with SHA- 1146 512. 1148 If EnvelopedData is supported, then ephemeral-static ECDH standard 1149 primitive MUST be supported. Support for ephemeral-static ECDH co- 1150 factor is OPTIONAL and support for 1-Pass ECMQV is also OPTIONAL. 1152 Implementations that support EnvelopedData with the ephemeral-static 1153 ECDH standard primitive: 1155 - MUST support the dhSinglePass-stdDH-sha256kdf-scheme key 1156 agreement algorithm, the id-aes128-wrap key wrap algorithm, and 1157 the id-aes128-cbc content encryption algorithm; and, 1159 - MAY support the dhSinglePass-stdDH-sha1kdf-scheme, dhSinglePass- 1160 stdDH-sha224kdf-scheme, dhSinglePass-stdDH-sha384kdf-scheme and 1161 dhSinglePass-stdDH-sha512kdf-scheme key agreement algorithms, 1162 the id-alg-CMS3DESwrap, id-aes192-wrap, and id-aes256-wrap key 1163 wrap algorithms and the des-ede3-cbc, id-aes192-cbc, and id- 1164 aes256-cbc content encryption algorithms; other algorithms MAY 1165 also be supported. 1167 Implementations that support EnvelopedData with the ephemeral-static 1168 ECDH cofactor primitive: 1170 - MUST support the dhSinglePass-cofactorDH-sha256kdf-scheme key 1171 agreement algorithm, the id-aes128-wrap key wrap algorithm, and 1172 the id-aes128-cbc content encryption algorithm; and, 1174 - MAY support the dhSinglePass-cofactorDH-sha1kdf-scheme, 1175 dhSinglePass-cofactorDH-sha224kdf-scheme, dhSinglePass- 1176 cofactorDH-sha384kdf-scheme, and dhSinglePass-cofactorDH- 1177 sha512kdf-scheme key agreement, the id-alg-CMS3DESwrap, id- 1178 aes192-wrap, and id-aes256-wrap key wrap algorithms and the des- 1179 ede3-cbc, id-aes192-cbc, and id-aes256-cbc content encryption 1180 algorithms; other algorithms MAY also be supported. 1182 Implementations that support EnvelopedData with 1-Pass ECMQV: 1184 - MUST support the mqvSinglePass-sha256kdf-scheme key agreement 1185 algorithm, the id-aes128-wrap key wrap algorithm, and the id- 1186 aes128-cbc content encryption algorithm; and, 1188 - MAY support mqvSinglePass-sha1kdf-scheme, mqvSinglePass- 1189 sha224kdf-scheme, mqvSinglePass-sha384kdf-scheme, and 1190 mqvSinglePass-sha512kdf-scheme key agreement algorithms, the id- 1191 alg-CMS3DESwrap, id-aes192-wrap, and id-aes256-wrap key wrap 1192 algorithms and the des-ede3-cbc, id-aes192-cbc, and id-aes256- 1193 cbc content encryption algorithms; other algorithms MAY also be 1194 supported. 1196 Implementations that support AuthenticatedData with 1-Pass ECMQV: 1198 - MUST support the mqvSinglePass-sha256kdf-scheme key agreement, 1199 the id-aes128-wrap key wrap, the id-sha256 message digest, and 1200 id-hmacWithSHA256 message authentication code algorithms; and, 1202 - MAY support the mqvSinglePass-sha1kdf-scheme, mqvSinglePass- 1203 sha224kdf-scheme, mqvSinglePass-sha384kdf-scheme, mqvSinglePass- 1204 sha512kdf-scheme key agreement algorithms, the id-alg- 1205 CMS3DESwrap, id-aes192-wrap, and id-aes256-wrap key wrap 1206 algorithms, the id-sha1, id-sha224, id-sha384, and id-sha512, 1207 message digest algorithms, and the hmac-SHA1, id-hmacWithSHA224, 1208 id-hmacWithSHA384, and id-hmacWithSHA512 message authentication 1209 code algorithms; other algorithms MAY also be supported. 1211 Implementations that support AuthEnvelopedData with 1-Pass ECMQV: 1213 - MUST support the mqvSinglePass-sha256kdf-scheme key agreement, 1214 the id-aes128-wrap key wrap, and the id-aes128-ccm 1215 authenticated-content encryption; and, 1217 - MAY support the mqvSinglePass-sha1kdf-scheme, mqvSinglePass- 1218 sha224kdf-scheme, mqvSinglePass-sha384kdf-scheme, and 1219 mqvSinglePass-sha512kdf-scheme key agreement algorithms, the id- 1220 alg-CMS3DESwrap, id-aes192-wrap, and id-aes256-wrap key wrap 1221 algorithms, the id-aes192-ccm and id-aes256-ccm authenticated- 1222 content encryption algorithms; other algorithms MAY also be 1223 supported. 1225 9. Security Considerations 1227 Cryptographic algorithms will be broken or weakened over time. 1228 Implementers and users need to check that the cryptographic 1229 algorithms listed in this document continue to provide the expected 1230 level of security. The IETF from time to time may issue documents 1231 dealing with the current state of the art. 1233 Cryptographic algorithms rely on random numbers. See [RANDOM] for 1234 guidance on generation of random numbers. 1236 Receiving agents that validate signatures and sending agents that 1237 encrypt messages need to be cautious of cryptographic processing 1238 usage when validating signatures and encrypting messages using keys 1239 larger than those mandated in this specification. An attacker could 1240 send keys and/or certificates with keys which would result in 1241 excessive cryptographic processing, for example keys larger than 1242 those mandated in this specification, which could swamp the 1243 processing element. Agents which use such keys without first 1244 validating the certificate to a trust anchor are advised to have some 1245 sort of cryptographic resource management system to prevent such 1246 attacks. 1248 Using secret keys of an appropriate size is crucial to the security 1249 of a Diffie-Hellman exchange. For elliptic curve groups, the size of 1250 the secret key must be equal to the size of n (the order of the group 1251 generated by the point g). Using larger secret keys provides 1252 absolutely no additional security, and using smaller secret keys is 1253 likely to result in dramatically less security. (See [SP800-56A] for 1254 more information on selecting secret keys.) 1256 This specification is based on [CMS], [CMS-AES], [CMS-AESCG], [CMS- 1257 ALG], [CMS-AUTHENV], [CMS-DH], [CMS-SHA2], [FIPS180-3], [FIPS186-3], 1258 [HMAC-SHA1], and [HMAC-SHA2], and the appropriate security 1259 considerations of those documents apply. 1261 In addition, implementers of AuthenticatedData and AuthEnvelopedData 1262 should be aware of the concerns expressed in [BON] when using 1263 AuthenticatedData and AuthEnvelopedData to send messages to more than 1264 one recipient. Also, users of MQV should be aware of the 1265 vulnerability in [K]. 1267 When implementing EnvelopedData, AuthenticatedData, and 1268 AuthEnvelopedData, there are five algorithm related choices that need 1269 to be made: 1271 1) What is the public key size? 1272 2) What is the KDF? 1273 3) What is the key wrap algorithm? 1274 4) What is the content encryption algorithm? 1275 5) What is the curve? 1277 Consideration must be given to strength of the security provided by 1278 each of these choices. Security is measured in bits, where a strong 1279 symmetric cipher with a key of X bits is said to provide X bits of 1280 security. It is recommended that the bits of security provided by 1281 each are roughly equivalent. The following table provides comparable 1282 minimum bits of security [SP800-57] for the ECDH/ECMQV key sizes, 1283 KDFs, key wrapping algorithms, and content encryption algorithms. It 1284 also lists curves [PKI-ALG] for the key sizes. 1286 Minimum | ECDH or | Key | Key | Content | Curves 1287 Bits of | ECQMV | Derivation | Wrap | Encryption | 1288 Security | Key Size | Function | Alg. | Alg. | 1289 ---------+----------+------------+----------+-------------+---------- 1290 80 | 160-223 | SHA-1 | 3DES | 3DES CBC | sect163k1 1291 | | SHA-224 | AES-128 | AES-128 CBC | secp163r2 1292 | | SHA-256 | AES-192 | AES-192 CBC | secp192r1 1293 | | SHA-384 | AES-256 | AES-256 CBC | 1294 | | SHA-512 | | | 1295 ---------+----------+------------+----------+-------------+--------- 1296 112 | 224-255 | SHA-1 | 3DES | 3DES CBC | secp224r1 1297 | | SHA-224 | AES-128 | AES-128 CBC | sect233k1 1298 | | SHA-256 | AES-192 | AES-192 CBC | sect233r1 1299 | | SHA-384 | AES-256 | AES-256 CBC | 1300 | | SHA-512 | | | 1301 ---------+----------+------------+----------+-------------+--------- 1302 128 | 256-383 | SHA-1 | AES-128 | AES-128 CBC | secp256r1 1303 | | SHA-224 | AES-192 | AES-192 CBC | sect283k1 1304 | | SHA-256 | AES-256 | AES-256 CBC | sect283r1 1305 | | SHA-384 | | | 1306 | | SHA-512 | | | 1307 ---------+----------+------------+----------+-------------+--------- 1308 192 | 384-511 | SHA-224 | AES-192 | AES-192 CBC | secp384r1 1309 | | SHA-256 | AES-256 | AES-256 CBC | sect409k1 1310 | | SHA-384 | | | sect409r1 1311 | | SHA-512 | | | 1312 ---------+----------+------------+----------+-------------+--------- 1313 256 | 512+ | SHA-256 | AES-256 | AES-256 CBC | secp521r1 1314 | | SHA-384 | | | sect571k1 1315 | | SHA-512 | | | sect571r1 1316 ---------+----------+------------+----------+-------------+--------- 1317 To promote interoperability, the following choices are RECOMMENDED: 1319 Minimum | ECDH or | Key | Key | Content | Curve 1320 Bits of | ECQMV | Derivation | Wrap | Encryption | 1321 Security | Key Size | Function | Alg. | Alg. | 1322 ---------+----------+------------+----------+-------------+---------- 1323 80 | 192 | SHA-256 | 3DES | 3DES CBC | secp192r1 1324 ---------+----------+------------+----------+-------------+---------- 1325 112 | 224 | SHA-256 | 3DES | 3DES CBC | secp224r1 1326 ---------+----------+------------+----------+-------------+---------- 1327 128 | 256 | SHA-256 | AES-128 | AES-128 CBC | secp256r1 1328 ---------+----------+------------+----------+-------------+---------- 1329 192 | 384 | SHA-384 | AES-256 | AES-256 CBC | secp384r1 1330 ---------+----------+------------+----------+-------------+---------- 1331 256 | 512+ | SHA-512 | AES-256 | AES-256 CBC | secp521r1 1332 ---------+----------+------------+----------+-------------+---------- 1334 When implementing SignedData, there are three algorithm related 1335 choices that need to be made: 1337 1) What is the public key size? 1338 2) What is the hash algorithm? 1339 3) What is the curve? 1341 Consideration must be given to the bits of security provided by each 1342 of these choices. Security is measured in bits, where a strong 1343 symmetric cipher with a key of X bits is said to provide X bits of 1344 security. It is recommended that the bits of security provided by 1345 each choice are roughly equivalent. The following table provides 1346 comparable minimum bits of security [SP800-57] for the ECDSA key 1347 sizes and message digest algorithms. It also lists curves [PKI-ALG] 1348 for the key sizes. 1350 Minimum | ECDSA | Message | Curve 1351 Bits of | Key Size | Digest | 1352 Security | | Algorithm | 1353 ---------+----------+-----------+----------- 1354 80 | 160-223 | SHA-1 | sect163k1 1355 | | SHA-224 | secp163r2 1356 | | SHA-256 | secp192r1 1357 | | SHA-384 | 1358 | | SHA-512 | 1359 ---------+----------+-----------+----------- 1360 112 | 224-255 | SHA-224 | secp224r1 1361 | | SHA-256 | sect233k1 1362 | | SHA-384 | sect233r1 1363 | | SHA-512 | 1364 ---------+----------+-----------+----------- 1365 128 | 256-383 | SHA-256 | secp256r1 1366 | | SHA-384 | sect283k1 1367 | | SHA-512 | sect283r1 1368 ---------+----------+-----------+----------- 1369 192 | 384-511 | SHA-384 | secp384r1 1370 | | SHA-512 | sect409k1 1371 | | | sect409r1 1372 ---------+----------+-----------+----------- 1373 256 | 512+ | SHA-512 | secp521r1 1374 | | | sect571k1 1375 | | | sect571r1 1376 ---------+----------+-----------+----------- 1378 To promote interoperability, the following choices are RECOMMENDED: 1380 Minimum | ECDSA | Message | Curve 1381 Bits of | Key Size | Digest | 1382 Security | | Algorithm | 1383 ---------+----------+-----------+----------- 1384 80 | 192 | SHA-256 | sect192r1 1385 ---------+----------+-----------+----------- 1386 112 | 224 | SHA-256 | secp224r1 1387 ---------+----------+-----------+----------- 1388 128 | 256 | SHA-256 | secp256r1 1389 ---------+----------+-----------+----------- 1390 192 | 384 | SHA-384 | secp384r1 1391 ---------+----------+-----------+----------- 1392 256 | 512+ | SHA-512 | secp521r1 1393 ---------+----------+-----------+----------- 1395 10. IANA Considerations 1397 This document makes extensive use of object identifiers to register 1398 originator public key types and algorithms. The algorithm object 1399 identifiers are registered in the ANSI X9.62, ANSI X9.63, NIST, RSA, 1400 and SECG arcs. Additionally, object identifiers are used to identify 1401 the ASN.1 modules found in Appendix A. These are defined in an arc 1402 delegated by IANA to the SMIME Working Group. No further action by 1403 IANA is necessary for this document or any anticipated updates. 1405 11. References 1407 11.1. Normative 1409 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 1410 3852, July 2004. 1412 [CMS-AES] Schaad, J., "Use of the Advanced Encryption Standard 1413 (AES) Encryption Algorithm in Cryptographic Message 1414 Syntax (CMS)", RFC 3565, July 2003. 1416 [CMS-AESCG] Housley, R., "Using AES-CCM and AES-GCM Authenticated 1417 Encryption in the Cryptographic Message Syntax 1418 (CMS)", RFC 5084, November 2007. 1420 [CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS) 1421 Algorithms", RFC 3370, August 2002. 1423 [CMS-ASN] Hoffman, P., and J. Schaad, "New ASN.1 Modules for 1424 CMS", draft-ietf-smime-new-asn1, work-in-progress. 1426 [CMS-AUTHENV] Housley, R. "Cryptographic Message Syntax (CMS) 1427 Authenticated-Enveloped-Data Content Type", RFC 5083, 1428 November 2007. 1430 [CMS-DH] Rescorla, E., "Diffie-Hellman Key Agreement Method", 1431 RFC 2631, June 1999. 1433 [CMS-SHA2] Turner, S., "Using SHA2 Algorithms with Cryptographic 1434 Message Syntax", draft-ietf-smime-sha2, work-in- 1435 progress. 1437 [FIPS180-3] National Institute of Standards and Technology 1438 (NIST), FIPS Publication 180-3: Secure Hash Standard, 1439 October 2008. 1441 [FIPS186-3] National Institute of Standards and Technology 1442 (NIST), FIPS Publication 186-3: Digital Signature 1443 Standard, (draft) November 2008. 1445 [HMAC-SHA1] Krawczyk, M., Bellare, M., and R. Canetti, "HMAC: 1446 Keyed-Hashing for Message Authentication", RFC 2104, 1447 February 1997. 1449 [HMAC-SHA2] Nystrom, M., "Identifiers and Test Vectors for HMAC- 1450 SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA- 1451 512", RFC 4231, December 2005. 1453 [MUST] Bradner, S., "Key Words for Use in RFCs to Indicate 1454 Requirement Levels", BCP 14, RFC 2119, March 1997. 1456 [MSG] Ramsdell, B., and S. Turner, "S/MIME Version 3.2 1457 Message Specification", draft-ietf-smime-3851bis, 1458 work-in-progress. 1460 [PKI] Cooper, D., Santesson, S., Farrell, S., Boeyen, S. 1461 Housley, R., and W. Polk, "Internet X.509 Public Key 1462 Infrastructure Certificate and Certificate Revocation 1463 List (CRL) Profile", RFC 5280, May 2008. 1465 [PKI-ALG] Turner, S., Brown, D., Yiu, K., Housley, R., and W. 1466 Polk, "Elliptic Curve Cryptography Subject Public Key 1467 Information", draft-ietf-pkix-ecc-subpubkeyinfo, 1468 work-in-progress. 1470 [RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller, 1471 "Randomness Recommendations for Security", RFC 4086, 1472 June 2005. 1474 [RSAOAEP] Schaad, J., Kaliski, B., and R. Housley, "Additional 1475 Algorithms and Identifiers for RSA Cryptography for 1476 use in the Internet X.509 Public Key Infrastructure 1477 Certificate and Certificate Revocation List (CRL) 1478 Profile", RFC 4055, June 2005. 1480 [SEC1] SECG, "Elliptic Curve Cryptography", Standards for 1481 Efficient Cryptography Group, 2000. Available from 1482 www.secg.org/collateral/sec1.pdf. 1484 [SP800-56A] National Institute of Standards and Technology 1485 (NIST), Special Publication 800-56A: Recommendation 1486 Pair-Wise Key Establishment Schemes Using Discrete 1487 Logarithm Cryptography (Revised), March 2007. 1489 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824- 1490 1:2002. Information Technology - Abstract Syntax 1491 Notation One. 1493 11.2. Informative 1495 [BON] D. Boneh, "The Security of Multicast MAC", 1496 Presentation at Selected Areas of Cryptography 2000, 1497 Center for Applied Cryptographic Research, University 1498 of Waterloo, 2000. Paper version available from 1499 http://crypto.stanford.edu/~dabo/papers/mmac.ps 1501 [CERTCAP] Santesson, S., "X.509 Certificate Extension for 1502 Secure/Multipurpose Internet Mail Extensions (S/MIME) 1503 Capabilities", RFC 4262, December 2005. 1505 [CMS-ECC] Blake-Wilson, S., Brown, D., and P. Lambert, "Use of 1506 Elliptic Curve Cryptography (ECC) Algorithms in 1507 Cryptographic Message Syntax (CMS)", RFC 3278, April 1508 2002. 1510 [CMS-KEA] Pawling, J., "CMS KEA and SKIPJACK Conventions", RFC 1511 2876, July 2000. 1513 [K] B. Kaliski, "MQV Vulnerability", Posting to ANSI X9F1 1514 and IEEE P1363 newsgroups, 1998. 1516 [PKI-ASN] Hoffman, P., and J. Schaad, "New ASN.1 Modules for 1517 PKIX", draft-ietf-pkix-new-asn1, work-in-progress. 1519 [SP800-57] National Institute of Standards and Technology 1520 (NIST), Special Publication 800-57: Recommendation 1521 for Key Management - Part 1 (Revised), March 2007. 1523 [X.681] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824- 1524 2:2002. Information Technology - Abstract Syntax 1525 Notation One: Information Object Specification. 1527 [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824- 1528 3:2002. Information Technology - Abstract Syntax 1529 Notation One: Constraint Specification. 1531 [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824- 1532 4:2002. Information Technology - Abstract Syntax 1533 Notation One: Parameterization of ASN.1 1534 Specifications, 2002. 1536 Appendix A ASN.1 Modules 1538 Appendix A.1 provides the normative ASN.1 definitions for the 1539 structures described in this specification using ASN.1 as defined in 1540 [X.680] for compilers that support the 1988 ASN.1. 1542 Appendix A.2 provides an informative ASN.1 definitions for the 1543 structures described in this specification using ASN.1 as defined in 1544 [X.680], [X.681], [X.682], and [X.683] for compilers that support the 1545 2002 ASN.1. This appendix contains the same information as Appendix 1546 A.1 in a more recent (and precise) ASN.1 notation, however Appendix 1547 A.1 takes precedence in case of conflict. 1549 Appendix A.1 1988 ASN.1 Module 1551 SMIMEECCAlgs-1988 1552 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1553 smime(16) modules(0) TBA1 } 1555 DEFINITIONS IMPLICIT TAGS ::= 1557 BEGIN 1559 -- EXPORTS ALL 1561 IMPORTS 1563 -- From [PKI] 1565 AlgorithmIdentifier 1566 FROM PKIX1Explicit88 1567 { iso(1) identified-organization(3) dod(6) 1568 internet(1) security(5) mechanisms(5) pkix(7) mod(0) 1569 pkix1-explicit(18) } 1571 -- From [RSAOAEP] 1573 id-sha224, id-sha256, id-sha384, id-sha512 1574 FROM PKIX1-PSS-OAEP-Algorithms 1575 { iso(1) identified-organization(3) dod(6) internet(1) 1576 security(5) mechanisms(5) pkix(7) id-mod(0) 1577 id-mod-pkix1-rsa-pkalgs(33) } 1579 -- From [PKI-ALG] 1581 id-sha1, ecdsa-with-SHA1, ecdsa-with-SHA224, 1582 ecdsa-with-SHA256, ecdsa-with-SHA384, ecdsa-with-SHA512, 1583 id-ecPublicKey, ECDSA-Sig-Value, ECPoint, ECParameters 1584 FROM PKIXAlgIDs-2008 1585 { iso(1) identified-organization(3) dod(6) internet(1) 1586 security(5) mechanisms(5) pkix(7) id-mod(0) TBA1 } 1588 -- From [CMS] 1590 OriginatorPublicKey, UserKeyingMaterial 1591 FROM CryptographicMessageSyntax2004 1592 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1593 smime(16) modules(0) cms-2004(24) } 1595 -- From [CMS-ALG] 1597 hMAC-SHA1, id-hmacWithSHA224, id-hmacWithSHA256, id-hmacWithSHA384, 1598 id-hmacWithSHA512, des-ede3-cbc, id-alg-CMS3DESwrap, CBCParameter 1599 FROM CryptographicMessageSyntaxAlgorithms 1600 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1601 smime(16) modules(0) cmsalg-2008(TBD) } 1603 -- From [CMS-AES] 1605 id-aes128-CBC, id-aes192-CBC, id-aes256-CBC, AES-IV, 1606 id-aes128-wrap, id-aes192-wrap, id-aes256-wrap 1607 FROM CMSAesRsaesOaep 1608 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1609 smime(16) modules(0) id-mod-cms-aes(19) } 1611 -- From [CMS-AESCG] 1613 id-aes128-CCM, id-aes192-CCM, id-aes256-CCM, CCMParameters 1614 id-aes128-GCM, id-aes192-GCM, id-aes256-GCM, GCMParameters 1615 FROM CMS-AES-CCM-and-AES-GCM 1616 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1617 smime(16) modules(0) id-mod-cms-aes(32) } 1619 ; 1620 -- 1621 -- Message Digest Algorithms 1622 -- 1624 -- id-sha1 Parameters are preferred absent 1625 -- id-sha224 Parameters are preferred absent 1626 -- id-sha256 Parameters are preferred absent 1627 -- id-sha384 Parameters are preferred absent 1628 -- id-sha512 Parameters are preferred absent 1630 -- 1631 -- Signature Algorithms 1632 -- 1634 -- ecdsa-with-SHA1 Parameters are NULL 1635 -- ecdsa-with-SHA224 Parameters are absent 1636 -- ecdsa-with-SHA256 Parameters are absent 1637 -- ecdsa-with-SHA384 Parameters are absent 1638 -- ecdsa-with-SHA512 Parameters are absent 1640 -- ECDSA Signature Value 1641 -- Contents of SignatureValue OCTET STRING 1643 -- ECDSA-Sig-Value ::= SEQUENCE { 1644 -- r INTEGER, 1645 -- s INTEGER 1646 -- } 1648 -- 1649 -- Key Agreement Algorithms 1650 -- 1652 x9-63-scheme OBJECT IDENTIFIER ::= { 1653 iso(1) identified-organization(3) tc68(133) country(16) x9(840) 1654 x9-63(63) schemes(0) } 1656 secg-scheme OBJECT IDENTIFIER ::= { 1657 iso(1) identified-organization(3) certicom(132) schemes(1) } 1659 -- 1660 -- Diffie-Hellman Single Pass, Standard, with KDFs 1661 -- 1663 -- Parameters are always present and indicate the key wrap algorithm 1664 -- with KeyWrapAlgorithm. 1666 dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 1667 x9-63-scheme 2 } 1669 dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 1670 secg-scheme 11 0 } 1672 dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 1673 secg-scheme 11 1 } 1675 dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 1676 secg-scheme 11 2 } 1678 dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 1679 secg-scheme 11 3 } 1681 -- 1682 -- Diffie-Hellman Single Pass, Cofactor, with KDFs 1683 -- 1685 dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 1686 x9-63-scheme 3 } 1688 dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 1689 secg-scheme 14 0 } 1691 dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 1692 secg-scheme 14 1 } 1694 dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 1695 secg-scheme 14 2 } 1697 dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 1698 secg-scheme 14 3 } 1700 -- 1701 -- MQV Single Pass, Cofactor, with KDFs 1702 -- 1704 mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= { 1705 x9-63-scheme 16 } 1707 mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= { 1708 secg-scheme 15 0 } 1710 mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= { 1711 secg-scheme 15 1 } 1713 mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= { 1714 secg-scheme 15 2 } 1716 mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= { 1717 secg-scheme 15 3 } 1719 -- 1720 -- Key Wrap Algorithms 1721 -- 1723 KeyWrapAlgorithm ::= AlgorithmIdentifier 1725 -- id-alg-CMS3DESwrap Parameters are NULL 1726 -- id-aes128-wrap Parameters are absent 1727 -- id-aes192-wrap Parameters are absent 1728 -- id-aes256-wrap Parameters are absent 1730 -- 1731 -- Content Encryption Algorithms 1732 -- 1734 -- des-ede3-cbc Parameters are CBCParameter 1735 -- id-aes128-CBC Parameters are AES-IV 1736 -- id-aes192-CBC Parameters are AES-IV 1737 -- id-aes256-CBC Parameters are AES-IV 1738 -- id-aes128-CCM Parameters are CCMParameters 1739 -- id-aes192-CCM Parameters are CCMParameters 1740 -- id-aes256-CCM Parameters are CCMParameters 1741 -- id-aes128-GCM Parameters are GCMParameters 1742 -- id-aes192-GCM Parameters are GCMParameters 1743 -- id-aes256-GCM Parameters are GCMParameters 1745 -- 1746 -- Message Authentication Code Algorithms 1747 -- 1749 -- hMAC-SHA1 Parameters are preferred absent 1750 -- id-hmacWithSHA224 Parameters are absent 1751 -- id-hmacWithSHA256 Parameters are absent 1752 -- id-hmacWithSHA384 Parameters are absent 1753 -- id-hmacWithSHA512 Parameters are absent 1754 -- 1755 -- Originator Public Key Algorithms 1756 -- 1758 -- id-ecPublicKey Parameters are absent, NULL, or ECParameters 1760 -- Format for both ephemeral and static public keys 1762 -- ECPoint ::= OCTET STRING 1764 -- ECParameters ::= CHOICE { 1765 -- namedCurve OBJECT IDENTIFIER 1766 -- commented out in [PKI-ALG] implicitCurve NULL 1767 -- commented out in [PKI-ALG] specifiedCurve SpecifiedECDomain 1768 -- commented out in [PKI-ALG] Extensible 1769 -- } 1770 -- implicitCurve and specifiedCurve MUST NOT be used in PKIX. 1771 -- Details for SpecifiedECDomain can be found in [X9.62]. 1772 -- Any future additions to this CHOICE should be coordinated 1773 -- with ANSI X9. 1775 -- Format of KeyAgreeRecipientInfo ukm field when used with 1776 -- ECMQV 1778 MQVuserKeyingMaterial ::= SEQUENCE { 1779 ephemeralPublicKey OriginatorPublicKey, 1780 addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL 1781 } 1783 -- 'SharedInfo' for input to KDF when using ECDH and ECMQV with 1784 -- EnvelopedData, AuthenticatedData, or AuthEnvelopedData 1786 ECC-CMS-SharedInfo ::= SEQUENCE { 1787 keyInfo AlgorithmIdentifier, 1788 entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL, 1789 suppPubInfo [2] EXPLICIT OCTET STRING 1790 } 1791 -- 1792 -- S/MIME Capabilities 1793 -- An identifier followed by type. 1794 -- 1796 -- 1797 -- S/MIME Capabilities: Message Digest Algorithms 1798 -- 1800 -- Found in [CMS-SHA2]. 1802 -- 1803 -- S/MIME Capabilities: Signature Algorithms 1804 -- 1806 -- ecdsa-with-SHA1 Type NULL 1807 -- ecdsa-with-SHA224 Type absent 1808 -- ecdsa-with-SHA256 Type absent 1809 -- ecdsa-with-SHA384 Type absent 1810 -- ecdsa-with-SHA512 Type absent 1812 -- 1813 -- S/MIME Capabilities: ECDH, Single Pass, Standard 1814 -- 1816 -- dhSinglePass-stdDH-sha1kdf Type is the KeyWrapAlgorithm 1817 -- dhSinglePass-stdDH-sha224kdf Type is the KeyWrapAlgorithm 1818 -- dhSinglePass-stdDH-sha256kdf Type is the KeyWrapAlgorithm 1819 -- dhSinglePass-stdDH-sha384kdf Type is the KeyWrapAlgorithm 1820 -- dhSinglePass-stdDH-sha512kdf Type is the KeyWrapAlgorithm 1822 -- 1823 -- S/MIME Capabilities: ECDH, Single Pass, Cofactor 1824 -- 1826 -- dhSinglePass-cofactorDH-sha1kdf Type is the KeyWrapAlgorithm 1827 -- dhSinglePass-cofactorDH-sha224kdf Type is the KeyWrapAlgorithm 1828 -- dhSinglePass-cofactorDH-sha256kdf Type is the KeyWrapAlgorithm 1829 -- dhSinglePass-cofactorDH-sha384kdf Type is the KeyWrapAlgorithm 1830 -- dhSinglePass-cofactorDH-sha512kdf Type is the KeyWrapAlgorithm 1831 -- 1832 -- S/MIME Capabilities: ECMQV, Single Pass, Standard 1833 -- 1835 -- mqvSinglePass-sha1kdf Type is the KeyWrapAlgorithm 1836 -- mqvSinglePass-sha224kdf Type is the KeyWrapAlgorithm 1837 -- mqvSinglePass-sha256kdf Type is the KeyWrapAlgorithm 1838 -- mqvSinglePass-sha384kdf Type is the KeyWrapAlgorithm 1839 -- mqvSinglePass-sha512kdf Type is the KeyWrapAlgorithm 1841 END 1843 Appendix A.2 2004 ASN.1 Module 1845 SMIMEECCAlgs-2008 1846 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1847 smime(16) modules(0) TBA2 } 1849 DEFINITIONS IMPLICIT TAGS ::= 1851 BEGIN 1853 -- EXPORTS ALL 1855 IMPORTS 1857 -- From [PKI-ALG] 1859 mda-sha1, sa-ecdsaWithSHA1, sa-ecdsaWithSHA224, sa-ecdsaWithSHA256, 1860 sa-ecdsaWithSHA384, sa-ecdsaWithSHA512, id-ecPublicKey, 1861 ECDSA-Sig-Value, ECPoint, ECParameters 1862 FROM PKIXAlgIDs-2008 1863 { iso(1) identified-organization(3) dod(6) internet(1) 1864 security(5) mechanisms(5) pkix(7) id-mod(0) TBA2 } 1866 -- FROM [PKI-ASN] 1868 KEY-WRAP, SIGNATURE-ALGORITHM, DIGEST-ALGORITHM, ALGORITHM, 1869 PUBLIC-KEY, MAC-ALGORITHM, CONTENT-ENCRYPTION, KEY-AGREE 1870 FROM AlgorithmInformation 1871 { iso(1) identified-organization(3) dod(6) internet(1) 1872 security(5) mechanisms(5) pkix(7) id-mod(0) 1873 id-mod-algorithmInformation(TBA5) } 1875 -- From [PKI-ASN] 1877 mda-sha224, mda-sha256, mda-sha384, mda-sha512 1878 FROM PKIX1-PSS-OAEP-Algorithms 1879 { iso(1) identified-organization(3) dod(6) internet(1) 1880 security(5) mechanisms(5) pkix(7) id-mod(0) TBA7 } 1882 -- From [CMS] 1884 OriginatorPublicKey, UserKeyingMaterial 1885 FROM CryptographicMessageSyntax2004 1886 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1887 smime(16) modules(0) cms-2004(24) } 1889 -- From [CMS-ASN] 1891 maca-hMAC-SHA1, maca-hMAC-SHA224, maca-hMAC-SHA256, maca-hMAC-SHA384, 1892 maca-hMAC-SHA512, cea-des-ede3-cbc, kwa-3DESWrap, CBCParameter 1893 FROM CryptographicMessageSyntaxAlgorithms 1894 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1895 smime(16) modules(0) cmsalg-2001(16) } 1897 -- From [CMS-ASN] 1899 cea-aes128-CBC, cea-aes192-CBC, cea-aes256-CBC, kwa-aes128-wrap, 1900 kwa-aes192-wrap, kwa-aes256-wrap 1901 FROM CMSAesRsaesOaep 1902 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1903 smime(16) modules(0) id-mod-cms-aes(19) } 1905 -- From [CMS-ASN] 1907 cea-aes128-ccm, cea-aes192-ccm, cea-aes256-ccm, cea-aes128-gcm, 1908 cea-aes192-gcm, cea-aes256-gcm 1909 FROM CMS-AES-CCM-and-AES-GCM 1910 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1911 smime(16) modules(0) cms-aes-ccm-and-gcm(32) } 1913 ; 1914 -- Constrains the SignedData digestAlgorithms field 1915 -- Constrains the SignedData SignerInfo digestAlgorithm field 1916 -- Constrains the AuthenticatedData digestAlgorithm field 1918 -- MessageDigestAlgs DIGEST-ALGORITHM ::= { 1919 -- mda-sha1 | 1920 -- mda-sha224 | 1921 -- mda-sha256 | 1922 -- mda-sha384 | 1923 -- mda-sha512, 1924 -- ... -- Extensible 1925 -- } 1927 -- Constrains the SignedData SignerInfo signatureAlgorithm field 1929 -- SignatureAlgs SIGNATURE-ALGORITHM ::= { 1930 -- sa-ecdsaWithSHA1 | 1931 -- sa-ecdsaWithSHA224 | 1932 -- sa-ecdsaWithSHA256 | 1933 -- sa-ecdsaWithSHA384 | 1934 -- sa-ecdsaWithSHA512, 1935 -- ... -- Extensible 1936 -- } 1938 -- ECDSA Signature Value 1939 -- Contents of SignatureValue OCTET STRING 1941 -- ECDSA-Sig-Value ::= SEQUENCE { 1942 -- r INTEGER, 1943 -- s INTEGER 1944 -- } 1946 -- 1947 -- Key Agreement Algorithms 1948 -- 1950 -- Constrains the EnvelopedData RecipientInfo KeyAgreeRecipientInfo 1951 -- keyEncryption Algorithm field 1952 -- Constrains the AuthenticatedData RecipientInfo 1953 -- KeyAgreeRecipientInfo keyEncryption Algorithm field 1954 -- Constrains the AuthEnvelopedData RecipientInfo 1955 -- KeyAgreeRecipientInfo keyEncryption Algorithm field 1957 -- DH variants are not used with AuthenticatedData or 1958 -- AuthEnvelopedData 1959 KeyAgreementAlgs KEY-AGREE ::= { 1960 kaa-dhSinglePass-stdDH-sha1kdf-scheme | 1961 kaa-dhSinglePass-stdDH-sha224kdf-scheme | 1962 kaa-dhSinglePass-stdDH-sha256kdf-scheme | 1963 kaa-dhSinglePass-stdDH-sha384kdf-scheme | 1964 kaa-dhSinglePass-stdDH-sha512kdf-scheme | 1965 kaa-dhSinglePass-cofactorDH-sha1kdf-scheme | 1966 kaa-dhSinglePass-cofactorDH-sha224kdf-scheme | 1967 kaa-dhSinglePass-cofactorDH-sha256kdf-scheme | 1968 kaa-dhSinglePass-cofactorDH-sha384kdf-scheme | 1969 kaa-dhSinglePass-cofactorDH-sha512kdf-scheme | 1970 kaa-mqvSinglePass-sha1kdf-scheme | 1971 kaa-mqvSinglePass-sha224kdf-scheme | 1972 kaa-mqvSinglePass-sha256kdf-scheme | 1973 kaa-mqvSinglePass-sha384kdf-scheme | 1974 kaa-mqvSinglePass-sha512kdf-scheme, 1975 ... -- Extensible 1976 } 1978 x9-63-scheme OBJECT IDENTIFIER ::= { 1979 iso(1) identified-organization(3) tc68(133) country(16) x9(840) 1980 x9-63(63) schemes(0) } 1982 secg-scheme OBJECT IDENTIFIER ::= { 1983 iso(1) identified-organization(3) certicom(132) schemes(1) } 1985 -- 1986 -- Diffie-Hellman Single Pass, Standard, with KDFs 1987 -- 1989 -- Parameters are always present and indicate the Key Wrap Algorithm 1991 kaa-dhSinglePass-stdDH-sha1kdf-scheme KEY-AGREE ::= { 1992 IDENTIFIER dhSinglePass-stdDH-sha1kdf-scheme 1993 PARAMS TYPE KeyWrapAlgorithm ARE required 1994 UKM TYPE -- unecndoded data -- IS preferredPresent 1995 SMIME CAPS { TYPE KeyWrapAlgorithm 1996 IDENTIFIED BY dhSinglePass-stdDH-sha1kdf-scheme } 1997 } 1999 dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 2000 x9-63-scheme 2 } 2002 kaa-dhSinglePass-stdDH-sha224kdf-scheme KEY-AGREE ::= { 2003 IDENTIFIER dhSinglePass-stdDH-sha224kdf-scheme 2004 PARAMS TYPE KeyWrapAlgorithm ARE required 2005 UKM TYPE -- unecndoded data -- IS preferredPresent 2006 SMIME CAPS { TYPE KeyWrapAlgorithm 2007 IDENTIFIED BY dhSinglePass-stdDH-sha224kdf-scheme } 2008 } 2010 dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 2011 secg-scheme 11 0 } 2013 kaa-dhSinglePass-stdDH-sha256kdf-scheme KEY-AGREE ::= { 2014 IDENTIFIER dhSinglePass-stdDH-sha256kdf-scheme 2015 PARAMS TYPE KeyWrapAlgorithm ARE required 2016 UKM TYPE -- unecndoded data -- IS preferredPresent 2017 SMIME CAPS { TYPE KeyWrapAlgorithm 2018 IDENTIFIED BY dhSinglePass-stdDH-sha256kdf-scheme } 2019 } 2021 dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 2022 secg-scheme 11 1 } 2024 kaa-dhSinglePass-stdDH-sha384kdf-scheme KEY-AGREE ::= { 2025 IDENTIFIER dhSinglePass-stdDH-sha384kdf-scheme 2026 PARAMS TYPE KeyWrapAlgorithm ARE required 2027 UKM TYPE -- unecndoded data -- IS preferredPresent 2028 SMIME CAPS { TYPE KeyWrapAlgorithm 2029 IDENTIFIED BY dhSinglePass-stdDH-sha384kdf-scheme } 2030 } 2032 dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 2033 secg-scheme 11 2 } 2035 kaa-dhSinglePass-stdDH-sha512kdf-scheme KEY-AGREE ::= { 2036 IDENTIFIER dhSinglePass-stdDH-sha512kdf-scheme 2037 PARAMS TYPE KeyWrapAlgorithm ARE required 2038 UKM TYPE -- unecndoded data -- IS preferredPresent 2039 SMIME CAPS { TYPE KeyWrapAlgorithm 2040 IDENTIFIED BY dhSinglePass-stdDH-sha512kdf-scheme } 2041 } 2043 dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 2044 secg-scheme 11 3 } 2046 -- 2047 -- Diffie-Hellman Single Pass, Cofactor, with KDFs 2048 -- 2050 kaa-dhSinglePass-cofactorDH-sha1kdf-scheme KEY-AGREE ::= { 2051 IDENTIFIER dhSinglePass-cofactorDH-sha1kdf-scheme 2052 PARAMS TYPE KeyWrapAlgorithm ARE required 2053 UKM TYPE -- unecndoded data -- IS preferredPresent 2054 SMIME CAPS { TYPE KeyWrapAlgorithm 2055 IDENTIFIED BY dhSinglePass-cofactorDH-sha1kdf-scheme } 2056 } 2058 dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 2059 x9-63-scheme 3 } 2061 kaa-dhSinglePass-cofactorDH-sha224kdf-scheme KEY-AGREE ::= { 2062 IDENTIFIER dhSinglePass-cofactorDH-sha224kdf-scheme 2063 PARAMS TYPE KeyWrapAlgorithm ARE required 2064 UKM TYPE -- unecndoded data -- IS preferredPresent 2065 SMIME CAPS { TYPE KeyWrapAlgorithm 2066 IDENTIFIED BY 2067 dhSinglePass-cofactorDH-sha224kdf-scheme } 2068 } 2070 dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 2071 secg-scheme 14 0 } 2073 kaa-dhSinglePass-cofactorDH-sha256kdf-scheme KEY-AGREE ::= { 2074 IDENTIFIER dhSinglePass-cofactorDH-sha256kdf-scheme 2075 PARAMS TYPE KeyWrapAlgorithm ARE required 2076 UKM TYPE -- unecndoded data -- IS preferredPresent 2077 SMIME CAPS { TYPE KeyWrapAlgorithm 2078 IDENTIFIED BY 2079 dhSinglePass-cofactorDH-sha256kdf-scheme } 2080 } 2082 dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 2083 secg-scheme 14 1 } 2085 kaa-dhSinglePass-cofactorDH-sha384kdf-scheme KEY-AGREE ::= { 2086 IDENTIFIER dhSinglePass-cofactorDH-sha384kdf-scheme 2087 PARAMS TYPE KeyWrapAlgorithm ARE required 2088 UKM TYPE -- unecndoded data -- IS preferredPresent 2089 SMIME CAPS { TYPE KeyWrapAlgorithm 2090 IDENTIFIED BY 2091 dhSinglePass-cofactorDH-sha384kdf-scheme } 2092 } 2093 dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 2094 secg-scheme 14 2 } 2096 kaa-dhSinglePass-cofactorDH-sha512kdf-scheme KEY-AGREE ::= { 2097 IDENTIFIER dhSinglePass-cofactorDH-sha512kdf-scheme 2098 PARAMS TYPE KeyWrapAlgorithm ARE required 2099 UKM TYPE -- unecndoded data -- IS preferredPresent 2100 SMIME CAPS { TYPE KeyWrapAlgorithm 2101 IDENTIFIED BY 2102 dhSinglePass-cofactorDH-sha512kdf-scheme } 2103 } 2105 dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 2106 secg-scheme 14 3 } 2108 -- 2109 -- MQV Single Pass, Cofactor, with KDFs 2110 -- 2112 kaa-mqvSinglePass-sha1kdf-scheme KEY-AGREE ::= { 2113 IDENTIFIER mqvSinglePass-sha1kdf-scheme 2114 PARAMS TYPE KeyWrapAlgorithm ARE required 2115 UKM TYPE -- unecndoded data -- IS preferredPresent 2116 SMIME CAPS { TYPE KeyWrapAlgorithm 2117 IDENTIFIED BY mqvSinglePass-sha1kdf-scheme } 2118 } 2120 mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= { 2121 x9-63-scheme 16 } 2123 kaa-mqvSinglePass-sha224kdf-scheme KEY-AGREE ::= { 2124 IDENTIFIER mqvSinglePass-sha224kdf-scheme 2125 PARAMS TYPE KeyWrapAlgorithm ARE required 2126 UKM TYPE -- unecndoded data -- IS preferredPresent 2127 SMIME CAPS { TYPE KeyWrapAlgorithm 2128 IDENTIFIED BY mqvSinglePass-sha224kdf-scheme } 2129 } 2131 mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= { 2132 secg-scheme 15 0 } 2134 kaa-mqvSinglePass-sha256kdf-scheme KEY-AGREE ::= { 2135 IDENTIFIER mqvSinglePass-sha256kdf-scheme 2136 PARAMS TYPE KeyWrapAlgorithm ARE required 2137 UKM TYPE -- unecndoded data -- IS preferredPresent 2138 SMIME CAPS { TYPE KeyWrapAlgorithm 2139 IDENTIFIED BY mqvSinglePass-sha256kdf-scheme } 2140 } 2142 mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= { 2143 secg-scheme 15 1 } 2145 kaa-mqvSinglePass-sha384kdf-scheme KEY-AGREE ::= { 2146 IDENTIFIER mqvSinglePass-sha384kdf-scheme 2147 PARAMS TYPE KeyWrapAlgorithm ARE required 2148 UKM TYPE -- unecndoded data -- IS preferredPresent 2149 SMIME CAPS { TYPE KeyWrapAlgorithm 2150 IDENTIFIED BY mqvSinglePass-sha384kdf-scheme } 2151 } 2153 mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= { 2154 secg-scheme 15 2 } 2156 kaa-mqvSinglePass-sha512kdf-scheme KEY-AGREE ::= { 2157 IDENTIFIER mqvSinglePass-sha512kdf-scheme 2158 PARAMS TYPE KeyWrapAlgorithm ARE required 2159 UKM TYPE -- unecndoded data -- IS preferredPresent 2160 SMIME CAPS { TYPE KeyWrapAlgorithm 2161 IDENTIFIED BY mqvSinglePass-sha512kdf-scheme } 2162 } 2164 mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= { 2165 secg-scheme 15 3 } 2167 -- 2168 -- Key Wrap Algorithms 2169 -- 2171 KeyWrapAlgorithm ::= KeyWrapAlgs 2173 KeyWrapAlgs KEY-WRAP ::= { 2174 kwa-3des | 2175 kwa-aes128 | 2176 kwa-aes192 | 2177 kwa-aes256, 2178 ... -- Extensible 2179 } 2180 -- 2181 -- Content Encryption Algorithms 2182 -- 2184 -- Constrains the EnvelopedData EncryptedContentInfo encryptedContent 2185 -- field and the AuthEnvelopedData EncryptedContentInfo 2186 -- contentEncryptionAlgorithm field 2188 -- ContentEncryptionAlgorithms CONTENT-ENCRYPTION ::= { 2189 -- cea-des-ede3-cbc | 2190 -- cea-aes128-cbc | 2191 -- cea-aes192-cbc | 2192 -- cea-aes256-cbc | 2193 -- cea-aes128-ccm | 2194 -- cea-aes192-ccm | 2195 -- cea-aes256-ccm | 2196 -- cea-aes128-gcm | 2197 -- cea-aes192-gcm | 2198 -- cea-aes256-gcm, 2199 -- ... -- Extensible 2200 -- } 2202 -- des-ede3-cbc and aes*-cbc are used with EnvelopedData and 2203 -- EncryptedData 2204 -- aes*-ccm are used with AuthEnvelopedData 2205 -- aes*-gcm are used with AuthEnvelopedData 2206 -- (where * is 128, 192, and 256) 2208 -- 2209 -- Message Authentication Code Algorithms 2210 -- 2212 -- Constrains the AuthenticatedData 2213 -- MessageAuthenticationCodeAlgorithm field 2214 -- 2216 -- MessageAuthenticationCodeAlgorithms MAC-ALGORITHM ::= { 2217 -- maca-sha1 | 2218 -- maca-sha224 | 2219 -- maca-sha256 | 2220 -- maca-sha384 | 2221 -- maca-sha512, 2222 -- ... -- Extensible 2223 -- } 2224 -- 2225 -- Originator Public Key Algorithms 2226 -- 2228 -- Constraints on KeyAgreeRecipientInfo OriginatorIdentifierOrKey 2229 -- OriginatorPublicKey algorithm field 2231 -- PARAMS are NULL 2233 OriginatorPKAlgorithms PUBLIC-KEY ::= { 2234 opka-ec, 2235 ... -- Extensible 2236 } 2238 opka-ec PUBLIC-KEY ::={ 2239 IDENTIFIER id-ecPublicKey 2240 KEY ECPoint 2241 PARAMS TYPE CHOICE { n NULL, p ECParameters } ARE preferredAbsent 2242 } 2244 -- Format for both ephemeral and static public keys 2246 -- ECPoint ::= OCTET STRING 2248 -- ECParameters ::= CHOICE { 2249 -- namedCurve CURVE.&id({NamedCurve}) 2250 -- commented out in [PKI-ALG] implicitCurve NULL 2251 -- commented out in [PKI-ALG] specifiedCurve SpecifiedECDomain 2252 -- commented out in [PKI-ALG] ... Extensible 2253 -- } 2254 -- implicitCurve and specifiedCurve MUST NOT be used in PKIX. 2255 -- Details for SpecifiedECDomain can be found in [X9.62]. 2256 -- Any future additions to this CHOICE should be coordinated 2257 -- with ANSI X.9. 2259 -- Format of KeyAgreeRecipientInfo ukm field when used with 2260 -- ECMQV 2262 MQVuserKeyingMaterial ::= SEQUENCE { 2263 ephemeralPublicKey OriginatorPublicKey, 2264 addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL 2265 } 2266 -- 'SharedInfo' for input to KDF when using ECDH and ECMQV with 2267 -- EnvelopedData, AuthenticatedData, or AuthEnvelopedData 2269 ECC-CMS-SharedInfo ::= SEQUENCE { 2270 keyInfo AlgorithmIdentifier { KeyWrapAlgorithm }, 2271 entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL, 2272 suppPubInfo [2] EXPLICIT OCTET STRING 2273 } 2275 END 2277 Appendix B Changes since RFC 3278 2279 The following summarizes the changes: 2281 - Abstract: The basis of the document was changed to refer to NIST 2282 FIPS 186-3 and SP800-56A. However, to maintain backwards 2283 capability the Key Derivation Function from ANSI/SEC1 is 2284 retained. 2286 - Section 1: A bullet was added to address AuthEnvelopedData. 2288 - Section 2.1: A sentence was added to indicate FIPS180-3 is used 2289 with ECDSA. Replaced reference to ANSI X9.62 with FIPS186-3. 2291 - Section 2.1.1: The permitted digest algorithms were expanded from 2292 SHA-1 to SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. 2294 - Section 2.1.2 and 2.1.3: The bullet addressing integer "e" was 2295 deleted. 2297 - Section 3: Added explanation of why static-static ECDH is not 2298 included. 2300 - Section 3.1: The reference for DH was changed from CMS to CMS- 2301 ALG. Provided text to indicate fields of EnvelopedData are as 2302 in CMS. 2304 - Section 3.1.1: The text was updated to include description of all 2305 KeyAgreeRecipientInfo fields. Parameters for id-ecPublicKey 2306 field changed from NULL to absent or ECParameter. Additional 2307 information about ukm was added. 2309 - Section 3.2: The sentence describing the advantages of 1-Pass 2310 ECMQV was rewritten. 2312 - Section 3.2.1: The text was updated to include description of all 2313 fields. Parameters for id-ecPublicKey field changed from NULL 2314 to absent or ECPoint. 2316 - Sections 3.2.2 and 4.1.2: The re-use of ephemeral keys paragraph 2317 was reworded. 2319 - Section 4.1: The sentences describing the advantages of 1-Pass 2320 ECMQV was moved to Section 4. 2322 - Section 4.1.2: The note about the attack was moved to Section 4. 2324 - Section 4.2: This section was added to address AuthEnvelopedData 2325 with ECMQV. 2327 - Section 5: This section was moved to Section 8. The 1st 2328 paragraph was modified to recommend both SignedData and 2329 EnvelopedData. The requirements were updated for hash 2330 algorithms and recommendations for matching curves and hash 2331 algorithms. Also the requirements were expanded to indicate 2332 which ECDH and ECMQV variants, key wrap algorithms, and content 2333 encryption algorithms are required for each of the content types 2334 used in this document. The permitted digest algorithms used in 2335 key derivations functions (KDFs) were expanded from SHA-1 to 2336 SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. 2338 - Section 6 (formerly 7): This section was updated to allow for 2339 SMIMECapabilities to be present in certificates. The S/MIME 2340 capabilities for ECDSA with SHA-224, SHA-256, SHA-384, and SHA- 2341 512 were added to the list of S/MIME Capabilities. Also updated 2342 to include S/MIME capabilities for ECDH and ECMQV using the SHA- 2343 224, SHA-256, SHA-384, and SHA-512 algorithms as the KDF. 2345 - Section 7.1 (formerly 8.1): Added sub-sections for digest, 2346 signature, originator public key, key agreement, content 2347 encryption, key wrap, and message authentication code 2348 algorithms. Pointed to algorithms and parameters in appropriate 2349 documents for: SHA-224, SHA-256, SHA-384, and SHA-512 as well as 2350 SHA-224, SHA-256, SHA-384, and SHA-512 with ECDSA. Also added 2351 algorithm identifiers for ECDH std, ECDH cofactor, and ECMQV 2352 with SHA-224, SHA-256, SHA-384, and SHA-512 algorithms as the 2353 KDF. Changed id-ecPublicKey parameters to be absent, NULL, and 2354 ECParameters and if present the originator's ECParameters must 2355 match the recipient's ECParameters. 2357 - Section 7.2 (formerly 8.2): Updated to include AuthEnvelopedData. 2358 Also, added text to address support requirement for compressed, 2359 uncompressed, and hybrid keys, changed pointers from ANSI X9.61 2360 to PKIX (where ECDSA-Sig-Value is imported), changed pointers 2361 from SECG to NIST specs, and updated example of suppPubInfo to 2362 be AES-256. keyInfo's parameters changed from NULL to any 2363 associated parameters (AES wraps have absent parameters). 2365 - Section 9: Replaced text, which was a summary paragraph, with an 2366 updated security considerations section. Paragraph referring to 2367 definitions of SHA-224, SHA-256, SHA-384, and SHA-512 is 2368 deleted. 2370 - Updated references. 2372 - Added ASN.1 modules. 2374 - Updated acknowledgements section. 2376 Acknowledgements 2378 The methods described in this document are based on work done by the 2379 ANSI X9F1 working group. The authors wish to extend their thanks to 2380 ANSI X9F1 for their assistance. The authors also wish to thank Peter 2381 de Rooij for his patient assistance. The technical comments of 2382 Francois Rousseau were valuable contributions. 2384 Many thanks go out to the other authors of RFC 3278: Simon Blake- 2385 Wilson and Paul Lambert. Without RFC 3278 this version wouldn't 2386 exist. 2388 The authors also wish to thank Alfred Hoenes, Paul Hoffman, Russ 2389 Housley, and Jim Schaad for their valuable input. 2391 Author's Addresses 2393 Sean Turner 2395 IECA, Inc. 2396 3057 Nutley Street, Suite 106 2397 Fairfax, VA 22031 2398 USA 2400 Email: turners@ieca.com 2402 Daniel R. L. Brown 2404 Certicom Corp 2405 5520 Explorer Drive #400 2406 Mississauga, ON L4W 5L1 2407 CANADA 2409 Email: dbrown@certicom.com 2411 Full Copyright Statement 2413 Copyright (C) The IETF Trust (2008). 2415 This document is subject to the rights, licenses and restrictions 2416 contained in BCP 78, and except as set forth therein, the authors 2417 retain all their rights. 2419 This document and the information contained herein are provided on an 2420 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2421 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2422 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2423 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2424 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2425 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2427 Intellectual Property 2429 The IETF takes no position regarding the validity or scope of any 2430 Intellectual Property Rights or other rights that might be claimed to 2431 pertain to the implementation or use of the technology described in 2432 this document or the extent to which any license under such rights 2433 might or might not be available; nor does it represent that it has 2434 made any independent effort to identify any such rights. Information 2435 on the procedures with respect to rights in RFC documents can be 2436 found in BCP 78 and BCP 79. 2438 Copies of IPR disclosures made to the IETF Secretariat and any 2439 assurances of licenses to be made available, or the result of an 2440 attempt made to obtain a general license or permission for the use of 2441 such proprietary rights by implementers or users of this 2442 specification can be obtained from the IETF on-line IPR repository at 2443 http://www.ietf.org/ipr. 2445 The IETF invites any interested party to bring to its attention any 2446 copyrights, patents or patent applications, or other proprietary 2447 rights that may cover technology that may be required to implement 2448 this standard. Please address the information to the IETF at 2449 ietf-ipr@ietf.org. 2451 Acknowledgment 2453 Funding for the RFC Editor function is provided by the IETF 2454 Administrative Support Activity (IASA).