idnits 2.17.1 draft-ietf-smime-3278bis-01.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 2023. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2034. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2041. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2047. 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC3278, but the abstract doesn't seem to mention this, which it should. 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 (June 30, 2008) is 5772 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 1848 -- Looks like a reference, but probably isn't: '2' on line 1849 == Unused Reference: 'MSG' is defined on line 1037, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) Summary: 2 errors (**), 0 flaws (~~), 2 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 June 30, 2008 4 Obsoletes: 3278 (once approved) 5 Expires: December 30, 2008 7 Use of Elliptic Curve Cryptography (ECC) Algorithms 8 in Cryptographic Message Syntax (CMS) 9 draft-ietf-smime-3278bis-01.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 December 30, 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 ANSI X9.62 standard, 47 developed by the ANSI X9F1 working group, the IEEE 1363 standard, and 48 the SEC 1 standard. 50 Discussion 52 This draft is being discussed on the 'ietf-smime' mailing list. To 53 subscribe, send a message to ietf-smime-request@imc.org with the 54 single word subscribe in the body of the message. There is a Web site 55 for the mailing list at . 57 Table of Contents 59 1. Introduction...................................................2 60 1.1. Requirements Terminology..................................3 61 1.2. Changes since RFC 3278....................................3 62 2. SignedData using ECC...........................................4 63 2.1. SignedData using ECDSA....................................4 64 3. EnvelopedData using ECC Algorithms.............................6 65 3.1. EnvelopedData using (ephemeral-static) ECDH...............6 66 3.2. EnvelopedData using 1-Pass ECMQV..........................7 67 4. AuthenticatedData and AuthEnvelopedData using ECC..............9 68 4.1. AuthenticatedData using 1-pass ECMQV......................9 69 4.2. AuthEnvelopedData using 1-pass ECMQV.....................10 70 5. Recommended Algorithms and Elliptic Curves....................10 71 6. Certificates using ECC........................................12 72 7. SMIMECapabilities Attribute and ECC...........................12 73 8. ASN.1 Syntax..................................................15 74 8.1. Algorithm Identifiers....................................15 75 8.2. Other Syntax.............................................18 76 9. Security Considerations.......................................19 77 10. IANA Considerations..........................................24 78 11. References...................................................24 79 11.1. Normative...............................................24 80 11.2. Informative.............................................26 81 Appendix A ASN.1 Modules.........................................27 82 Appendix A.1 1988 ASN.1 Module................................27 83 Appendix A.2 2004 ASN.1 Module................................34 85 1. Introduction 87 The Cryptographic Message Syntax (CMS) is cryptographic algorithm 88 independent. This specification defines a profile for the use of 89 Elliptic Curve Cryptography (ECC) public key algorithms in the CMS. 90 The ECC algorithms are incorporated into the following CMS content 91 types: 93 - 'SignedData' to support ECC-based digital signature methods 94 (ECDSA) to sign content 96 - 'EnvelopedData' to support ECC-based public-key agreement 97 methods (ECDH and ECMQV) to generate pairwise key-encryption 98 keys to encrypt content-encryption keys used for content 99 encryption 101 - 'AuthenticatedData' to support ECC-based public-key agreement 102 methods (ECMQV) to generate pairwise key-encryption keys to 103 encrypt MAC keys used for content authentication and integrity. 105 Certification of EC public keys is also described to provide public- 106 key distribution in support of the specified techniques. 108 1.1. Requirements Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [MUST]. 114 1.2. Changes since RFC 3278 116 The following summarizes the changes: 118 - Section 2.1 added sentence indicating SHA is used with EDSA. 120 - Section 2.1.1 limited the digest algorithm to SHA-1. This document 121 expands the allowed algorithms to SHA-224, SHA-256, SHA-384, and 122 SHA-512. 124 - Section 2.1.2 and 2.1.3 - Delete e paragraph and update ANSI X9.42 125 references. 127 - Section 3.1 - Updates reference to CMS-ALG vice CMS for DH. 129 - Section 3.1.1 used SHA1 in the KDF with ECDH std and cofactor 130 methods. This document expands the set of allowed algorithms by 131 adding SHA-224, SHA-256, SHA-384, and SHA-512. 133 - Section 3.2.1 used SHA1 in the KDF with ECMQV. This document 134 expands the set of allowed algorithms by adding SHA-224, SHA-256, 135 SHA-384, and SHA-512. 137 - Section 4.2 was added to address ECMQV use of AuthEnvelopedData. 139 - Section 5 is updated to include requirements for hash algorithms 140 and recommendations for matching curves and hash algorithms. It 141 also was expanded to indicate which ECDH and ECMQV variants, key 142 wrap algorithms, and content encryption algorithms are required 143 for each of the content types used in this document.. 145 - Section 7 is updated to include S/MIME capabilities for ECDSA with 146 SHA-224, SHA-256, SHA-384, and SHA-512. It was also updated to 147 include S/MIME capabilities for ECDH and ECMQV using SHA2 148 algorithms as the KDF. 150 - Section 8.1 listed the algorithm identifiers for SHA-1 and SHA-1 151 with ECDSA. This document adds algorithm identifiers for SHA-224, 152 SHA-256, SHA-384, and SHA-512 as well as SHA-224, SHA-256, SHA- 153 384, and SHA-512 with ECDSA. This document also updates the list 154 of algorithm identifiers for ECDH std, ECDH cofactor, and ECMQV 155 with SHA2 algorithms as the KDF. 157 - Deleted summary paragraph. 159 - Updated references. 161 - Updated security considerations. Security considerations paragraph 162 referring to definitions of SHA-224, SHA-256, SHA-384, and SHA- 163 512 is deleted. 165 - Added ASN.1 modules. 167 - Updated acknowledgements section. 169 2. SignedData using ECC 171 This section describes how to use ECC algorithms with the CMS 172 SignedData format to sign data. 174 2.1. SignedData using ECDSA 176 This section describes how to use the Elliptic Curve Digital 177 Signature Algorithm (ECDSA) with SignedData. ECDSA is specified in 178 [X9.62]. The method is the elliptic curve analog of the Digital 179 Signature Algorithm (DSA) [DSS]. ECDSA is used with the Secure Hash 180 Algorithm (SHA) [SHS]. 182 In an implementation that uses ECDSA with CMS SignedData, the 183 following techniques and formats MUST be used. 185 2.1.1. Fields of the SignedData 187 When using ECDSA with SignedData, the fields of SignerInfo are as in 188 [CMS], but with the following restrictions: 190 digestAlgorithm MUST contain the algorithm identifier of the hash 191 algorithm (see Section 8.1) which MUST be one of the following: 192 id-sha1 identifies the SHA-1 hash algorithm, id-sha224 identifies 193 the SHA-224 hash algorithm, id-sha256 identifies the SHA-256 hash 194 algorithm, id-sha384 identifies the SHA-384 algorithm, and id- 195 sha512 identifies the SHA-512 algorithm. 197 signatureAlgorithm contains the signature algorithm identifier 198 (see Section 8.1): ecdsa-with-SHA1, ecdsa-with-SHA224, ecdsa- 199 with-SHA256, ecdsa-with-SHA384, or ecdsa-with-SHA512. 201 signature MUST contain the DER encoding (as an octet string) of a 202 value of the ASN.1 type ECDSA-Sig-Value (see Section 8.2). 204 When using ECDSA, the SignedData certificates field MAY include the 205 certificate(s) for the EC public key(s) used in the generation of the 206 ECDSA signatures in SignedData. ECC certificates are discussed in 207 Section 6. 209 2.1.2. Actions of the sending agent 211 When using ECDSA with SignedData, the sending agent uses the message 212 digest calculation process and signature generation process for 213 SignedData that are specified in [CMS]. To sign data, the sending 214 agent uses the signature method specified in [X9.62, Section 7.3]. 216 The sending agent encodes the resulting signature using the ECDSA- 217 Sig-Value syntax (see Section 8.2) and places it in the 218 SignerInfosignature field. 220 2.1.3. Actions of the receiving agent 222 When using ECDSA with SignedData, the receiving agent uses the 223 message digest calculation process and signature verification process 224 for SignedData that are specified in [CMS]. To verify SignedData, 225 the receiving agent uses the signature verification method specified 226 in [X9.62, Section 7.3]. 228 In order to verify the signature, the receiving agent retrieves the 229 integers r and s from the SignerInfo signature field of the received 230 message. 232 3. EnvelopedData using ECC Algorithms 234 This section describes how to use ECC algorithms with the CMS 235 EnvelopedData format. 237 3.1. EnvelopedData using (ephemeral-static) ECDH 239 This section describes how to use the ephemeral-static Elliptic Curve 240 Diffie-Hellman (ECDH) key agreement algorithm with EnvelopedData. 241 Ephemeral-static ECDH is specified in [SEC1] and [IEEE1363]. 242 Ephemeral-static ECDH is the elliptic curve analog of the 243 ephemeral-static Diffie-Hellman key agreement algorithm specified 244 jointly in the documents [CMS-ALG, Section 4.1.1] and [CMS-DH]. 246 In an implementation that uses ECDH with CMS EnvelopedData with key 247 agreement, the following techniques and formats MUST be used. 249 3.1.1. Fields of KeyAgreeRecipientInfo 251 When using ephemeral-static ECDH with EnvelopedData, the fields of 252 KeyAgreeRecipientInfo are as in [CMS], but with the following 253 restrictions: 255 originator MUST be the alternative originatorKey. The 256 originatorKey algorithm field MUST contain the id-ecPublicKey 257 object identifier (see Section 8.1) with NULL parameters. The 258 originatorKey publicKey field MUST contain the DER-encoding of a 259 value of the ASN.1 type ECPoint (see Section 8.2), which 260 represents the sending agent's ephemeral EC public key. 262 keyEncryptionAlgorithm MUST contain the key encryption algorithm 263 object identifier (see Section 8.1). The parameters field 264 contains KeyWrapAlgorithm. The KeyWrapAlgorithm is the algorithm 265 identifier that indicates the symmetric encryption algorithm used 266 to encrypt the content-encryption key (CEK) with the 267 key-encryption key (KEK). Algorithm requirements are found in 268 paragraph 5. 270 3.1.2. Actions of the sending agent 272 When using ephemeral-static ECDH with EnvelopedData, the sending 273 agent first obtains the recipient's EC public key and domain 274 parameters (e.g. from the recipient's certificate). The sending 275 agent then determines an integer "keydatalen", which is the 276 KeyWrapAlgorithm symmetric key-size in bits, and also a bit string 277 "SharedInfo", which is the DER encoding of ECC-CMS-SharedInfo (see 278 Section 8.2). The sending agent then performs the key deployment and 279 the key agreement operation of the Elliptic Curve Diffie-Hellman 280 Scheme specified in [SEC1, Section 6.1]. 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 8.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 3.1.3. Actions of the receiving agent 292 When using ephemeral-static ECDH with EnvelopedData, the receiving 293 agent determines the bit string "SharedInfo", which is the DER 294 encoding of ECC-CMS-SharedInfo (see Section 8.2), and the integer 295 "keydatalen" from the key-size, in bits, of the KeyWrapAlgorithm. The 296 receiving agent retrieves the ephemeral EC public key from the bit 297 string KeyAgreeRecipientInfo originator, with a value of the type 298 ECPoint (see Section 8.2) encapsulated as a bit string. The 299 receiving agent performs the key agreement operation of the Elliptic 300 Curve Diffie-Hellman Scheme specified in [SEC1, Section 6.1]. As a 301 result, the receiving agent obtains a shared secret bit string "K", 302 which is used as the pairwise key-encryption key to unwrap the CEK. 304 3.2. EnvelopedData using 1-Pass ECMQV 306 This section describes how to use the 1-Pass elliptic curve MQV 307 (ECMQV) key agreement algorithm with EnvelopedData. ECMQV is 308 specified in [SEC1] and [IEEE1363]. Like the KEA algorithm [CMS- 309 KEA], 1-Pass ECMQV uses three key pairs: an ephemeral key pair, a 310 static key pair of the sending agent, and a static key pair of the 311 receiving agent. An advantage of using 1-Pass ECMQV is that it can 312 be used with both EnvelopedData and AuthenticatedData. 314 In an implementation that uses 1-Pass ECMQV with CMS EnvelopedData 315 with key agreement, the following techniques and formats MUST be 316 used. 318 3.2.1. Fields of KeyAgreeRecipientInfo 320 When using 1-Pass ECMQV with EnvelopedData, the fields of 321 KeyAgreeRecipientInfo are: 323 originator identifies the static EC public key of the sender. It 324 SHOULD be one of the alternatives, issuerAndSerialNumber or 325 subjectKeyIdentifier, and point to one of the sending agent's 326 certificates. 328 ukm MUST be present. The ukm field MUST contain an octet string 329 which is the DER encoding of the type MQVuserKeyingMaterial (see 330 Section 8.2). The MQVuserKeyingMaterial ephemeralPublicKey 332 algorithm field MUST contain the id-ecPublicKey object identifier 333 (see Section 8.1) with NULL parameters field. The 334 MQVuserKeyingMaterial ephemeralPublicKey publicKey field MUST 335 contain the DER-encoding of the ASN.1 type ECPoint (see Section 336 8.2) representing the sending agent's ephemeral EC public key. 337 The MQVuserKeyingMaterial addedukm field, if present, SHOULD 338 contain an octet string of additional user keying material of the 339 sending agent. 341 keyEncryptionAlgorithm MUST be the key encryption algorithm 342 identifier (see Section 8.1), with the parameters field 343 KeyWrapAlgorithm. The KeyWrapAlgorithm indicates the symmetric 344 encryption algorithm used to encrypt the CEK with the KEK 345 generated using the 1-Pass ECMQV algorithm. Algorithm 346 requirements are found in paragraph 5. 348 3.2.2. Actions of the sending agent 350 When using 1-Pass ECMQV with EnvelopedData, the sending agent first 351 obtains the recipient's EC public key and domain parameters, (e.g. 352 from the recipient's certificate) and checks that the domain 353 parameters are the same. The sending agent then determines an 354 integer "keydatalen", which is the KeyWrapAlgorithm symmetric key- 355 size in bits, and also a bit string "SharedInfo", which is the DER 356 encoding of ECC-CMS-SharedInfo (see Section 8.2). The sending agent 357 then performs the key deployment and key agreement operations of the 358 Elliptic Curve MQV Scheme specified in [SEC1, Section 6.2]. As a 359 result, the sending agent obtains: 361 - an ephemeral public key, which is represented as a value of type 362 ECPoint (see Section 8.2), encapsulated in a bit string, placed 363 in an MQVuserKeyingMaterial ephemeralPublicKey publicKey field 364 (see Section 8.2), and 366 - a shared secret bit string "K", which is used as the pairwise 367 key-encryption key for that recipient, as specified in [CMS]. 369 The ephemeral public key can be re-used with an AuthenticatedData for 370 greater efficiency. 372 3.2.3. Actions of the receiving agent 374 When using 1-Pass ECMQV with EnvelopedData, the receiving agent 375 determines the bit string "SharedInfo", which is the DER encoding of 376 ECC-CMS-SharedInfo (see Section 8.2), and the integer "keydatalen" 377 from the key-size, in bits, of the KeyWrapAlgorithm. The receiving 378 agent then retrieves the static and ephemeral EC public keys of the 379 originator, from the originator and ukm fields as described in field 380 and checks that the domain parameters are the same. The receiving 381 agent then performs the key agreement operation of the Elliptic Curve 382 MQV Scheme [SEC1, Section 6.2]. As a result, the receiving agent 383 obtains a shared secret bit string "K" which is used as the pairwise 384 key-encryption key to unwrap the CEK. 386 4. AuthenticatedData and AuthEnvelopedData using ECC 388 This section describes how to use ECC algorithms with the CMS 389 AuthenticatedData format. AuthenticatedData lacks non-repudiation, 390 and so in some instances is preferable to SignedData. (For example, 391 the sending agent might not want the message to be authenticated when 392 forwarded.) 394 This section also describes how to use ECC algorithms with the CMS 395 AuthEnvelopedData format [CMS-AUTHENV]. AuthEnvelopedData supports 396 authentication and encryption, and in some instances is preferable to 397 signing and than encrypting data. 399 4.1. AuthenticatedData using 1-pass ECMQV 401 This section describes how to use the 1-Pass elliptic curve MQV 402 (ECMQV) key agreement algorithm with AuthenticatedData. ECMQV is 403 specified in [SEC1]. An advantage of using 1-Pass ECMQV is that it 404 can be used with EnvelopedData, AuthenticatedData, and 405 AuthEnvelopedData. 407 4.1.1. Fields of the KeyAgreeRecipientInfo 409 The AuthenticatedData KeyAgreeRecipientInfo fields are used in the 410 same manner as the fields for the corresponding EnvelopedData 411 KeyAgreeRecipientInfo fields of Section 3.2.1 of this document. 413 4.1.2. Actions of the sending agent 415 The sending agent uses the same actions as for EnvelopedData with 416 1-Pass ECMQV, as specified in Section 3.2.2 of this document. 418 The ephemeral public key can be re-used with an EnvelopedData for 419 greater efficiency. 421 Note: if there are multiple recipients, an attack is possible where 422 one recipient modifies the content without other recipients noticing 423 [BON]. A sending agent who is concerned with such an attack SHOULD 424 use a separate AuthenticatedData for each recipient. 426 4.1.3. Actions of the receiving agent 428 The receiving agent uses the same actions as for EnvelopedData with 429 1-Pass ECMQV, as specified in Section 3.2.3 of this document. 431 Note: see Note in Section 4.1.2. 433 4.2. AuthEnvelopedData using 1-pass ECMQV 435 This section describes how to use the 1-Pass elliptic curve MQV 436 (ECMQV) key agreement algorithm with AuthEnvelopedData. ECMQV is 437 specified in [SEC1]. An advantage of using 1-Pass ECMQV is that it 438 can be used with EnvelopedData, AuthenticatedData, and 439 AuthEnvelopedData. 441 4.2.1. Fields of the KeyAgreeRecipientInfo 443 The AuthEnvelopedData KeyAgreeRecipientInfo fields are used in the 444 same manner as the fields for the corresponding EnvelopedData 445 KeyAgreeRecipientInfo fields of Section 3.2.1 of this document. 447 4.2.2. Actions of the sending agent 449 The sending agent uses the same actions as for EnvelopedData with 1- 450 Pass ECMQV, as specified in Section 3.2.2 of this document. 452 The ephemeral public key can be re-used with an EnvelopedData for 453 greater efficiency. 455 4.2.3. Actions of the receiving agent 457 The receiving agent uses the same actions as for EnvelopedData with 458 1-Pass ECMQV, as specified in Section 3.2.3 of this document. 460 5. Recommended Algorithms and Elliptic Curves 462 Implementations of this specification MUST implement either 463 SignedData with ECDSA or EnvelopedData with ephemeral-static ECDH. 464 Implementations of this specification SHOULD implement both 465 SignedData with ECDSA and EnvelopedData with ephemeral-static ECDH. 466 Implementations MAY implement the other techniques specified, such as 467 AuthenticatedData and 1-Pass ECMQV. 469 Furthermore, in order to encourage interoperability, implementations 470 SHOULD use the elliptic curve domain parameters specified by ANSI 471 [X9.62], NIST [DSS] and SECG [SEC2]. It is RECOMMENDED that the 472 P-256 curve be used with SHA-256, the P-384 curve be used with 473 SHA-384, and the P-521 curve be used with SHA-512. 475 Implementations of this specification MUST implement the SHA-256 hash 476 algorithm. The SHA-1, SHA-224, SHA-384, SHA-512 hash algorithms MAY 477 be supported. 479 When ECDSA, ECDH, or ECMQV is used, it is RECOMMENDED that the 480 P-256 curve be used with SHA-256, the P-384 curve be used with 481 SHA-384, and the P-521 curve be used with SHA-512. 483 Implementations of this specification that support EnvelopedData with 484 ephemeral-static ECDH standard primitive MUST support the 485 dhSinglePass-stdDH-sha256kdf-scheme algorithm. They MUST also support 486 the id-aes128-wrap key wrap and id-aes128-cbc content encryption 487 algorithms. The dhSinglePass-stdDH-sha1kdf-scheme, dhSinglePass- 488 stdDH-sha224kdf-scheme, dhSinglePass-stdDH-sha384kdf-scheme, and 489 dhSinglePass-stdDH-sha512kdf-scheme algorithms MAY be supported. 490 Likewise, the id-alg-CMS3DESwrap, id-aes192-wrap, and id-aes256-wrap 491 key wrap algorithms and the id-aes192-cbc and id-aes256-cbc content 492 encryption algorithms MAY be supported. 494 Implementations of this specification that support EnvelopedData with 495 ephemeral-static ECDH cofactor primitive MUST support the 496 dhSinglePass-cofactorDH-sha256kdf-scheme algorithm. They MUST also 497 support the id-aes128-wrap key wrap and id-aes128-cbc content 498 encryption algorithms. The dhSinglePass-cofactorDH-sha1kdf-scheme, 499 dhSinglePass-cofactorDH-sha224kdf-scheme, dhSinglePass-cofactorDH- 500 sha384kdf-scheme, and dhSinglePass-cofactorDH-sha512kdf-scheme 501 algorithms MAY be supported. Likewise, the id-alg-CMS3DESwrap, id- 502 aes192-wrap, and id-aes256-wrap MAY be supported. 504 Implementations of this specification that support EnvelopedData with 505 ECMQV MUST support the mqvSinglePass-sha256kdf-scheme algorithm. They 506 MUST also support the id-aes128-wrap and id-aes128-cbc algorithms. 507 The mqvSinglePass-sha1kdf-scheme, mqvSinglePass-sha224kdf-scheme, 508 mqvSinglePass-sha384kdf-scheme, and mqvSinglePass-sha512kdf-scheme 509 algorithms MAY be supported. Likewise, the id-alg-CMS3DESwrap, id- 510 aes192-wrap, and id-aes256-wrap key wrap algorithms and the id- 511 aes192-cbc and id-aes256-cbc content encryption algorithms MAY be 512 supported. 514 Implementations of this specification that support AuthenticatedData 515 with ECMQV MUST support the 516 mqvSinglePass-sha256kdf-scheme algorithm. They MUST also support the 517 id-aes128-wrap key wrap, id-aes128-cbc content encryption, and id- 518 hmacWithSHA256 message digest algorithms. The mqvSinglePass-sha1kdf- 519 scheme, mqvSinglePass-sha224kdf-scheme, mqvSinglePass-sha384kdf- 520 scheme, and mqvSinglePass-sha512kdf-scheme algorithms MAY be 521 supported. Likewise, the id-alg-CMS3DESwrap, id-aes192-wrap, and id- 522 aes256-wrap key wrap algorithms and the id-aes192-cbc and id-aes256- 523 cbc content encryption algorithms MAY be supported. The 524 id-hmacWithSHA1, id-hmacWithSHA224, id-hmacWithSHA384, and id- 525 hmacWithSHA512 MAY be supported. 527 Implementations of this specification that support AuthEnvelopedData 528 with ECMQV MUST support the 529 mqvSinglePass-sha256kdf-scheme algorithm. They MUST also support the 530 id-aes128-wrap key wrap and id-aes128-cbc content encryption 531 algorithm. The mqvSinglePass-sha1kdf-scheme, mqvSinglePass-sha224kdf- 532 scheme, mqvSinglePass-sha384kdf-scheme, and mqvSinglePass-sha512kdf- 533 scheme algorithms MAY be supported. Likewise, the id-alg-CMS3DESwrap, 534 id-aes192-wrap, and id-aes256-wrap key wrap algorithms and the id- 535 aes192-cbc and id-aes256-cbc content encryption algorithms MAY be 536 supported. 538 6. Certificates using ECC 540 Internet X.509 certificates [PKI] can be used in conjunction with 541 this specification to distribute agents' public keys. The use of ECC 542 algorithms and keys within X.509 certificates is specified in 543 [PKI-ALG]. 545 7. SMIMECapabilities Attribute and ECC 547 A sending agent MAY announce to receiving agents that it supports one 548 or more of the ECC algorithms in this document by using the 549 SMIMECapabilities signed attribute [MSG, Section 2.5.2]. 551 The SMIMECapability value to indicate support for the ECDSA signature 552 algorithm is the SEQUENCE with the capabilityID field containing the 553 object identifiers ecdsa-with-SHA* object identifiers (where * is 1, 554 224, 256, 384, or 512) all with NULL parameters. The DER encodings 555 are: 557 ecdsa-with-SHA1: 30 0b 06 07 2a 86 48 ce 3d 04 01 05 00 559 ecdsa-with-SHA224: 30 0c 06 08 2a 86 48 ce 3d 04 03 01 05 00 561 ecdsa-with-SHA256: 30 0c 06 08 2a 86 48 ce 3d 04 03 02 05 00 563 ecdsa-with-SHA384: 30 0c 06 08 2a 86 48 ce 3d 04 03 03 05 00 565 ecdsa-with-SHA512: 30 0c 06 08 2a 86 48 ce 3d 04 03 04 05 00 567 The SMIMECapability value to indicate 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 Example DER encodings that indicate some capabilities are as follows 581 (KA is key agreement, KDF is key derivation function, and Wrap is key 582 wrap algorithm): 584 KA=ECDH standard KDF=SHA1 Wrap=3DES 586 30 1c 587 06 09 2b 81 05 10 86 48 3f 00 02 588 30 0f 589 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 590 05 00 592 KA=ECDH standard KDF=SHA256 Wrap=AES128 594 30 17 595 06 06 2b 81 04 01 0B 01 596 30 0d 597 06 09 60 86 48 01 65 03 04 01 05 598 05 00 600 KA=ECDH standard KDF=SHA384 Wrap=AES256 602 30 17 603 06 06 2b 81 04 01 0B 02 604 30 0d 605 06 09 60 86 48 01 65 03 04 01 2D 606 05 00 608 KA=ECDH cofactor KDF=SHA1 Wrap=3DES 610 30 1c 611 06 09 2b 81 05 10 86 48 3f 00 03 612 30 0f 613 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 614 05 00 616 KA=ECDH cofactor KDF=SHA256 Wrap=AES128 618 30 17 619 06 06 2b 81 04 01 0E 01 620 30 0d 621 06 09 60 86 48 01 65 03 04 01 05 622 05 00 624 KA=ECDH cofactor KDF=SHA384 Wrap=AES256 626 30 17 627 06 06 2b 81 04 01 0E 02 628 30 0d 629 06 09 60 86 48 01 65 03 04 01 2D 630 05 00 632 KA=ECMQV 1-Pass KDF=SHA1 Wrap=3DES 634 30 1c 635 06 09 2b 81 05 10 86 48 3f 00 10 636 30 0f 637 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 638 05 00 640 KA=ECMQV 1-Pass KDF=SHA256 Wrap=AES128 642 30 17 643 06 06 2b 81 04 01 0F 01 644 30 0d 645 06 09 60 86 48 01 65 03 04 01 05 646 05 00 648 KA=ECMQV 1-Pass KDF=SHA384 Wrap=AES256 650 30 17 651 06 06 2b 81 04 01 0F 02 652 30 0d 653 06 09 60 86 48 01 65 03 04 01 2D 654 05 00 656 8. ASN.1 Syntax 658 The ASN.1 syntax used in this document is gathered in this section 659 for reference purposes. 661 8.1. Algorithm Identifiers 663 The following object identifier indicates the hash algorithm used in 664 this document [SMIME-SHA2]: 666 id-sha1 OBJECT IDENTIFIER ::= { 667 iso(1) identified-organization(3) oiw(14) secsig(3) 668 algorithm(2) 26 } 670 id-sha224 OBJECT IDENTIFIER ::= { 671 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 672 csor(3) nistalgorithm(4) hashalgs(2) 4 } 674 id-sha256 OBJECT IDENTIFIER ::= { 675 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 676 csor(3) nistalgorithm(4) hashalgs(2) 1 } 678 id-sha384 OBJECT IDENTIFIER ::= { 679 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 680 csor(3) nistalgorithm(4) hashalgs(2) 2 } 682 id-sha512 OBJECT IDENTIFIER ::= { 683 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 684 csor(3) nistalgorithm(4) hashalgs(2) 3 } 686 The following object identifier is used in this document to indicate 687 an elliptic curve public key: 689 id-ecPublicKey OBJECT IDENTIFIER ::= { ansi-x9-62 keyType(2) 1 } 691 where 693 ansi-x9-62 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 694 10045 } 696 When the object identifier id-ecPublicKey is used here with an 697 algorithm identifier, the associated parameters contain NULL. 699 The following object identifier indicates the digital signature 700 algorithm used in this document: 702 ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { 703 ansi-x9-62 signatures(4) 1 } 705 ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { 706 ansi-x9-62 signatures(4) ecdsa-with-SHA2(3) 1 } 708 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { 709 ansi-x9-62 signatures(4) ecdsa-with-SHA2(3) 2 } 711 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { 712 ansi-x9-62 signatures(4) ecdsa-with-SHA2(3) 3 } 714 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { 715 ansi-x9-62 signatures(4) ecdsa-with-SHA2(3) 4 } 717 When the object identifiers ecdsa-with-SHA1, ecdsa-with-SHA224, 718 ecdsa-with-SHA256, ecdsa-with-SHA384, or ecdsa-with-SHA512 are used 719 within an algorithm identifier, the associated parameters field 720 contains NULL. 722 The following object identifiers indicate the key agreement 723 algorithms used in this document: 725 dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 726 x9-63-scheme 2 } 728 dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 729 secg-scheme 11 0 } 731 dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 732 secg-scheme 11 1 } 734 dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 735 secg-scheme 11 2 } 737 dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 738 secg-scheme 11 3 } 740 dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 741 x9-63-scheme 3 } 743 dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 744 secg-scheme 14 0 } 746 dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 747 secg-scheme 14 1 } 749 dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 750 secg-scheme 14 2 } 752 dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 753 secg-scheme 14 3 } 755 mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= { 756 x9-63-scheme 16 } 758 mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= { 759 secg-scheme 15 0 } 761 mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= { 762 secg-scheme 15 1 } 764 mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= { 765 secg-scheme 15 2 } 767 mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= { 768 secg-scheme 15 3 } 770 where 772 x9-63-scheme OBJECT IDENTIFIER ::= { 773 iso(1) identified-organization(3) tc68(133) country(16) 774 x9(840) x9-63(63) schemes(0) } 776 and 778 secg-scheme OBJECT IDENTIFIER ::= { 779 iso(1) identified-organization(3) certicom(132) schemes(1) } 781 When the object identifiers are used here within an algorithm 782 identifier, the associated parameters field contains the CMS 783 KeyWrapAlgorithm algorithm identifier. 785 8.2. Other Syntax 787 The following additional syntax is used here. 789 When using ECDSA with SignedData, ECDSA signatures are encoded using 790 the type: 792 ECDSA-Sig-Value ::= SEQUENCE { 793 r INTEGER, 794 s INTEGER } 796 ECDSA-Sig-Value is specified in [X9.62]. Within CMS, ECDSA-Sig-Value 797 is DER-encoded and placed within a signature field of SignedData. 799 When using ECDH and ECMQV with EnvelopedData and AuthenticatedData, 800 ephemeral and static public keys are encoded using the type ECPoint. 802 ECPoint ::= OCTET STRING 804 When using ECMQV with EnvelopedData and AuthenticatedData, the 805 sending agent's ephemeral public key and additional keying material 806 are encoded using the type: 808 MQVuserKeyingMaterial ::= SEQUENCE { 809 ephemeralPublicKey OriginatorPublicKey, 810 addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL } 812 The ECPoint syntax in used to represent the ephemeral public key and 813 placed in the ephemeralPublicKey field. The additional user keying 814 material is placed in the addedukm field. Then the 815 MQVuserKeyingMaterial value is DER-encoded and placed within a ukm 816 field of EnvelopedData or AuthenticatedData. 818 When using ECDH or ECMQV with EnvelopedData or AuthenticatedData, the 819 key-encryption keys are derived by using the type: 821 ECC-CMS-SharedInfo ::= SEQUENCE { 822 keyInfo AlgorithmIdentifier, 823 entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL, 824 suppPubInfo [2] EXPLICIT OCTET STRING } 826 The fields of ECC-CMS-SharedInfo are as follows: 828 keyInfo contains the object identifier of the key-encryption 829 algorithm (used to wrap the CEK) and NULL parameters. 831 entityUInfo optionally contains additional keying material 832 supplied by the sending agent. When used with ECDH and CMS, the 833 entityUInfo field contains the octet string ukm. When used with 834 ECMQV and CMS, the entityUInfo contains the octet string addedukm 835 (encoded in MQVuserKeyingMaterial). 837 suppPubInfo contains the length of the generated KEK, in bits, 838 represented as a 32 bit number, as in [CMS-DH]. (E.g. for 3DES 839 it would be 00 00 00 c0.) 841 Within CMS, ECC-CMS-SharedInfo is DER-encoded and used as input to 842 the key derivation function, as specified in [SEC1, Section 3.6.1]. 844 Note that ECC-CMS-SharedInfo differs from the OtherInfo specified in 845 [CMS-DH]. Here, a counter value is not included in the keyInfo field 846 because the key derivation function specified in [SEC1, Section 847 3.6.1] ensures that sufficient keying data is provided. 849 9. Security Considerations 851 Cryptographic algorithms will be broken or weakened over time. 852 Implementers and users need to check that the cryptographic 853 algorithms listed in this document continue to provide the expected 854 level of security. The IETF from time to time may issue documents 855 dealing with the current state of the art. 857 This specification is based on [CMS], [CMS-AUTHENV], [CMS-ALG], [CMS- 858 AESCG], [X9.62], and [SEC1] and the appropriate security 859 considerations of those documents apply. 861 In addition, implementors of AuthenticatedData should be aware of the 862 concerns expressed in [BON] when using AuthenticatedData to send 863 messages to more than one recipient. Also, users of MQV should be 864 aware of the vulnerability in [K]. 866 When implementing EnvelopedData, AuthenticatedData, and 867 AuthEnvelopedData, there are five algorithm related choices that need 868 to be made: 870 1) What is the public key size? 871 2) What is the KDF? 872 3) What is the key wrap algorithm? 873 4) What is the content encryption algorithm? 874 5) What is the curve? 876 Consideration must be given to strength of the security provided by 877 each of these choices. Security is measured in bits, where a strong 878 symmetric cipher with a key of X bits is said to provide X bits of 879 security. It is recommended that the bits of security provided by 880 each are roughly equivalent. The following table provides comparable 881 minimum bits of security [NISTSP800-57] for the ECDH/ECMQV key sizes, 882 KDFs, key wrapping algorithms, and content encryption algorithms. It 883 also lists curves [PKI-ALG] for the key sizes. 885 Minimum | ECDH or | Key | Key | Content | Curves 886 Bits of | ECQMV | Derivation | Wrap | Encryption | 887 Security | Key Size | Function | Alg. | Alg. | 888 ---------+----------+------------+----------+-------------+---------- 889 80 | 160-223 | SHA1 | 3DES | 3DES CBC | sect163k1 890 | | SHA224 | AES-128 | AES-128 CBC | secp163r2 891 | | SHA256 | AES-192 | AES-192 CBC | secp192r1 892 | | SHA384 | AES-256 | AES-256 CBC | 893 | | SHA512 | | | 894 ---------+----------+------------+----------+-------------+--------- 895 112 | 224-255 | SHA1 | 3DES | 3DES CBC | secp224r1 896 | | SHA224 | AES-128 | AES-128 CBC | sect233k1 897 | | SHA256 | AES-192 | AES-192 CBC | sect233r1 898 | | SHA384 | AES-256 | AES-256 CBC | 899 | | SHA512 | | | 900 ---------+----------+------------+----------+-------------+--------- 901 128 | 256-383 | SHA1 | AES-128 | AES-128 CBC | secp256r1 902 | | SHA224 | AES-192 | AES-192 CBC | sect283k1 903 | | SHA256 | AES-256 | AES-256 CBC | sect283r1 904 | | SHA384 | | | 905 | | SHA512 | | | 906 ---------+----------+------------+----------+-------------+--------- 907 192 | 384-511 | SHA224 | AES-192 | AES-192 CBC | secp384r1 908 | | SHA256 | AES-256 | AES-256 CBC | sect409k1 909 | | SHA384 | | | sect409r1 910 | | SHA512 | | | 911 ---------+----------+------------+----------+-------------+--------- 912 256 | 512+ | SHA256 | AES-256 | AES-256 CBC | secp521r1 913 | | SHA384 | | | sect571k1 914 | | SHA512 | | | sect571r1 915 ---------+----------+------------+----------+-------------+--------- 916 To promote interoperability, the following choices are RECOMMENDED: 918 Minimum | ECDH or | Key | Key | Content | Curve 919 Bits of | ECQMV | Derivation | Wrap | Encryption | 920 Security | Key Size | Function | Alg. | Alg. | 921 ---------+----------+------------+----------+-------------+---------- 922 80 | 192 | SHA256 | 3DES | 3DES CBC | secp192r1 923 ---------+----------+------------+----------+-------------+---------- 924 112 | 224 | SHA256 | 3DES | 3DES CBC | secp224r1 925 ---------+----------+------------+----------+-------------+---------- 926 128 | 256 | SHA256 | AES-128 | AES-128 CBC | secp256r1 927 ---------+----------+------------+----------+-------------+---------- 928 192 | 384 | SHA384 | AES-256 | AES-256 CBC | secp384r1 929 ---------+----------+------------+----------+-------------+---------- 930 256 | 512 | SHA512 | AES-256 | AES-256 CBC | secp521r1 931 ---------+----------+------------+----------+-------------+---------- 933 When implementing SignedData, there are three algorithm related 934 choices that need to be made: 936 1) What is the public key size? 937 2) What is the hash algorithm? 938 3) What is the curve? 940 Consideration must be given to the bits of security provided by each 941 of these choices. Security is measured in bits, where a strong 942 symmetric cipher with a key of X bits is said to provide X bits of 943 security. It is recommended that the bits of security provided by 944 each choice are roughly equivalent. The following table provides 945 comparable minimum bits of security [NISTSP800-57] for the ECDSA key 946 sizes and message digest algorithms. It also lists curves [PKI-ALG] 947 for the key sizes. 949 Minimum | ECDSA | Message | Curve 950 Bits of | Key Size | Digest | 951 Security | | Algorithm | 952 ---------+----------+-----------+----------- 953 80 | 160-223 | SHA1 | sect163k1 954 | | SHA224 | secp163r2 955 | | SHA256 | secp192r1 956 | | SHA384 | 957 | | SHA512 | 958 ---------+----------+-----------+----------- 959 112 | 224-255 | SHA224 | secp224r1 960 | | SHA256 | sect233k1 961 | | SHA384 | sect233r1 962 | | SHA512 | 963 ---------+----------+-----------+----------- 964 128 | 256-383 | SHA256 | secp256r1 965 | | SHA384 | sect283k1 966 | | SHA512 | sect283r1 967 ---------+----------+-----------+----------- 968 192 | 384-511 | SHA384 | secp384r1 969 | | SHA512 | sect409k1 970 | | | sect409r1 971 ---------+----------+-----------+----------- 972 256 | 512+ | SHA512 | secp521r1 973 | | | sect571k1 974 | | | sect571r1 975 ---------+----------+-----------+----------- 977 To promote interoperability, the following choices are RECOMMENDED: 979 Minimum | ECDSA | Message | Curve 980 Bits of | Key Size | Digest | 981 Security | | Algorithm | 982 ---------+----------+-----------+----------- 983 80 | 192 | SHA256 | sect192r1 984 ---------+----------+-----------+----------- 985 112 | 224 | SHA256 | secp224r1 986 ---------+----------+-----------+----------- 987 128 | 256 | SHA256 | secp256r1 988 ---------+----------+-----------+----------- 989 192 | 384 | SHA384 | secp384r1 990 ---------+----------+-----------+----------- 991 256 | 512+ | SHA512 | secp521r1 992 ---------+----------+-----------+----------- 994 10. IANA Considerations 996 None. 998 11. References 1000 11.1. Normative 1002 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 1003 3852, July 2004. 1005 [CMS-AES] Schaad, J., "Use of the Advanced Encryption Standard 1006 (AES) Encryption Algorithm in Cryptographic Message 1007 Syntax (CMS)", RFC 3565, July 2003. 1009 [CMS-AESCG] Housley, R., "Using AES-CCM and AES-GCM Authenticated 1010 Encryption in the Cryptographic Message Syntax 1011 (CMS)", RFC 5084, November 2007. 1013 [CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS) 1014 Algorithms", RFC 3370, August 2002. 1016 [CMS-AUTHENV] Housley, R. "Cryptographic Message Syntax (CMS) 1017 Authenticated-Enveloped-Data Content Type", RFC 5083, 1018 November 2007. 1020 [CMS-DH] Rescorla, E., "Diffie-Hellman Key Agreement Method", 1021 RFC 2631, June 1999. 1023 [IEEE1363] IEEE P1363, "Standard Specifications for Public Key 1024 Cryptography", Institute of Electrical and 1025 Electronics Engineers, 2000. 1027 [DSS] FIPS 186-2, "Digital Signature Standard", National 1028 Institute of Standards and Technology, January 2000. 1030 [HMAC-SHA] Nystrom, M., "Identifiers and Test Vectors for HMAC- 1031 SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA- 1032 512", RFC 4231, December 2005. 1034 [MUST] Bradner, S., "Key Words for Use in RFCs to Indicate 1035 Requirement Levels", BCP 14, RFC 2119, March 1997. 1037 [MSG] Ramsdell, B., and S. Turner, "S/MIME Version 3.2 1038 Message Specification", work-in-progress. 1040 [PKI] Cooper, D., Santesson, S., Farrell, S., Boeyen, S. 1041 Housley, R., and W. Polk, "Internet X.509 Public Key 1042 Infrastructure Certificate and Certificate Revocation 1043 List (CRL) Profile", RFC 5280, May 2008. 1045 [PKI-ALG] Turner, S., Brown, D., Yiu, K., Housley, R., and W. 1046 Polk, "Elliptic Curve Cryptography Subject Public Key 1047 Information", work-in-progress. 1049 [SEC1] SECG, "Elliptic Curve Cryptography", Standards for 1050 Efficient Cryptography Group, 2000. Available from 1051 www.secg.org/collateral/sec1.pdf. 1053 [SEC2] SECG, "Recommended Elliptic Curve Domain Parameters", 1054 Standards for Efficient Cryptography Group, 2000. 1055 Available from www.secg.org/collateral/sec2.pdf. 1057 [SHS] National Institute of Standards and Technology 1058 (NIST), FIPS Publication 180-2: Secure Hash Standard, 1059 August 2002. 1061 [SMIME-SHA2] Turner, S., "Using SHA2 Algorithms with Cryptographic 1062 Message Syntax", work-in-progress. 1064 [X9.62] ANSI X9.62-2005, "Public Key Cryptography For The 1065 Financial Services Industry: The Elliptic Curve 1066 Digital Signature Algorithm (ECDSA)", American 1067 National Standards Institute, 2005. 1069 [X.208] ITU-T Recommendation X.208 (1998) | ISO/IEC 8824- 1070 1:1998. Specification of Abstract Syntax Notation One 1071 (ASN.1). 1073 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824- 1074 1 :2002. Information Technology - Abstract Syntax 1075 Notation One. 1077 [X.681] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824- 1078 2 :2002. Information Technology - Abstract Syntax 1079 Notation One: Information Object Specification. 1081 [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824- 1082 3 :2002. Information Technology - Abstract Syntax 1083 Notation One: Constraint Specification. 1085 [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824- 1086 4:2002. Information Technology - Abstract Syntax 1087 Notation One: Parameterization of ASN.1 1088 Specifications, 2002. 1090 11.2. Informative 1092 [BON] D. Boneh, "The Security of Multicast MAC", 1093 Presentation at Selected Areas of Cryptography 2000, 1094 Center for Applied Cryptographic Research, University 1095 of Waterloo, 2000. Paper version available from 1096 http://crypto.stanford.edu/~dabo/papers/mmac.ps 1098 [CMS-KEA] Pawling, J., "CMS KEA and SKIPJACK Conventions", RFC 1099 2876, July 2000. 1101 [K] B. Kaliski, "MQV Vulnerability", Posting to ANSI X9F1 1102 and IEEE P1363 newsgroups, 1998. 1104 [NISTSP800-57] National Institute of Standards and Technology 1105 (NIST), Special Publication 800-57: Recommendation 1106 for Key Management, August 2005. 1108 Appendix A ASN.1 Modules 1110 Appendix A.1 provides the normative ASN.1 definitions for the 1111 structures described in this specification using ASN.1 as defined in 1112 [X.208]. 1114 Appendix A.2 provides an informative ASN.1 definitions for the 1115 structures described in this specification using ASN.1 as defined in 1116 [X.680], [X.681], [X.682], [X.683]. This appendix contains the same 1117 information as Appendix A.1 in a more recent (and precise) ASN.1 1118 notation, however Appendix A.1 takes precedence in case of conflict. 1120 Appendix A.1 1988 ASN.1 Module 1122 SMIMEECCAlgs-1988 1123 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1124 smime(16) modules(0) TBD } 1126 DEFINITIONS EXPLICIT TAGS ::= 1128 BEGIN 1130 -- EXPORTS ALL 1132 IMPORTS 1134 -- From [PKI] 1136 AlgorithmIdentifier 1137 FROM PKIX1Explicit88 1138 { iso(1) identified-organization(3) dod(6) 1139 internet(1) security(5) mechanisms(5) pkix(7) mod(0) 1140 pkix1-explicit(18) } 1142 -- From [CMS-AES] 1144 id-aes128-CBC, id-aes192-CBC, id-aes256-CBC, AES-IV, 1145 id-aes128-wrap, id-aes192-wrap, id-aes1256-wrap 1146 FROM CMSAesRsaesOaep 1147 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1148 smime(16) modules(0) id-mod-cms-aes(19) } 1150 -- From [CMS-AESCG] 1152 id-aes128-CCM, id-aes192-CCM, id-aes256-CCM, CCMParameters 1153 id-aes128-GCM, id-aes192-GCM, id-aes256-GCM, GCMParameters 1154 FROM CMS-AES-CCM-and-AES-GCM 1155 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1156 smime(16) modules(0) id-mod-cms-aes(32) } 1158 -- From [CMS] 1160 OriginatorPublicKey, UserKeyingMaterial 1161 FROM CryptographicMessageSyntax2004 1162 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1163 smime(16) modules(0) cms-2004(24) } 1165 -- From [CMS-ALG] 1167 hMAC-SHA1, id-alg-CMS3DESwrap, CBCParameter 1168 FROM CryptographicMessageSyntaxAlgorithms 1169 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1170 smime(16) modules(0) cmsalg-2001(16) } 1172 -- From [PKI-ALG] 1174 id-ecPublicKey, ecdsa-with-SHA1 1175 FROM PKIXAlgs-1988 1176 { iso(1) identified-organization(3) dod(6) internet(1) 1177 security(5) mechanisms(5) pkix(7) id-mod(0) TBD } 1179 ; 1181 -- 1182 -- ECDSA with SHA-2 Algorithms 1183 -- 1185 -- Parameters are NULL 1187 -- ecdsa-with-SHA1 Parameters are NULL 1189 ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { 1190 iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 1191 ecdsa-with-SHA2(3) 1 } 1193 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { 1194 iso(1) member-body(2) us(840)ansi-X9-62(10045) signatures(4) 1195 ecdsa-with-SHA2(3) 2 } 1197 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { 1198 iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 1199 ecdsa-with-SHA2(3) 3 } 1201 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { 1202 iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 1203 ecdsa-with-SHA2(3) 4 } 1205 -- ECDSA Signature Value 1206 -- Contents of SignatureValue OCTET STRING 1208 ECDSA-Sig-Value ::= SEQUENCE { 1209 r INTEGER, 1210 s INTEGER 1211 } 1213 -- 1214 -- Key Agreement Algorithms 1215 -- 1217 x9-63-scheme OBJECT IDENTIFIER ::= { 1218 iso(1) identified-organization(3) tc68(133) country(16) x9(840) 1219 x9-63(63) schemes(0) } 1221 secg-scheme OBJECT IDENTIFIER ::= { 1222 iso(1) identified-organization(3) certicom(132) schemes(1) } 1224 -- 1225 -- Diffie-Hellman Single Pass, Standard, with KDFs 1226 -- 1228 -- Parameters are always present and indicate the Key Wrap Algorithm 1230 dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 1231 x9-63-scheme 2 } 1233 dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 1234 secg-scheme 11 0 } 1236 dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 1237 secg-scheme 11 1 } 1239 dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 1240 secg-scheme 11 2 } 1242 dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 1243 secg-scheme 11 3 } 1245 -- 1246 -- Diffie-Hellman Single Pass, Cofactor, with KDFs 1247 -- 1249 dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 1250 x9-63-scheme 3 } 1252 dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 1253 secg-scheme 14 0 } 1255 dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 1256 secg-scheme 14 1 } 1258 dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 1259 secg-scheme 14 2 } 1261 dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 1262 secg-scheme 14 3 } 1264 -- 1265 -- MQV Single Pass, Cofactor, with KDFs 1266 -- 1268 mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= { 1269 x9-63-scheme 16 } 1271 mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= { 1272 secg-scheme 15 0 } 1274 mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= { 1275 secg-scheme 15 1 } 1277 mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= { 1278 secg-scheme 15 2 } 1280 mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= { 1281 secg-scheme 15 3 } 1283 -- 1284 -- Key Wrap Algorithms 1285 -- 1287 -- id-alg-CMS3DESwrap Parameters are NULL 1288 -- id-aes128-wrap Parameters are ABSENT 1289 -- id-aes192-wrap Parameters are ABSENT 1290 -- id-aes256-wrap Parameters are ABSENT 1292 -- 1293 -- Content Encryption Algorithms 1294 -- 1296 -- des-ede3-cbc Parameters are CBCParameter 1297 -- id-aes128-CBC Parameters are AES-IV 1298 -- id-aes192-CBC Parameters are AES-IV 1299 -- id-aes256-CBC Parameters are AES-IV 1300 -- id-aes128-CCM Parameters are CCMParameters 1301 -- id-aes192-CCM Parameters are CCMParameters 1302 -- id-aes256-CCM Parameters are CCMParameters 1303 -- id-aes128-GCM Parameters are GCMParameters 1304 -- id-aes192-GCM Parameters are GCMParameters 1305 -- id-aes256-GCM Parameters are GCMParameters 1307 -- 1308 -- Message Digest Algorithms 1309 -- 1311 -- Parameters are NULL 1313 -- HMAC with SHA-224, HMAC with SHA-256, HMAC with SHA-384, 1314 -- HMAC with SHA-512 are specified in [HMAC-SHA] 1316 -- hMACWithSHA1 1318 id-hmacWithSHA224 OBJECT IDENTIFIER ::= { 1319 iso(1) member-body(2) us(840) rsadsi(113549) 1320 digestAlgorithm(2) 8 } 1322 id-hmacWithSHA256 OBJECT IDENTIFIER ::= { 1323 iso(1) member-body(2) us(840) rsadsi(113549) 1324 digestAlgorithm(2) 9 } 1326 id-hmacWithSHA384 OBJECT IDENTIFIER ::= { 1327 iso(1) member-body(2) us(840) rsadsi(113549) 1328 digestAlgorithm(2) 10 } 1330 id-hmacWithSHA512 OBJECT IDENTIFIER ::= { 1331 iso(1) member-body(2) us(840) rsadsi(113549) 1332 digestAlgorithm(2) 11 } 1334 -- 1335 -- Originator Public Key Algorithms 1336 -- 1338 -- id-ecPublicKey Parameters are NULL 1340 -- Format for both ephemeral and static public keys 1342 ECPoint ::= OCTET STRING 1344 -- Format of KeyAgreeRecipientInfo ukm field when used with 1345 -- ECMQV 1347 MQVuserKeyingMaterial ::= SEQUENCE { 1348 ephemeralPublicKey OriginatorPublicKey, 1349 addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL 1350 } 1352 -- Format for ECDH and ECMQV key-encryption keys when using 1353 -- EnvelopedData or AuthenticatedData 1355 ECC-CMS-SharedInfo ::= SEQUENCE { 1356 keyInfo AlgorithmIdentifier, 1357 entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL, 1358 suppPubInfo [2] EXPLICIT OCTET STRING 1359 } 1361 -- 1362 -- S/MIME Capabilities 1363 -- 1365 -- 1366 -- S/MIME Capabilities: ECDSA with SHA2 Algorithms 1367 -- 1369 -- ecdsa-with-SHA1 Type NULL 1370 -- ecdsa-with-SHA224 Type NULL 1371 -- ecdsa-with-SHA256 Type NULL 1372 -- ecdsa-with-SHA384 Type NULL 1373 -- ecdsa-with-SHA512 Type NULL 1374 -- 1375 -- S/MIME Capabilities: ECDH, Single Pass, Standard 1376 -- 1378 -- dhSinglePass-stdDH-sha1kdf Type is the Key Wrap Algorithm 1379 -- dhSinglePass-stdDH-sha224kdf Type is the Key Wrap Algorithm 1380 -- dhSinglePass-stdDH-sha256kdf Type is the Key Wrap Algorithm 1381 -- dhSinglePass-stdDH-sha384kdf Type is the Key Wrap Algorithm 1382 -- dhSinglePass-stdDH-sha512kdf Type is the Key Wrap Algorithm 1384 -- 1385 -- S/MIME Capabilities: ECDH, Single Pass, Cofactor 1386 -- 1388 -- dhSinglePass-cofactorDH-sha1kdf Type is the Key Wrap Algorithm 1389 -- dhSinglePass-cofactorDH-sha224kdf Type is the Key Wrap Algorithm 1390 -- dhSinglePass-cofactorDH-sha256kdf Type is the Key Wrap Algorithm 1391 -- dhSinglePass-cofactorDH-sha384kdf Type is the Key Wrap Algorithm 1392 -- dhSinglePass-cofactorDH-sha512kdf Type is the Key Wrap Algorithm 1394 -- 1395 -- S/MIME Capabilities: ECMQV, Single Pass, Standard 1396 -- 1398 -- mqvSinglePass-sha1kdf Type is the Key Wrap Algorithm 1399 -- mqvSinglePass-sha224kdf Type is the Key Wrap Algorithm 1400 -- mqvSinglePass-sha256kdf Type is the Key Wrap Algorithm 1401 -- mqvSinglePass-sha384kdf Type is the Key Wrap Algorithm 1402 -- mqvSinglePass-sha512kdf Type is the Key Wrap Algorithm 1404 END 1406 Appendix A.2 2004 ASN.1 Module 1408 SMIMEECCAlgs-2008 1409 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1410 smime(16) modules(0) TBD } 1412 DEFINITIONS EXPLICIT TAGS ::= 1414 BEGIN 1416 -- EXPORTS ALL 1418 IMPORTS 1420 -- From [PKI-ALG] 1422 ALGORITHM, algorithmIdentifier, MessageDigestAlgorithms, 1423 SignatureAlgorithms 1424 ow-sha1, ow-sha224, ow-sha256, ow-sha384, ow-sha512, 1425 sa-ecdsaWithSHA1 1426 FROM PKIXAlgs-2008 1427 { iso(1) identified-organization(3) dod(6) internet(1) 1428 security(5) mechanisms(5) pkix(7) id-mod(0) TBD } 1430 -- From [CMS-AES] 1432 id-aes128-CBC, id-aes192-CBC, id-aes256-CBC, AES-IV, 1433 id-aes128-wrap, id-aes192-wrap, id-aes1256-wrap 1434 FROM CMSAesRsaesOaep 1435 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1436 smime(16) modules(0) id-mod-cms-aes(19) } 1438 -- From [CMS-AESCG] 1440 id-aes128-CCM, id-aes192-CCM, id-aes256-CCM, CCMParameters, 1441 id-aes128-GCM, id-aes192-GCM, id-aes256-GCM, GCMParameters 1442 FROM CMS-AES-CCM-and-AES-GCM 1443 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1444 smime(16) modules(0) id-mod-cms-aes(32) } 1446 -- From [CMS] 1448 OriginatorPublicKey, UserKeyingMaterial 1449 FROM CryptographicMessageSyntax2004 1450 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1451 smime(16) modules(0) cms-2004(24) } 1453 -- From [CMS-ALG] 1455 hMAC-SHA1, id-alg-CMS3DESwrap, CBCParameter 1456 FROM CryptographicMessageSyntaxAlgorithms 1457 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1458 smime(16) modules(0) cmsalg-2001(16) } 1460 ; 1462 -- Constrains the SignedData digestAlgorithms field 1463 -- Constrains the SignedData SignerInfo digestAlgorithm field 1464 -- Constrains the AuthenticatedData digestAlgorithm field 1466 MessageDigestAlgorithms ALGORITHM ::= { 1467 ow-sha1 | 1468 ow-sha224 | 1469 ow-sha256 | 1470 ow-sha384 | 1471 ow-sha512, 1472 ... -- Extensible 1473 } 1475 -- Constrains the SignedData SignerInfo signatureAlgorithm field 1477 SignatureAlgorithms ALGORITHM ::= { 1478 sa-ecdsaWithSHA1 | 1479 sa-ecdsaWithSHA224 | 1480 sa-ecdsaWithSHA256 | 1481 sa-ecdsaWithSHA384 | 1482 sa-ecdsaWithSHA512 , 1483 ... -- Extensible 1484 } 1486 -- 1487 -- ECDSA with SHA-2 Algorithms 1488 -- 1490 -- Parameters are NULL 1492 -- sa-ecdsa-withSHA1 1494 sa-ecdsa-with-SHA224 ALGORITHM ::= { 1495 OID ecdsa-with-SHA224 PARMS NULL } 1497 ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { 1498 iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 1499 ecdsa-with-SHA2(3) 1 } 1501 sa-ecdsa-with-SHA256 ALGORITHM ::= { 1502 OID ecdsa-with-SHA256 PARMS NULL } 1504 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { 1505 iso(1) member-body(2) us(840)ansi-X9-62(10045) signatures(4) 1506 ecdsa-with-SHA2(3) 2 } 1508 sa-ecdsa-with-SHA384 ALGORITHM ::= { 1509 OID ecdsa-with-SHA384 PARMS NULL } 1511 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { 1512 iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 1513 ecdsa-with-SHA2(3) 3 } 1515 sa-ecdsa-with-SHA512 ALGORITHM ::= { 1516 OID ecdsa-with-SHA512 PARMS NULL } 1518 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { 1519 iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 1520 ecdsa-with-SHA2(3) 4 } 1522 -- ECDSA Signature Value 1523 -- Contents of SignatureValue OCTET STRING 1525 ECDSA-Sig-Value ::= SEQUENCE { 1526 r INTEGER, 1527 s INTEGER 1528 } 1529 -- 1530 -- Key Agreement Algorithms 1531 -- 1533 -- Constrains the EnvelopedData RecipientInfo KeyAgreeRecipientInfo 1534 -- keyEncryption Algorithm field 1535 -- Constrains the AuthenticatedData RecipientInfo 1536 -- KeyAgreeRecipientInfo keyEncryption Algorithm field 1537 -- Constrains the AuthEnvelopedData RecipientInfo 1538 -- KeyAgreeRecipientInfo keyEncryption Algorithm field 1540 -- DH variants are not used with AuthenticatedData or 1541 -- AuthEnvelopedData 1543 KeyAgreementAlgorithms ALGORITHM ::= { 1544 kaa-dhSinglePass-stdDH-sha1kdf | 1545 kaa-dhSinglePass-stdDH-sha224kdf | 1546 kaa-dhSinglePass-stdDH-sha256kdf | 1547 kaa-dhSinglePass-stdDH-sha384kdf | 1548 kaa-dhSinglePass-stdDH-sha512kdf | 1549 kaa-dhSinglePass-cofactorDH-sha1kdf | 1550 kaa-dhSinglePass-cofactorDH-sha224kdf | 1551 kaa-dhSinglePass-cofactorDH-sha256kdf | 1552 kaa-dhSinglePass-cofactorDH-sha384kdf | 1553 kaa-dhSinglePass-cofactorDH-sha512kdf | 1554 kaa-mqvSinglePass-sha1kdf | 1555 kaa-mqvSinglePass-sha224kdf | 1556 kaa-mqvSinglePass-sha256kdf | 1557 kaa-mqvSinglePass-sha384kdf | 1558 kaa-mqvSinglePass-sha512kdf, 1559 ... -- Extensible 1560 } 1562 x9-63-scheme OBJECT IDENTIFIER ::= { 1563 iso(1) identified-organization(3) tc68(133) country(16) x9(840) 1564 x9-63(63) schemes(0) } 1566 secg-scheme OBJECT IDENTIFIER ::= { 1567 iso(1) identified-organization(3) certicom(132) schemes(1) } 1569 -- 1570 -- Diffie-Hellman Single Pass, Standard, with KDFs 1571 -- 1573 -- Parameters are always present and indicate the Key Wrap Algorithm 1575 kaa-dhSinglePass-stdDH-sha1kdf ALGORITHM ::= { 1576 OID dhSinglePass-stdDH-sha1kdf-scheme PARMS KeyWrapAlgorithms } 1578 dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 1579 x9-63-scheme 2 } 1581 kaa-dhSinglePass-stdDH-sha224kdf ALGORITHM ::= { 1582 OID dhSinglePass-stdDH-sha224kdf-scheme PARMS KeyWrapAlgorithms } 1584 dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 1585 secg-scheme 11 0 } 1587 kaa-dhSinglePass-stdDH-sha256kdf ALGORITHM ::= { 1588 OID dhSinglePass-stdDH-sha256kdf-scheme PARMS KeyWrapAlgorithms } 1590 dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 1591 secg-scheme 11 1 } 1593 kaa-dhSinglePass-stdDH-sha384kdf ALGORITHM ::= { 1594 OID dhSinglePass-stdDH-sha384kdf-scheme PARMS KeyWrapAlgorithms } 1596 dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 1597 secg-scheme 11 2 } 1599 kaa-dhSinglePass-stdDH-sha512kdf ALGORITHM ::= { 1600 OID dhSinglePass-stdDH-sha512kdf-scheme PARMS KeyWrapAlgorithms } 1602 dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 1603 secg-scheme 11 3 } 1605 -- 1606 -- Diffie-Hellman Single Pass, Cofactor, with KDFs 1607 -- 1609 kaa-dhSinglePass-cofactorDH-sha1kdf ALGORITHM ::= { 1610 OID dhSinglePass-cofactorDH-sha1kdf-scheme PARMS KeyWrapAlgorithms } 1612 dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 1613 x9-63-scheme 3 } 1615 kaa-dhSinglePass-cofactorDH-sha224kdf ALGORITHM ::= { 1616 OID dhSinglePass-cofactorDH-sha224kdf-scheme 1617 PARMS KeyWrapAlgorithms } 1619 dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 1620 secg-scheme 14 0 } 1622 kaa-dhSinglePass-cofactorDH-sha256kdf ALGORITHM ::= { 1623 OID dhSinglePass-cofactorDH-sha256kdf-scheme 1624 PARMS KeyWrapAlgorithms } 1626 dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 1627 secg-scheme 14 1 } 1629 kaa-dhSinglePass-cofactorDH-sha384kdf ALGORITHM ::= { 1630 OID dhSinglePass-cofactorDH-sha384kdf-scheme 1631 PARMS KeyWrapAlgorithms } 1633 dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 1634 secg-scheme 14 2 } 1636 kaa-dhSinglePass-cofactorDH-sha512kdf ALGORITHM ::= { 1637 OID dhSinglePass-cofactorDH-sha512kdf-scheme 1638 PARMS KeyWrapAlgorithms } 1640 dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 1641 secg-scheme 14 3 } 1643 -- 1644 -- MQV Single Pass, Cofactor, with KDFs 1645 -- 1647 kaa-mqvSinglePass-sha1kdf ALGORITHM ::= { 1648 OID mqvSinglePass-sha1kdf-scheme PARMS KeyWrapAlgorithms } 1650 mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= { 1651 x9-63-scheme 16 } 1653 kaa-mqvSinglePass-sha224kdf ALGORITHM ::= { 1654 OID mqvSinglePass-sha224kdf-scheme PARMS KeyWrapAlgorithms } 1656 mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= { 1657 secg-scheme 15 0 } 1659 kaa-mqvSinglePass-sha256kdf ALGORITHM ::= { 1660 OID mqvSinglePass-sha256kdf-scheme PARMS KeyWrapAlgorithms } 1662 mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= { 1663 secg-scheme 15 1 } 1665 kaa-mqvSinglePass-sha384kdf ALGORITHM ::= { 1666 OID mqvSinglePass-sha384kdf-scheme PARMS KeyWrapAlgorithms } 1668 mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= { 1669 secg-scheme 15 2 } 1671 kaa-mqvSinglePass-sha512kdf ALGORITHM ::= { 1672 OID mqvSinglePass-sha512kdf-scheme PARMS KeyWrapAlgorithms } 1674 mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= { 1675 secg-scheme 15 3 } 1677 -- 1678 -- Key Wrap Algorithms 1679 -- 1681 KeyWrapAlgorithms ALGORITHM ::= { 1682 kwa-3des | 1683 kwa-aes128 | 1684 kwa-aes192 | 1685 kwa-aes256, 1686 ... -- Extensible 1687 } 1689 kwa-3des ALGORITHM :: = { 1690 OID id-alg-CMS3DESwrap PARMS NULL } 1692 kwa-aes128 ALGORITHM ::= { 1693 OID id-aes128-wrap PARMS ABSENT } 1695 kwa-aes192 ALGORITHM ::= { 1696 OID id-aes192-wrap PARMS ABSENT } 1698 kwa-aes256 ALGORITHM ::= { 1699 OID id-aes256-wrap PARMS ABSENT } 1701 -- 1702 -- Content Encryption Algorithms 1703 -- 1705 -- Constrains the EnvelopedData EncryptedContentInfo encryptedContent 1706 -- field and the AuthEnvelopedData EncryptedContentInfo 1707 -- contentEncryptionAlgorithm field 1709 ContentEncryptionAlgorithms ALGORITHM ::= { 1710 cea-des-ede3-cbc | 1711 cea-aes128-cbc | 1712 cea-aes192-cbc | 1713 cea-aes256-cbc | 1714 cea-aes128-ccm | 1715 cea-aes192-ccm | 1716 cea-aes256-ccm | 1717 cea-aes128-gcm | 1718 cea-aes192-gcm | 1719 cea-aes256-gcm, 1720 ... -- Extensible 1721 } 1723 -- des-ede3-cbc and aes*-cbc are used with EnvelopedData and 1724 -- EncryptedData 1726 cea-des-ede3-cbc ALGORITHM ::= { 1727 OID des-ede3-cbc PARMS CBCParameter } 1729 cea-aes128-cbc ALGORITHM ::= { 1730 OID id-aes128-CBC PARMS AES-IV } 1732 cea-aes192-cbc ALGORITHM ::= { 1733 OID id-aes192-CBC PARMS AES-IV } 1735 cea-aes256-cbc ALGORITHM ::= { 1736 OID id-aes256-CBC PARMS AES-IV } 1738 -- aes*-ccm are used with AuthEnvelopedData 1740 cea-aes128-ccm ALGORITHM ::= { 1741 OID id-aes128-CCM PARMS CCMParameters } 1743 cea-aes192-ccm ALGORITHM ::= { 1744 OID id-aes192-CCM PARMS CCMParameters } 1746 cea-aes256-ccm ALGORITHM ::= { 1747 OID id-aes256-CCM PARMS CCMParameters } 1749 -- aes*-gcm are used with AuthEnvelopedData 1751 cea-aes128-gcm ALGORITHM ::= { 1752 OID id-aes128-GCM PARMS GCMParameters } 1754 cea-aes192-gcm ALGORITHM ::= { 1755 OID id-aes192-GCM PARMS GCMParameters } 1757 cea-aes256-gcm ALGORITHM ::= { 1758 OID id-aes256-GCM PARMS GCMParameters } 1760 -- 1761 -- Message Digest Algorithms 1762 -- 1764 -- HMAC with SHA-224, HMAC with SHA-256, HMAC with SHA-384, 1765 -- HMAC with SHA-512 are specified in [HMAC-SHA] 1767 -- Constrains the AuthenticatedData 1768 -- MessageAuthenticationCodeAlgorithm field 1769 -- Constrains the AuthEnvelopedData 1770 -- MessageAuthenticationCodeAlgorithm field 1772 MessageAuthenticationCodeAlgorithms ALGORITHM ::= { 1773 maca-sha1 | 1774 maca-sha224 | 1775 maca-sha256 | 1776 maca-sha384 | 1777 maca-sha512, 1778 ... -- Extensible 1779 } 1781 maca-sha1 ALGORITHM ::= { 1782 OID hMAC-SHA1 PARMS NULL } 1784 maca-sha224 ALGORITHM ::= { 1785 OID id-hmacWithSHA224 PARMS NULL } 1787 -- Would love to import the HMAC224-512 OIDS but they're not in a 1788 -- module (that I could find) 1790 id-hmacWithSHA224 OBJECT IDENTIFIER ::= { 1791 iso(1) member-body(2) us(840) rsadsi(113549) 1792 digestAlgorithm(2) 8 } 1794 maca-sha256 ALGORITHM ::= { 1795 OID id-hmacWithSHA256 PARMS NULL } 1797 id-hmacWithSHA256 OBJECT IDENTIFIER ::= { 1798 iso(1) member-body(2) us(840) rsadsi(113549) 1799 digestAlgorithm(2) 9 } 1801 maca-sha384 ALGORITHM ::= { 1802 OID id-hmacWithSHA384 PARMS NULL } 1804 id-hmacWithSHA384 OBJECT IDENTIFIER ::= { 1805 iso(1) member-body(2) us(840) rsadsi(113549) 1806 digestAlgorithm(2) 10 } 1808 maca-sha512 ALGORITHM ::= { 1809 OID id-hmacWithSHA512 PARMS NULL } 1811 id-hmacWithSHA512 OBJECT IDENTIFIER ::= { 1812 iso(1) member-body(2) us(840) rsadsi(113549) 1813 digestAlgorithm(2) 11 } 1815 -- 1816 -- Originator Public Key Algorithms 1817 -- 1819 -- Constraints on KeyAgreeRecipientInfo OriginatorIdentifierOrKey 1820 -- OriginatorPublicKey algorithm field 1822 -- PARMS are NULL 1824 OriginatorPKAlgorithms ALGORITHM ::= { 1825 opka-ec, 1826 ... -- Extensible 1827 } 1829 opka-ec AGLORITHM ::={ 1830 OID id-ecPublicKey PARMS NULL } 1832 -- Format for both ephemeral and static public keys 1834 ECPoint ::= OCTET STRING 1836 -- Format of KeyAgreeRecipientInfo ukm field when used with 1837 -- ECMQV 1839 MQVuserKeyingMaterial ::= SEQUENCE { 1840 ephemeralPublicKey OriginatorPublicKey, 1841 addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL 1842 } 1843 -- Format for ECDH and ECMQV key-encryption keys when using 1844 -- EnvelopedData or AuthenticatedData 1846 ECC-CMS-SharedInfo ::= SEQUENCE { 1847 keyInfo AlgorithmIdentifier { KeyWrapAlgorithms }, 1848 entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL, 1849 suppPubInfo [2] EXPLICIT OCTET STRING 1850 } 1852 -- 1853 -- S/MIME Capabilities 1854 -- 1856 SMIME-CAPS ::= CLASS { 1857 &Type OPTIONAL, 1858 &id OBJECT IDENTIFIER UNIQUE 1859 } 1860 WITH SYNTAX {TYPE &Type IDENTIFIED BY &id } 1862 SMIMECapability ::= SEQUENCE { 1863 capabilityID SMIME-CAPS.&id({SMimeCapsSet}), 1864 parameters SMIME-CAPS. 1865 &Type({SMimeCapsSet}{@capabilityID}) OPTIONAL 1866 } 1867 SMimeCapsSet SMIME-CAPS ::= { 1868 cap-ecdsa-with-SHA1 | 1869 cap-ecdsa-with-SHA224 | 1870 cap-ecdsa-with-SHA256 | 1871 cap-ecdsa-with-SHA384 | 1872 cap-ecdsa-with-SHA512 | 1873 cap-dhSinglePass-stdDH-sha1kdf | 1874 cap-dhSinglePass-stdDH-sha224kdf | 1875 cap-dhSinglePass-stdDH-sha256kdf | 1876 cap-dhSinglePass-stdDH-sha384kdf | 1877 cap-dhSinglePass-stdDH-sha512kdf | 1878 cap-dhSinglePass-cofactorDH-sha1kdf | 1879 cap-dhSinglePass-cofactorDH-sha224kdf | 1880 cap-dhSinglePass-cofactorDH-sha256kdf | 1881 cap-dhSinglePass-cofactorDH-sha384kdf | 1882 cap-dhSinglePass-cofactorDH-sha512kdf | 1883 cap-mqvSinglePass-sha1kdf | 1884 cap-mqvSinglePass-sha224kdf | 1885 cap-mqvSinglePass-sha256kdf | 1886 cap-mqvSinglePass-sha384kdf | 1887 cap-mqvSinglePass-sha512kdf, 1888 ... -- Extensible 1889 } 1891 -- 1892 -- S/MIME Capabilities: ECDSA with SHA2 Algorithms 1893 -- 1895 cap-ecdsa-with-SHA1 SMIME-CAPS ::= { 1896 TYPE NULL IDENTIFIED BY ecdsa-with-SHA1 } 1898 cap-ecdsa-with-SHA224 SMIME-CAPS ::= { 1899 TYPE NULL IDENTIFIED BY ecdsa-with-SHA224 } 1901 cap-ecdsa-with-SHA256 SMIME-CAPS ::= { 1902 TYPE NULL IDENTIFIED BY ecdsa-with-SHA256 } 1904 cap-ecdsa-with-SHA384 SMIME-CAPS ::= { 1905 TYPE NULL IDENTIFIED BY ecdsa-with-SHA384 } 1907 cap-ecdsa-with-SHA512 SMIME-CAPS ::= { 1908 TYPE NULL IDENTIFIED BY ecdsa-with-SHA512 } 1910 -- 1911 -- S/MIME Capabilities: ECDH, Single Pass, Standard 1912 -- 1914 cap-dhSinglePass-stdDH-sha1kdf SMIME-CAPS ::= { 1915 TYPE KeyWrapAlgorithms IDENTIFIED BY dhSinglePass-stdDH-sha1kdf } 1917 cap-dhSinglePass-stdDH-sha224kdf SMIME-CAPS ::= { 1918 TYPE KeyWrapAlgorithms IDENTIFIED BY dhSinglePass-stdDH-sha224kdf } 1920 cap-dhSinglePass-stdDH-sha256kdf SMIME-CAPS ::= { 1921 TYPE KeyWrapAlgorithms IDENTIFIED BY dhSinglePass-stdDH-sha256kdf } 1923 cap-dhSinglePass-stdDH-sha384kdf SMIME-CAPS ::= { 1924 TYPE KeyWrapAlgorithms IDENTIFIED BY dhSinglePass-stdDH-sha384kdf } 1926 cap-dhSinglePass-stdDH-sha512kdf SMIME-CAPS ::= { 1927 TYPE KeyWrapAlgorithms IDENTIFIED BY dhSinglePass-stdDH-sha512kdf } 1929 -- 1930 -- S/MIME Capabilities: ECDH, Single Pass, Cofactor 1931 -- 1933 cap-dhSinglePass-cofactorDH-sha1kdf SMIME-CAPS ::= { 1934 TYPE KeyWrapAlgorithms 1935 IDENTIFIED BY dhSinglePass-cofactorDH-sha1kdf } 1937 cap-dhSinglePass-cofactorDH-sha224kdf SMIME-CAPS ::= { 1938 TYPE KeyWrapAlgorithms 1939 IDENTIFIED BY dhSinglePass-cofactorDH-sha224kdf } 1941 cap-dhSinglePass-cofactorDH-sha256kdf SMIME-CAPS ::= { 1942 TYPE KeyWrapAlgorithms 1943 IDENTIFIED BY dhSinglePass-cofactorDH-sha256kdf } 1945 cap-dhSinglePass-cofactorDH-sha384kdf SMIME-CAPS ::= { 1946 TYPE KeyWrapAlgorithms 1947 IDENTIFIED BY dhSinglePass-cofactorDH-sha384kdf } 1949 cap-dhSinglePass-cofactorDH-sha512kdf SMIME-CAPS ::= { 1950 TYPE KeyWrapAlgorithms 1951 IDENTIFIED BY dhSinglePass-cofactorDH-sha512kdf } 1953 -- 1954 -- S/MIME Capabilities: ECMQV, Single Pass, Standard 1955 -- 1957 cap-mqvSinglePass-sha1kdf SMIME-CAPS ::= { 1958 TYPE KeyWrapAlgorithms IDENTIFIED BY mqvSinglePass-sha1kdf } 1960 cap-mqvSinglePass-sha224kdf SMIME-CAPS ::= { 1961 TYPE KeyWrapAlgorithms IDENTIFIED BY mqvSinglePass-sha224kdf } 1963 cap-mqvSinglePass-sha256kdf SMIME-CAPS ::= { 1964 TYPE KeyWrapAlgorithms IDENTIFIED BY mqvSinglePass-sha256kdf } 1966 cap-mqvSinglePass-sha384kdf SMIME-CAPS ::= { 1967 TYPE KeyWrapAlgorithms IDENTIFIED BY mqvSinglePass-sha384kdf } 1969 cap-mqvSinglePass-sha512kdf SMIME-CAPS ::= { 1970 TYPE KeyWrapAlgorithms IDENTIFIED BY mqvSinglePass-sha512kdf } 1972 END 1974 Acknowledgements 1976 The methods described in this document are based on work done by the 1977 ANSI X9F1 working group. The authors wish to extend their thanks to 1978 ANSI X9F1 for their assistance. The authors also wish to thank Peter 1979 de Rooij for his patient assistance. The technical comments of 1980 Francois Rousseau were valuable contributions. 1982 Many thanks go out to the other authors of RFC 3278: Simon Blake- 1983 Wilson and Paul Lambert. Without the initial version of RFC3278 this 1984 version wouldn't exist. 1986 The authors also wish to thank Alfred Hoenes, Jim Schaad, and Russ 1987 Housley for their valuable input. 1989 Author's Addresses 1991 Sean Turner 1993 IECA, Inc. 1994 3057 Nutley Street, Suite 106 1995 Fairfax, VA 22031 1996 USA 1998 Email: turners@ieca.com 2000 Daniel R. L. Brown 2002 Certicom Corp 2003 5520 Explorer Drive #400 2004 Mississauga, ON L4W 5L1 2005 CANADA 2007 Email: dbrown@certicom.com 2009 Full Copyright Statement 2011 Copyright (C) The IETF Trust (2008). 2013 This document is subject to the rights, licenses and restrictions 2014 contained in BCP 78, and except as set forth therein, the authors 2015 retain all their rights. 2017 This document and the information contained herein are provided on an 2018 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2019 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2020 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2021 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2022 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2023 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2025 Intellectual Property 2027 The IETF takes no position regarding the validity or scope of any 2028 Intellectual Property Rights or other rights that might be claimed to 2029 pertain to the implementation or use of the technology described in 2030 this document or the extent to which any license under such rights 2031 might or might not be available; nor does it represent that it has 2032 made any independent effort to identify any such rights. Information 2033 on the procedures with respect to rights in RFC documents can be 2034 found in BCP 78 and BCP 79. 2036 Copies of IPR disclosures made to the IETF Secretariat and any 2037 assurances of licenses to be made available, or the result of an 2038 attempt made to obtain a general license or permission for the use of 2039 such proprietary rights by implementers or users of this 2040 specification can be obtained from the IETF on-line IPR repository at 2041 http://www.ietf.org/ipr. 2043 The IETF invites any interested party to bring to its attention any 2044 copyrights, patents or patent applications, or other proprietary 2045 rights that may cover technology that may be required to implement 2046 this standard. Please address the information to the IETF at 2047 ietf-ipr@ietf.org. 2049 Acknowledgment 2051 Funding for the RFC Editor function is provided by the IETF 2052 Administrative Support Activity (IASA).