idnits 2.17.1 draft-ietf-smime-3278bis-03.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 2288. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2299. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2306. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2312. 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 directly say this. It does mention RFC3278 though, so this could be OK. 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 (October 22, 2008) is 5658 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 2112 -- Looks like a reference, but probably isn't: '2' on line 2113 ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) -- Obsolete informational reference (is this intentional?): RFC 3278 (ref. 'CMS-ECC') (Obsoleted by RFC 5753) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 11 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 October 22, 2008 4 Obsoletes: 3278 (once approved) 5 Expires: April 22, 2009 7 Use of Elliptic Curve Cryptography (ECC) Algorithms 8 in Cryptographic Message Syntax (CMS) 9 draft-ietf-smime-3278bis-03.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 April 22, 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 for key agreement, RFC 3565 and RFC 48 3370 for key wrap and content encryption, NIST FIPS 180-3 for message 49 digest, and RFC 2104 and RFC 4231 for message authentication code 50 standards. This document will obsolete RFC 3278. 52 Discussion 54 This draft is being discussed on the 'ietf-smime' mailing list. To 55 subscribe, send a message to ietf-smime-request@imc.org with the 56 single word subscribe in the body of the message. There is a Web site 57 for the mailing list at . 59 Table of Contents 61 1. Introduction...................................................2 62 1.1. Requirements Terminology..................................3 63 1.2. Changes since RFC 3278....................................3 64 2. SignedData using ECC...........................................5 65 2.1. SignedData using ECDSA....................................6 66 3. EnvelopedData using ECC Algorithms.............................7 67 3.1. EnvelopedData using (ephemeral-static) ECDH...............7 68 3.2. EnvelopedData using 1-Pass ECMQV..........................9 69 4. AuthenticatedData and AuthEnvelopedData using ECC.............12 70 4.1. AuthenticatedData using 1-pass ECMQV.....................12 71 4.2. AuthEnvelopedData using 1-pass ECMQV.....................13 72 5. Certificates using ECC........................................14 73 6. SMIMECapabilities Attribute and ECC...........................14 74 7. ASN.1 Syntax..................................................17 75 7.1. Algorithm Identifiers....................................17 76 7.2. Other Syntax.............................................20 77 8. Recommended Algorithms and Elliptic Curves....................22 78 9. Security Considerations.......................................24 79 10. IANA Considerations..........................................29 80 11. References...................................................29 81 11.1. Normative...............................................29 82 11.2. Informative.............................................31 83 Appendix A ASN.1 Modules.........................................33 84 Appendix A.1 1988 ASN.1 Module................................33 85 Appendix A.2 2004 ASN.1 Module................................40 87 1. Introduction 89 The Cryptographic Message Syntax (CMS) is cryptographic algorithm 90 independent. This specification defines a profile for the use of 91 Elliptic Curve Cryptography (ECC) public key algorithms in the CMS. 93 The ECC algorithms are incorporated into the following CMS content 94 types: 96 - 'SignedData' to support ECC-based digital signature methods 97 (ECDSA) to sign content; 99 - 'EnvelopedData' to support ECC-based public-key agreement 100 methods (ECDH and ECMQV) to generate pairwise key-encryption 101 keys to encrypt content-encryption keys used for content 102 encryption; 104 - 'AuthenticatedData' to support ECC-based public-key agreement 105 methods (ECMQV) to generate pairwise key-encryption keys to 106 encrypt message authenticate code (MAC) keys used for content 107 authentication and integrity; and, 109 - 'AuthEnvelopedData' to support ECC-based public-key agreement 110 methods (ECMQV) to generate pairwise key-encryption keys to 111 encrypt MAC keys used for authenticated encryption modes. 113 Certification of EC public keys is also described to provide public- 114 key distribution in support of the specified techniques. 116 The document will obsolete [CMS-ECC]. 118 1.1. Requirements Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [MUST]. 124 1.2. Changes since RFC 3278 126 The following summarizes the changes: 128 - Abstract: The basis of the document was changed to refer to NIST 129 FIPP 186-3 and SP800-56A. 131 - Section 1: A bullet was added to address AuthEnvelopedData. 133 - Section 2.1: A sentence was added to indicate FIPS180-3 is used 134 with ECDSA. Replaced reference to ANSI X9.62 with FIPS186-3. 136 - Section 2.1.1: The permitted digest algorithms were expanded from 137 SHA-1 to SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. 139 - Section 2.1.2 and 2.1.3: The bullet addressing integer "e" was 140 deleted. 142 - Section 3: Added explanation of why static-static ECDH is not 143 included. 145 - Section 3.1: The reference for DH was changed from CMS to CMS- 146 ALG. Provided text to indicate fields of EnvelopedData are as 147 in CMS. 149 - Section 3.1.1: The permitted digest algorithms for use with ECDH 150 std and cofactor methods were expanded from SHA-1 to SHA-1, SHA- 151 224, SHA-256, SHA-384, and SHA-512. Updated to include 152 description of all KeyAgreeRecipientInfo fields. Parameters for 153 id-ecPublicKey field changed from NULL to absent or ECPoint. 154 Additional information about ukm was added. 156 - Section 3.2: The sentence describing the advantages of 1-Pass 157 ECMQV was rewritten. 159 - Section 3.2.1: The permitted digest algorithms for use with ECMQV 160 were expanded from SHA-1 to SHA-1, SHA-224, SHA-256, SHA-384, 161 and SHA-512. Updated to include description of all fields. 162 Parameters for id-ecPublicKey field changed from NULL to absent 163 or ECPoint. 165 - Sections 3.2.2 and 4.1.2: The re-use of ephemeral keys paragraph 166 was reworded. 168 - Section 4.1: The sentences describing the advantages of 1-Pass 169 ECMQV was moved to Section 4. 171 - Section 4.1.2: The note about the attack was moved to Section 4. 173 - Section 4.2: This section was added to address AuthEnvelopedData 174 with ECMQV. 176 - Section 5: This section was moved to Section 8. The 1st 177 paragraph was modified to require both SignedData and 178 EnvelopedData. The requirements were updated for hash 179 algorithms and recommendations for matching curves and hash 180 algorithms. Also the requirements were expanded to indicate 181 which ECDH and ECMQV variants, key wrap algorithms, and content 182 encryption algorithms are required for each of the content types 183 used in this document. 185 - Section 5 (formerly 6): This section was updated to allow for 186 SMIMECapabilities to be present certificates. 188 - Section 6 (formerly 7): The S/MIME capabilities for ECDSA with 189 SHA-224, SHA-256, SHA-384, and SHA-512 were added to the list of 190 S/MIME Capabilities. Also updated to include S/MIME 191 capabilities for ECDH and ECMQV using the SHA-224, SHA-256, SHA- 192 384, and SHA-512 algorithms as the KDF. 194 - Section 7.1 (formerly 8.1): Added sub-sections for digest, 195 signature, originator public key, key agreement, content 196 encryption, and message authentication code algorithms. Pointed 197 to algorithms and parameters in appropriate docummments for: 198 SHA-224, SHA-256, SHA-384, and SHA-512 as well as SHA-224, SHA- 199 256, SHA-384, and SHA-512 with ECDSA. Also added algorithm 200 identifiers for ECDH std, ECDH cofactor, and ECMQV with SHA-224, 201 SHA-256, SHA-384, and SHA-512 algorithms as the KDF. Changed 202 id-ecPublicKey parameters to be absent, NULL, and ECParameters 203 and if present the originator's ECParameters must match the 204 recipient's ECParameters. 206 - Section 7.2 (formerly 8.2): Updated to include AuthEnvelopedData. 207 Also, added text to address support requirement for compressed 208 and uncompressed keys, changed pointers from ANSI X9.61 to PKIX 209 (where ECDSA-Sig-Value is imported), changed pointers from SECG 210 to NIST specs, and updated example of suppPubInfo to be AES-256. 211 keyInfo's parameters changed from NULL to any associated 212 parameters (AES wraps have absent parameters). 214 - Section 9: Replaced text, which was a summary paragraph, with an 215 updated security considerations section. Paragraph referring to 216 definitions of SHA-224, SHA-256, SHA-384, and SHA-512 is 217 deleted. 219 - Updated references. 221 - Added ASN.1 modules. 223 - Updated acknowledgements section. 225 2. SignedData using ECC 227 This section describes how to use ECC algorithms with the CMS 228 SignedData format to sign data. 230 2.1. SignedData using ECDSA 232 This section describes how to use the Elliptic Curve Digital 233 Signature Algorithm (ECDSA) with SignedData. ECDSA is specified in 234 [FIPS186-3]. The method is the elliptic curve analog of the Digital 235 Signature Algorithm (DSA) [FIPS186-3]. ECDSA is used with the Secure 236 Hash Algorithm (SHA) [FIPS180-3]. 238 In an implementation that uses ECDSA with CMS SignedData, the 239 following techniques and formats MUST be used. 241 2.1.1. Fields of the SignedData 243 When using ECDSA with SignedData, the fields of SignerInfo are as in 244 [CMS], but with the following restrictions: 246 - digestAlgorithm MUST contain the algorithm identifier of the hash 247 algorithm (see Section 7.1) which MUST be one of the following: 248 id-sha1, id-sha224, id-sha256, id-sha384, or id-sha512. 250 - signatureAlgorithm contains the signature algorithm identifier 251 (see Section 7.1): ecdsa-with-SHA1, ecdsa-with-SHA224, ecdsa- 252 with-SHA256, ecdsa-with-SHA384, or ecdsa-with-SHA512. 254 - signature MUST contain the DER encoding (as an octet string) of a 255 value of the ASN.1 type ECDSA-Sig-Value (see Section 7.2). 257 When using ECDSA, the SignedData certificates field MAY include the 258 certificate(s) for the EC public key(s) used in the generation of the 259 ECDSA signatures in SignedData. ECC certificates are discussed in 260 Section 5. 262 2.1.2. Actions of the sending agent 264 When using ECDSA with SignedData, the sending agent uses the message 265 digest calculation process and signature generation process for 266 SignedData that are specified in [CMS]. To sign data, the sending 267 agent uses the signature method specified in [FIPS186-3]. 269 The sending agent encodes the resulting signature using the 270 ECDSA-Sig-Value syntax (see Section 7.2) and places it in the 271 SignerInfo.signature field. 273 2.1.3. Actions of the receiving agent 275 When using ECDSA with SignedData, the receiving agent uses the 276 message digest calculation process and signature verification process 277 for SignedData that are specified in [CMS]. To verify SignedData, 278 the receiving agent uses the signature verification method specified 279 in [FIPS186-3]. 281 In order to verify the signature, the receiving agent retrieves the 282 integers r and s from the SignerInfo signature field of the received 283 message. 285 3. EnvelopedData using ECC Algorithms 287 This section describes how to use ECC algorithms with the CMS 288 EnvelopedData format. 290 This document does not specify the static-static ECDH, method C(0,2, 291 ECC CDH) from [SP800-56A]. Static-static ECDH is analogous to 292 static-static DH, which is specified in [CMS-ALG]. Ephemeral-static 293 ECDH and 1-Pass ECMQV were specified because they provide better 294 security due the originator's ephemeral contribution to the key 295 agreement scheme. 297 3.1. EnvelopedData using (ephemeral-static) ECDH 299 This section describes how to use the ephemeral-static Elliptic Curve 300 Diffie-Hellman (ECDH) key agreement algorithm with EnvelopedData, 301 method C(1, 1, ECC CDH) from [SP800-56A]. Ephemeral-static ECDH is 302 the elliptic curve analog of the ephemeral-static Diffie-Hellman key 303 agreement algorithm specified jointly in the documents [CMS-ALG] and 304 [CMS-DH]. 306 If an implementation uses ECDH with CMS EnvelopedData, then the 307 following techniques and formats MUST be used. 309 The fields of EnvelopedData are as in [CMS], as ECDH is a key 310 agreement algorithm the RecipientInfo kari choice is used. When 311 using ECDH, the EnvelopedData originatorInfo field MAY include the 312 certificate(s) for the EC public key(s) used in the formation of the 313 pairwise key. ECC certificates are discussed in Section 5. 315 3.1.1. Fields of KeyAgreeRecipientInfo 317 When using ephemeral-static ECDH with EnvelopedData, the fields of 318 KeyAgreeRecipientInfo are as follows: 320 - version MUST be 3. 322 - originator MUST be the alternative originatorKey. The 323 originatorKey algorithm field MUST contain the id-ecPublicKey 324 object identifier (see Section 7.1). The parameters associated 325 with id-ecPublicKey MUST be absent or ECParameters. NOTE: The 326 previous version of this document required NULL to be present, 327 support for this legacy form is OPTIONAL. The originatorKey 328 publicKey field MUST contain the value of the ASN.1 type ECPoint 329 (see Section 7.2), which represents the sending agent's 330 ephemeral EC public key. The ECPoint in uncompressed form MUST 331 be supported. 333 - ukm MAY be present or absent. However, message originators 334 SHOULD include the ukm. As specified in RFC 3852 [CMS], 335 implementations MUST support ukm message recipient processing, 336 so interoperability is not a concern if the ukm is present or 337 absent. The ukm is placed in the entityUInfo field of the ECC- 338 CMS-SharedInfo structure. When present, the ukm is used to 339 ensure that a different key-encryption key is generated, even 340 when the ephemeral private key is improperly used more than 341 once, by using the ECC-CMS-SharedInfo as an input to the key 342 derivation function (see Section 7.2). 344 - keyEncryptionAlgorithm MUST contain the key encryption algorithm 345 object identifier (see Section 7.1). The parameters field 346 contains KeyWrapAlgorithm. The KeyWrapAlgorithm is the 347 algorithm identifier that indicates the symmetric encryption 348 algorithm used to encrypt the content-encryption key (CEK) with 349 the key-encryption key (KEK) and any associated parameters. 350 Algorithm requirements are found in Section 8. 352 - recipientEncryptedKeys contains an identifier and an encrypted 353 key for each recipient. The RecipientEncryptedKey 354 KeyAgreeRecipientIdentifier MUST contain either the 355 issuerAndSerialNumber identifying the recipient's certificate or 356 the RecipientKeyIdentifier containing the subject key identifier 357 from the recipient's certificate. In both cases, the 358 recipient's certificate contains the recipient's static ECDH 359 public key. RecipientEncryptedKey EncryptedKey MUST contain the 360 content-encryption key encrypted with the ephemeral-static, 361 ECDH-generated pairwise key-encryption key using the algorithm 362 specified by the KeyWrapAlgorithm. 364 3.1.2. Actions of the sending agent 366 When using ephemeral-static ECDH with EnvelopedData, the sending 367 agent first obtains the recipient's EC public key and domain 368 parameters (e.g. from the recipient's certificate). The sending 369 agent then determines an integer "keydatalen", which is the 370 KeyWrapAlgorithm symmetric key-size in bits, and also a bit string 371 "SharedInfo", which is the DER encoding of ECC-CMS-SharedInfo (see 372 Section 7.2). The sending agent then performs the key deployment and 373 the key agreement operation of the Elliptic Curve Diffie-Hellman 374 Scheme specified in [SP800-56A]. As a result the sending agent 375 obtains: 377 - an ephemeral public key, which is represented as a value of the 378 type ECPoint (see Section 7.2), encapsulated in a bit string and 379 placed in the KeyAgreeRecipientInfo originator field, and 381 - a shared secret bit string "K", which is used as the pairwise 382 key-encryption key for that recipient, as specified in [CMS]. 384 3.1.3. Actions of the receiving agent 386 When using ephemeral-static ECDH with EnvelopedData, the receiving 387 agent determines the bit string "SharedInfo", which is the DER 388 encoding of ECC-CMS-SharedInfo (see Section 7.2), and the integer 389 "keydatalen" from the key-size, in bits, of the KeyWrapAlgorithm. The 390 receiving agent retrieves the ephemeral EC public key from the bit 391 string KeyAgreeRecipientInfo originator, with a value of the type 392 ECPoint (see Section 7.2) encapsulated as a bit string, and if 393 present, originally supplied additional user key material from the 394 ukm field. The receiving agent performs the key agreement operation 395 of the Elliptic Curve Diffie-Hellman Scheme specified in [SP800-56A]. 396 As a result, the receiving agent obtains a shared secret bit string 397 "K", which is used as the pairwise key-encryption key to unwrap the 398 CEK. 400 3.2. EnvelopedData using 1-Pass ECMQV 402 This section describes how to use the 1-Pass elliptic curve MQV 403 (ECMQV) key agreement algorithm with EnvelopedData, method 404 C(1, 2, ECC MQV) from [SP800-56A]. Like the KEA algorithm [CMS-KEA], 405 1-Pass ECMQV uses three key pairs: an ephemeral key pair, a static 406 key pair of the sending agent, and a static key pair of the receiving 407 agent. Using an algorithm with the sender static key pair allows for 408 knowledge of the message creator, this means that authentication can, 409 in some circumstances, be obtained for AuthEnvelopedData and 410 AuthenticatedData. This means that 1-Pass ECMQV can be a common 411 algorithm for EnvelopedData, AuthenticatedData and AuthEnvelopedData, 412 while ECDH can only be used in EnvelopedData. 414 If an implementation uses 1-Pass ECMQV with CMS EnvelopedData, then 415 the following techniques and formats MUST be used. 417 The fields of EnvelopedData are as in [CMS], as 1-Pass ECMQV is a key 418 agreement algorithm the RecipientInfo kari choice is used. When 419 using 1-Pass ECMQV, the EnvelopedData originatorInfo field MAY 420 include the certificate(s) for the EC public key(s) used in the 421 formation of the pairwise key. ECC certificates are discussed in 422 Section 5. 424 3.2.1. Fields of KeyAgreeRecipientInfo 426 When using 1-Pass ECMQV with EnvelopedData, the fields of 427 KeyAgreeRecipientInfo are: 429 - version MUST be 3. 431 - originator identifies the static EC public key of the sender. It 432 SHOULD be one of the alternatives, issuerAndSerialNumber or 433 subjectKeyIdentifier, and point to one of the sending agent's 434 certificates. 436 - ukm MUST be present. The ukm field is an octet string which MUST 437 contain the DER encoding of the type MQVuserKeyingMaterial (see 438 Section 7.2). The MQVuserKeyingMaterial ephemeralPublicKey 439 algorithm field MUST contain the id-ecPublicKey object 440 identifier (see Section 7.1). The parameters associated with 441 id-ecPublicKey MUST be absent or ECParameters. NOTE: The 442 previous version of this document required NULL to be present, 443 support for this legacy form is OPTIONAL. The 444 MQVuserKeyingMaterial ephemeralPublicKey publicKey field MUST 445 contain the DER-encoding of the ASN.1 type ECPoint (see Section 446 7.2) representing the sending agent's ephemeral EC public key. 447 The MQVuserKeyingMaterial addedukm field, if present, contains 448 additional user keying material from the sending agent. 450 - keyEncryptionAlgorithm MUST be the key encryption algorithm 451 identifier (see Section 7.1), with the parameters field 452 KeyWrapAlgorithm. The KeyWrapAlgorithm indicates the symmetric 453 encryption algorithm used to encrypt the CEK with the KEK 454 generated using the 1-Pass ECMQV algorithm and any associated 455 parameters. Algorithm requirements are found in Section 8. 457 - recipientEncryptedKeys contains an identifier and an encrypted 458 key for each recipient. The RecipientEncryptedKey 459 KeyAgreeRecipientIdentifier MUST contain either the 460 issuerAndSerialNumber identifying the recipient's certificate or 461 the RecipientKeyIdentifier containing the subject key identifier 462 from the recipient's certificate. In both cases, the 463 recipient's certificate contains the recipient's static ECMQV 464 public key. RecipientEncryptedKey EncryptedKey MUST contain the 465 content-encryption key encrypted with the 1-Pass ECMQV-generated 466 pairwise key-encryption key using the algorithm specified by the 467 KeyWrapAlgorithm. 469 3.2.2. Actions of the sending agent 471 When using 1-Pass ECMQV with EnvelopedData, the sending agent first 472 obtains the recipient's EC public key and domain parameters (e.g. 473 from the recipient's certificate), and checks that the domain 474 parameters are the same as the sender's domain parameters. The 475 sending agent then determines an integer "keydatalen", which is the 476 KeyWrapAlgorithm symmetric key-size in bits, and also a bit string 477 "SharedInfo", which is the DER encoding of ECC-CMS-SharedInfo (see 478 Section 7.2). The sending agent then performs the key deployment and 479 key agreement operations of the Elliptic Curve MQV Scheme specified 480 in [SP800-56A]. As a result, the sending agent obtains: 482 - an ephemeral public key, which is represented as a value of type 483 ECPoint (see Section 7.2), encapsulated in a bit string, placed 484 in an MQVuserKeyingMaterial ephemeralPublicKey publicKey field 485 (see Section 7.2), and 487 - a shared secret bit string "K", which is used as the pairwise 488 key-encryption key for that recipient, as specified in [CMS]. 490 In a single message, if there are multiple layers for a recipient, 491 then the ephemeral public key can be reused by the originator for 492 that recipient in each of the different layers. 494 3.2.3. Actions of the receiving agent 496 When using 1-Pass ECMQV with EnvelopedData, the receiving agent 497 determines the bit string "SharedInfo", which is the DER encoding of 498 ECC-CMS-SharedInfo (see Section 7.2), and the integer "keydatalen" 499 from the key-size, in bits, of the KeyWrapAlgorithm. The receiving 500 agent then retrieves the static and ephemeral EC public keys of the 501 originator, from the originator and ukm fields as described in 502 Section 3.2.1, and its static EC public key identified in the rid 503 field and checks that the domain parameters are the same as the 504 recipient's domain parameters. The receiving agent then performs the 505 key agreement operation of the Elliptic Curve MQV Scheme [SP800-56A]. 506 As a result, the receiving agent obtains a shared secret bit string 507 "K" which is used as the pairwise key-encryption key to unwrap the 508 CEK. 510 4. AuthenticatedData and AuthEnvelopedData using ECC 512 This section describes how to use ECC algorithms with the CMS 513 AuthenticatedData format. AuthenticatedData lacks non-repudiation, 514 and so in some instances is preferable to SignedData. (For example, 515 the sending agent might not want the message to be authenticated when 516 forwarded.) 518 This section also describes how to use ECC algorithms with the CMS 519 AuthEnvelopedData format [CMS-AUTHENV]. AuthEnvelopedData supports 520 authentication and encryption, and in some instances is preferable to 521 signing and then encrypting data. 523 For both AuthentictedData and AuthEnvelopedData, data origin 524 authentication with 1-Pass ECMQV can only be provided when there is 525 one and only one recipient. When there are multiple recipients, an 526 attack is possible where one recipient modifies the content without 527 other recipients noticing [BON]. A sending agent who is concerned 528 with such an attack SHOULD use a separate AuthenticatedData or 529 AuthEnvelopedData for each recipient. 531 Using an algorithm with the sender static key pair allows for 532 knowledge of the message creator, this means that authentication can, 533 in some circumstances, be obtained for AuthEnvelopedData and 534 AuthenticatedData. This means that 1-Pass ECMQV can be a common 535 algorithm for EnvelopedData, AuthenticatedData, and AuthEnvelopedData 536 while ECDH can only be used in EnvelopedData. 538 4.1. AuthenticatedData using 1-pass ECMQV 540 This section describes how to use the 1-Pass elliptic curve MQV 541 (ECMQV) key agreement algorithm with AuthenticatedData. ECMQV is 542 method C(1, 2, ECC MQV) from [SP800-56A]. 544 When using ECMQV with AuthenticatedData, the fields of 545 AuthenticatedData are as in [CMS], but with the following 546 restrictions: 548 - macAlgorithm MUST contain the algorithm identifier of the message 549 authentication code algorithm (see Section 7.1) which MUST be 550 one of the following: hmac-SHA1, id-hmacWITHSHA224, id- 551 hmacWITHSHA256, id-hmacWITHSHA384, or id-hmacWITHSHA512. 553 - digestAlgorithm MUST contain the algorithm identifier of the hash 554 algorithm (see Section 7.1) which MUST be one of the following: 555 id-sha1, id-sha224, id-sha256, id-sha384, and id-sha512. 557 As 1-Pass ECMQV is a key agreement algorithm, the RecipientInfo kari 558 choice is used in the AuthenticatedData. When using 1-Pass ECMQV, 559 the AuthenticatedData originatorInfo field MAY include the 560 certificate(s) for the EC public key(s) used in the formation of the 561 pairwise key. ECC certificates are discussed in Section 5. 563 4.1.1. Fields of the KeyAgreeRecipientInfo 565 The AuthenticatedData KeyAgreeRecipientInfo fields are used in the 566 same manner as the fields for the corresponding EnvelopedData 567 KeyAgreeRecipientInfo fields of Section 3.2.1 of this document. 569 4.1.2. Actions of the sending agent 571 The sending agent uses the same actions as for EnvelopedData with 572 1-Pass ECMQV, as specified in Section 3.2.2 of this document. 574 In a single message, if there are multiple layers for a recipient, 575 then the ephemeral public key can be reused by the originator for 576 that recipient in each of the different layers. 578 4.1.3. Actions of the receiving agent 580 The receiving agent uses the same actions as for EnvelopedData with 581 1-Pass ECMQV, as specified in Section 3.2.3 of this document. 583 4.2. AuthEnvelopedData using 1-pass ECMQV 585 This section describes how to use the 1-Pass elliptic curve MQV 586 (ECMQV) key agreement algorithm with AuthEnvelopedData. ECMQV is 587 method C(1, 2, ECC MQV) from [SP800-56A]. 589 When using ECMQV with AuthEnvelopedData, the fields of 590 AuthenticatedData are as in [CMS-AUTHENV], but with the following 591 restriction: 593 - macAlgorithm MUST contain the algorithm identifier of the message 594 authentication code algorithm (see Section 7.1) which MUST be 595 one of the following: hmac-SHA1, id-hmacWITHSHA224, id- 596 hmacWITHSHA256, id-hmacWITHSHA384, or id-hmacWITHSHA512. 598 As 1-Pass ECMQV is a key agreement algorithm, the RecipientInfo kari 599 choice is used. When using 1-Pass ECMQV, the AuthEnvelopedData 600 originatorInfo field MAY include the certificate(s) for the EC public 601 key(s) used in the formation of the pairwise key. ECC certificates 602 are discussed in Section 5. 604 4.2.1. Fields of the KeyAgreeRecipientInfo 606 The AuthEnvelopedData KeyAgreeRecipientInfo fields are used in the 607 same manner as the fields for the corresponding EnvelopedData 608 KeyAgreeRecipientInfo fields of Section 3.2.1 of this document. 610 4.2.2. Actions of the sending agent 612 The sending agent uses the same actions as for EnvelopedData with 1- 613 Pass ECMQV, as specified in Section 3.2.2 of this document. 615 In a single message, if there are multiple layers for a recipient, 616 then the ephemeral public key can be reused by the originator for 617 that recipient in each of the different layers. 619 4.2.3. Actions of the receiving agent 621 The receiving agent uses the same actions as for EnvelopedData with 622 1-Pass ECMQV, as specified in Section 3.2.3 of this document. 624 5. Certificates using ECC 626 Internet X.509 certificates [PKI] can be used in conjunction with 627 this specification to distribute agents' public keys. The use of ECC 628 algorithms and keys within X.509 certificates is specified in [PKI- 629 ALG]. 631 6. SMIMECapabilities Attribute and ECC 633 A sending agent MAY announce to receiving agents that it supports one 634 or more of the ECC algorithms specified in this document by using the 635 SMIMECapabilities signed attribute [MSG] in either a signed message 636 or a certificate [CERTCAP]. 638 The SMIMECapability value to indicate support for one of the ECDSA 639 signature algorithms is a SEQUENCE with the capabilityID field 640 containing the object identifier ecdsa-with-SHA* (where * is 1, 224, 641 256, 384, or 512) with NULL parameters. The DER encodings are: 643 ecdsa-with-SHA1: 30 0b 06 07 2a 86 48 ce 3d 04 01 05 00 645 ecdsa-with-SHA224: 30 0c 06 08 2a 86 48 ce 3d 04 03 01 05 00 647 ecdsa-with-SHA256: 30 0c 06 08 2a 86 48 ce 3d 04 03 02 05 00 649 ecdsa-with-SHA384: 30 0c 06 08 2a 86 48 ce 3d 04 03 03 05 00 651 ecdsa-with-SHA512: 30 0c 06 08 2a 86 48 ce 3d 04 03 04 05 00 653 NOTE: The S/MIME Capabilities indicates that parameters for ECDSA 654 with SHA-* are NULL (where * is 1, 224, 256, 384, or 512), however, 655 the parameters are absent when used to generate a digital signature. 657 The SMIMECapability value to indicate support for 658 a) the standard ECDH key agreement algorithm, 659 b) the cofactor ECDH key agreement algorithm, or 660 c) the 1-Pass ECMQV key agreement algorithm 661 is a SEQUENCE with the capabilityID field containing the object 662 identifier 663 a) dhSinglePass-stdDH-sha*kdf-scheme, 664 b) dhSinglePass-cofactorDH-sha*kdf-scheme, or 665 c) mqvSinglePass-sha*kdf-scheme 666 respectively (where * is 1, 224, 256, 384, or 512) with the 667 parameters present. The parameters indicate the supported key- 668 encryption algorithm with the KeyWrapAlgorithm algorithm identifier. 670 Example DER encodings that indicate some capabilities are as follows 671 (KA is key agreement, KDF is key derivation function, and Wrap is key 672 wrap algorithm): 674 KA=ECDH standard KDF=SHA-1 Wrap=Triple-DES 676 30 1c 677 06 09 2b 81 05 10 86 48 3f 00 02 678 30 0f 679 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 680 05 00 682 KA=ECDH standard KDF=SHA-256 Wrap=AES-128 684 30 17 685 06 06 2b 81 04 01 0B 01 686 30 0d 687 06 09 60 86 48 01 65 03 04 01 05 688 05 00 690 KA=ECDH standard KDF=SHA-384 Wrap=AES-256 692 30 17 693 06 06 2b 81 04 01 0B 02 694 30 0d 695 06 09 60 86 48 01 65 03 04 01 2D 696 05 00 698 KA=ECDH cofactor KDF=SHA-1 Wrap=Triple-DES 700 30 1c 701 06 09 2b 81 05 10 86 48 3f 00 03 702 30 0f 703 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 704 05 00 706 KA=ECDH cofactor KDF=SHA-256 Wrap=AES-128 708 30 17 709 06 06 2b 81 04 01 0E 01 710 30 0d 711 06 09 60 86 48 01 65 03 04 01 05 712 05 00 714 KA=ECDH cofactor KDF=SHA-384 Wrap=AES-256 716 30 17 717 06 06 2b 81 04 01 0E 02 718 30 0d 719 06 09 60 86 48 01 65 03 04 01 2D 720 05 00 722 KA=ECMQV 1-Pass KDF=SHA-1 Wrap=Triple-DES 724 30 1c 725 06 09 2b 81 05 10 86 48 3f 00 10 726 30 0f 727 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 728 05 00 730 KA=ECMQV 1-Pass KDF=SHA-256 Wrap=AES-128 732 30 17 733 06 06 2b 81 04 01 0F 01 734 30 0d 735 06 09 60 86 48 01 65 03 04 01 05 736 05 00 738 KA=ECMQV 1-Pass KDF=SHA-384 Wrap=AES-256 740 30 17 741 06 06 2b 81 04 01 0F 02 742 30 0d 743 06 09 60 86 48 01 65 03 04 01 2D 744 05 00 746 NOTE: The S/MIME Capabilities indicates that parameters for the key 747 wrap algorithm AES-* (where * is 128, 192, or 256) are NULL; however, 748 the parameters are absent when used to encrypt/decrypt a content 749 encryption key. 751 7. ASN.1 Syntax 753 The ASN.1 syntax used in this document is gathered in this section 754 for reference purposes. 756 7.1. Algorithm Identifiers 758 This section provides the object identifiers for the algorithms used 759 in this document along with any associated parameters. 761 7.1.1. Digest Algorithms 763 Digest algorithm object identifiers are used in the SignedData 764 digestAlgorithms and digestAlgorithm fields and the AuthenticatedData 765 digestAlgorithm field. The digest algorithms used in this document 766 are: SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. The object 767 identifiers and parameters associated with these algorithms are found 768 in [CMS-ALG] and [CMS-SHA2]. 770 7.1.2. Originator Public Key 772 The KeyAgreeRecipientInfo originator field use the following object 773 identifier to indicate an elliptic curve public key: 775 id-ecPublicKey OBJECT IDENTIFIER ::= { 776 ansi-x9-62 keyType(2) 1 } 778 where 780 ansi-x9-62 OBJECT IDENTIFIER ::= { 781 iso(1) member-body(2) us(840) 10045 } 783 When the object identifier id-ecPublicKey is used here with an 784 algorithm identifier, the associated parameters MUST be either absent 785 or ECParameters. Implementations MUST accept id-ecPublicKey with 786 absent, and ECParameters parameters. If ECParameters is present, its 787 value MUST match the recipients ECParameters. Implementations SHOULD 788 generate absent parameters for the id-ecPublicKey object identifier 789 in the KeyAgreeRecipientInfo originator field. 791 NOTE: [CMS-ECC] indicated the parameters were NULL. Support for NULL 792 parameters is OPTIONAL. 794 7.1.3. Signature Algorithms 796 Signature algorithm identifiers are used in the SignedData 797 signatureAlgorithm and signature field. The signature algorithms 798 used in this document are ECDSA with SHA-1, ECDSA with SHA-224, ECDSA 799 with SHA-256, ECDSA with SHA-384, and ECDSA with SHA-512. The object 800 identifiers and parameters associated with these algorithms are found 801 in [PKI-ALG]. 803 NOTE: [CMS-ECC] indicated the parameters were NULL. Support for NULL 804 parameters is OPTIONAL. 806 7.1.4. Key Agreement Algorithms 808 Key agreement algorithms are used in EnvelopedData, 809 AuthenticatedData, and AuthEnvelopedData in the KeyAgreeRecipientInfo 810 keyEncryptionAlgorithm field. The following object identifiers 811 indicate the key agreement algorithms used in this document [SP800- 812 56A]: 814 dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 815 x9-63-scheme 2 } 817 dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 818 secg-scheme 11 0 } 820 dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 821 secg-scheme 11 1 } 823 dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 824 secg-scheme 11 2 } 826 dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 827 secg-scheme 11 3 } 829 dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 830 x9-63-scheme 3 } 832 dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 833 secg-scheme 14 0 } 835 dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 836 secg-scheme 14 1 } 838 dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 839 secg-scheme 14 2 } 841 dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 842 secg-scheme 14 3 } 844 mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= { 845 x9-63-scheme 16 } 847 mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= { 848 secg-scheme 15 0 } 850 mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= { 851 secg-scheme 15 1 } 853 mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= { 854 secg-scheme 15 2 } 856 mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= { 857 secg-scheme 15 3 } 859 where 861 x9-63-scheme OBJECT IDENTIFIER ::= { 862 iso(1) identified-organization(3) tc68(133) country(16) 863 x9(840) x9-63(63) schemes(0) } 865 and 867 secg-scheme OBJECT IDENTIFIER ::= { 868 iso(1) identified-organization(3) certicom(132) schemes(1) } 870 When the object identifiers are used here within an algorithm 871 identifier, the associated parameters field contains KeyWrapAlgorithm 872 to indicate the key wrap algorithm and any associated parameters. 874 7.1.5. Key Wrap Algorithms 876 Key wrap algorithms are used as part of the parameters in the key 877 agreement algorithm. The key wrap algorithms used in this document 878 are Triple-DES, AES-128, AES-192, and AES-256. The object 879 identifiers and parameters for these algorithms are found in [CMS- 880 ALG] and [CMS-AES]. 882 7.1.6. Content Encryption Algorithms 884 Content encryption algorithms are used in EnvelopedData and 885 AuthEnvelopedData in the EncryptedContentInfo 886 contentEncryptionAlgorithm field. The content encryption algorithms 887 used with EnvelopedData in this document are 3-Key Triple DES in CBC 888 mode, AES-128 in CBC mode, AES-192 in CBC mode, and AES-256 in CBC 889 mode. The object identifiers and parameters associated with these 890 algorithms are found in [CMS-ALG] and [CMS-AES]. The content 891 encryption algorithms used with AuthEnvelopedData in this document 892 are AES-128 in CCM mode, AES-192 in CCM mode, AES-256 in CCM mode, 893 AES-128 in GCM mode, AES-192 in GCM mode, and AES-256 in GCM mode. 894 The object identifiers and parameters associated with these 895 algorithms are found in [CMS-AESCG]. 897 7.1.7. Message Authentication Code Algorithms 899 Message authentication code algorithms are used in AuthenticatedData 900 and AuthEnvelopedData in the macAlgorithm field. The message 901 authentication code algorithms used in this document are HMAC with 902 SHA-1, HMAC with SHA-224, HMAC with SHA-256, HMAC with SHA-384, and 903 HMAC with SHA-512. The object identifiers and parameters associated 904 with these algorithms are found in [HMAC-SHA1] and [HMAC-SHA2]. 906 7.2. Other Syntax 908 The following additional syntax is used here. 910 When using ECDSA with SignedData, ECDSA signatures are encoded using 911 the type: 913 ECDSA-Sig-Value ::= SEQUENCE { 914 r INTEGER, 915 s INTEGER } 917 ECDSA-Sig-Value is specified in [PKI-ALG]. Within CMS, ECDSA-Sig- 918 Value is DER-encoded and placed within a signature field of 919 SignedData. 921 When using ECDH and ECMQV with EnvelopedData, AuthenticatedData, and 922 AuthEnvelopedData, ephemeral and static public keys are encoded using 923 the type ECPoint. Implementations MUST support uncompressed keys and 924 MAY support compressed keys. 926 ECPoint ::= OCTET STRING 928 When using ECMQV with EnvelopedData, AuthenticatedData, and 929 AuthEnvelopedData, the sending agent's ephemeral public key and 930 additional keying material are encoded using the type: 932 MQVuserKeyingMaterial ::= SEQUENCE { 933 ephemeralPublicKey OriginatorPublicKey, 934 addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL } 936 The ECPoint syntax is used to represent the ephemeral public key and 937 is placed in the ephemeralPublicKey.publicKey field. The additional 938 user keying material is placed in the addedukm field. Then the 939 MQVuserKeyingMaterial value is DER-encoded and placed within the ukm 940 field of EnvelopedData, AuthenticatedData, or AuthEnvelopedData. 942 When using ECDH or ECMQV with EnvelopedData, AuthenticatedData, or 943 AuthEnvelopedData, the key-encryption keys are derived by using the 944 type: 946 ECC-CMS-SharedInfo ::= SEQUENCE { 947 keyInfo AlgorithmIdentifier, 948 entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL, 949 suppPubInfo [2] EXPLICIT OCTET STRING } 951 The fields of ECC-CMS-SharedInfo are as follows: 953 keyInfo contains the object identifier of the key-encryption 954 algorithm (used to wrap the CEK) and associated parameters. In 955 this specification, 3DES wrap has NULL parameters while the AES 956 wraps have absent parameters. 958 entityUInfo optionally contains additional keying material 959 supplied by the sending agent. When used with ECDH and CMS, the 960 entityUInfo field contains the octet string ukm. When used with 961 ECMQV and CMS, the entityUInfo contains the octet string addedukm 962 (encoded in MQVuserKeyingMaterial). 964 suppPubInfo contains the length of the generated KEK, in bits, 965 represented as a 32 bit number, as in [CMS-DH] and [CMS-AES]. 966 (E.g. for AES-256 it would be 00 00 01 00.) 968 Within CMS, ECC-CMS-SharedInfo is DER-encoded and used as input to 969 the key derivation function, as specified in [SP800-56A]. 971 Note that ECC-CMS-SharedInfo differs from the OtherInfo specified in 972 [CMS-DH]. Here, a counter value is not included in the keyInfo field 973 because the key derivation function specified in [SP800-56A] ensures 974 that sufficient keying data is provided. 976 8. Recommended Algorithms and Elliptic Curves 978 It is RECOMMEND that implementations of this specification support 979 SignedData and EnvelopedData. Support for AuthenticatedData and 980 AuthEnvelopedData is OPTIONAL. 982 In order to encourage interoperability, implementations SHOULD use 983 the elliptic curve domain parameters specified by [PKI-ALG]. 985 Implementations that support SignedData with ECDSA: 987 - MUST support ECDSA with SHA-256; and, 989 - MAY support ECDSA with SHA-1, ECDSA with SHA-224, ECDSA with SHA- 990 384, and ECDSA with SHA-512. Other digital signature algorithms 991 MAY also be supported. 993 When using ECDSA, it is RECOMMENDED that the P-224 curve be used with 994 SHA-224, the P-256 curve be used with SHA-256, the P-384 curve be 995 used with SHA-384, and the P-521 curve be used with SHA-512. 997 If EnvelopedData is supported, then ephemeral-static ECDH standard 998 primitive MUST be supported. Support for ephemeral-static ECDH co- 999 factor is OPTIONAL and support for 1-Pass ECMQV is also OPTIONAL. 1001 Implementations that support EnvelopedData with the ephemeral-static 1002 ECDH standard primitive: 1004 - MUST support the dhSinglePass-stdDH-sha256kdf-scheme key 1005 agreement algorithm, the id-aes128-wrap key wrap algorithm, and 1006 the id-aes128-cbc content encryption algorithm; and, 1008 - MAY support the dhSinglePass-stdDH-sha1kdf-scheme, dhSinglePass- 1009 stdDH-sha224kdf-scheme, dhSinglePass-stdDH-sha384kdf-scheme and 1010 dhSinglePass-stdDH-sha512kdf-scheme key agreement algorithms, 1011 the id-alg-CMS3DESwrap, id-aes192-wrap, and id-aes256-wrap key 1012 wrap algorithms and the des-ede3-cbc, id-aes192-cbc and id- 1013 aes256-cbc content encryption algorithms. Other algorithms MAY 1014 also be supported. 1016 Implementations that support EnvelopedData with the ephemeral-static 1017 ECDH cofactor primitive: 1019 - MUST support the dhSinglePass-cofactorDH-sha256kdf-scheme key 1020 agreement algorithm, the id-aes128-wrap key wrap algorithm, and 1021 the id-aes128-cbc content encryption algorithm; and, 1023 - MAY support the dhSinglePass-cofactorDH-sha1kdf-scheme, 1024 dhSinglePass-cofactorDH-sha224kdf-scheme, dhSinglePass- 1025 cofactorDH-sha384kdf-scheme, and dhSinglePass-cofactorDH- 1026 sha512kdf-scheme key agreement, the id-alg-CMS3DESwrap, id- 1027 aes192-wrap, and id-aes256-wrap key wrap algorithms and the des- 1028 ede3-cbc, id-aes192-cbc and id-aes256-cbc content encryption 1029 algorithms. Other algorithms MAY also be supported. 1031 Implementations that support EnvelopedData with 1-Pass ECMQV: 1033 - MUST support the mqvSinglePass-sha256kdf-scheme key agreement 1034 algorithm, the id-aes128-wrap key wrap algorithm, and the id- 1035 aes128-cbc content encryption algorithm; and, 1037 - MAY support mqvSinglePass-sha1kdf-scheme, mqvSinglePass- 1038 sha224kdf-scheme, mqvSinglePass-sha384kdf-scheme, and 1039 mqvSinglePass-sha512kdf-scheme key agreement algorithms, the id- 1040 alg-CMS3DESwrap, id-aes192-wrap, and id-aes256-wrap key wrap 1041 algorithms and the des-ede3-cbc, id-aes192-cbc and id-aes256-cbc 1042 content encryption algorithms. Other algorithms MAY also be 1043 supported. 1045 Implementations that support AuthenticatedData with 1-Pass ECMQV: 1047 - MUST support the mqvSinglePass-sha256kdf-scheme key agreement, 1048 the id-aes128-wrap key wrap, the id-sha256 message digest, and 1049 id-hmacWithSHA256 message authentication code algorithms; and, 1051 - MAY support the mqvSinglePass-sha1kdf-scheme, mqvSinglePass- 1052 sha224kdf-scheme, mqvSinglePass-sha384kdf-scheme, mqvSinglePass- 1053 sha512kdf-scheme key agreement algorithms, the id-alg- 1054 CMS3DESwrap, id-aes192-wrap, and id-aes256-wrap key wrap 1055 algorithms, the id-sha1, id-sha224, id-sha384, and id-sha512, 1056 message digest algorithms, and the hmac-SHA1, id-hmacWithSHA224, 1057 id-hmacWithSHA384, id-hmacWithSHA512 message authentication code 1058 algorithms. Other algorithms MAY also be supported. 1060 Implementations that support AuthEnvelopedData with 1-Pass ECMQV: 1062 - MUST support the mqvSinglePass-sha256kdf-scheme key agreement, 1063 the id-aes128-wrap key wrap, the id-aes128-ccm authenticated- 1064 content encryption, and the id-hmacWithSHA256 message 1065 authentication code algorithms; and, 1067 - MAY support the mqvSinglePass-sha1kdf-scheme, mqvSinglePass- 1068 sha224kdf-scheme, mqvSinglePass-sha384kdf-scheme, and 1069 mqvSinglePass-sha512kdf-scheme key agreement algorithms, the id- 1070 alg-CMS3DESwrap, id-aes192-wrap, and id-aes256-wrap key wrap 1071 algorithms, the id-aes192-ccm and id-aes256-ccm authenticated- 1072 content encryption algorithms, and hmac-SHA1, id-hmacWithSHA224, 1073 id-hmacWithSHA384, id-hmacWithSHA512 message authentication code 1074 algorithms. Other algorithms MAY also be supported. 1076 9. Security Considerations 1078 Cryptographic algorithms will be broken or weakened over time. 1079 Implementers and users need to check that the cryptographic 1080 algorithms listed in this document continue to provide the expected 1081 level of security. The IETF from time to time may issue documents 1082 dealing with the current state of the art. 1084 Cryptographic algorithms rely on random number. See [RANDOM] for 1085 guidance on generation of random numbers. 1087 Receiving agents that validate signatures and sending agents that 1088 encrypt messages need to be cautious of cryptographic processing 1089 usage when validating signatures and encrypting messages using keys 1090 larger than those mandated in this specification. An attacker could 1091 send keys and/or certificates with keys which would result in 1092 excessive cryptographic processing, for example keys larger than 1093 those mandated in this specification, which could swamp the 1094 processing element. Agents which use such keys without first 1095 validating the certificate to a trust anchor are advised to have some 1096 sort of cryptographic resource management system to prevent such 1097 attacks. 1099 Using secret keys of an appropriate size is crucial to the security 1100 of a Diffie-Hellman exchange. For elliptic curve groups, the size of 1101 the secret key must be equal to the size of n (the order of the group 1102 generated by the point g). Using larger secret keys provides 1103 absolutely no additional security, and using smaller secret keys is 1104 likely to result in dramatically less security. (See [SP800-56A] for 1105 more information on selecting secret keys.) 1107 This specification is based on [CMS], [CMS-AES], [CMS-AESCG], [CMS- 1108 ALG], [CMS-AUTHENV], [CMS-DH], [CMS_SHA2], [FIPS180-3], [FIPS186-3], 1110 [HMAC-SHA1], and [HMAC-SHA2], and the appropriate security 1111 considerations of those documents apply. 1113 In addition, implementors of AuthenticatedData and AuthEnvelopedData 1114 should be aware of the concerns expressed in [BON] when using 1115 AuthenticatedData and AuthEnvelopedData to send messages to more than 1116 one recipient. Also, users of MQV should be aware of the 1117 vulnerability in [K]. 1119 When implementing EnvelopedData, AuthenticatedData, and 1120 AuthEnvelopedData, there are five algorithm related choices that need 1121 to be made: 1123 1) What is the public key size? 1124 2) What is the KDF? 1125 3) What is the key wrap algorithm? 1126 4) What is the content encryption algorithm? 1127 5) What is the curve? 1129 Consideration must be given to strength of the security provided by 1130 each of these choices. Security is measured in bits, where a strong 1131 symmetric cipher with a key of X bits is said to provide X bits of 1132 security. It is recommended that the bits of security provided by 1133 each are roughly equivalent. The following table provides comparable 1134 minimum bits of security [SP800-57] for the ECDH/ECMQV key sizes, 1135 KDFs, key wrapping algorithms, and content encryption algorithms. It 1136 also lists curves [PKI-ALG] for the key sizes. 1138 Minimum | ECDH or | Key | Key | Content | Curves 1139 Bits of | ECQMV | Derivation | Wrap | Encryption | 1140 Security | Key Size | Function | Alg. | Alg. | 1141 ---------+----------+------------+----------+-------------+---------- 1142 80 | 160-223 | SHA-1 | 3DES | 3DES CBC | sect163k1 1143 | | SHA-224 | AES-128 | AES-128 CBC | secp163r2 1144 | | SHA-256 | AES-192 | AES-192 CBC | secp192r1 1145 | | SHA-384 | AES-256 | AES-256 CBC | 1146 | | SHA-512 | | | 1147 ---------+----------+------------+----------+-------------+--------- 1148 112 | 224-255 | SHA-1 | 3DES | 3DES CBC | secp224r1 1149 | | SHA-224 | AES-128 | AES-128 CBC | sect233k1 1150 | | SHA-256 | AES-192 | AES-192 CBC | sect233r1 1151 | | SHA-384 | AES-256 | AES-256 CBC | 1152 | | SHA-512 | | | 1153 ---------+----------+------------+----------+-------------+--------- 1154 128 | 256-383 | SHA-1 | AES-128 | AES-128 CBC | secp256r1 1155 | | SHA-224 | AES-192 | AES-192 CBC | sect283k1 1156 | | SHA-256 | AES-256 | AES-256 CBC | sect283r1 1157 | | SHA-384 | | | 1158 | | SHA-512 | | | 1159 ---------+----------+------------+----------+-------------+--------- 1160 192 | 384-511 | SHA-224 | AES-192 | AES-192 CBC | secp384r1 1161 | | SHA-256 | AES-256 | AES-256 CBC | sect409k1 1162 | | SHA-384 | | | sect409r1 1163 | | SHA-512 | | | 1164 ---------+----------+------------+----------+-------------+--------- 1165 256 | 512+ | SHA-256 | AES-256 | AES-256 CBC | secp521r1 1166 | | SHA-384 | | | sect571k1 1167 | | SHA-512 | | | sect571r1 1168 ---------+----------+------------+----------+-------------+--------- 1169 To promote interoperability, the following choices are RECOMMENDED: 1171 Minimum | ECDH or | Key | Key | Content | Curve 1172 Bits of | ECQMV | Derivation | Wrap | Encryption | 1173 Security | Key Size | Function | Alg. | Alg. | 1174 ---------+----------+------------+----------+-------------+---------- 1175 80 | 192 | SHA-256 | 3DES | 3DES CBC | secp192r1 1176 ---------+----------+------------+----------+-------------+---------- 1177 112 | 224 | SHA-256 | 3DES | 3DES CBC | secp224r1 1178 ---------+----------+------------+----------+-------------+---------- 1179 128 | 256 | SHA-256 | AES-128 | AES-128 CBC | secp256r1 1180 ---------+----------+------------+----------+-------------+---------- 1181 192 | 384 | SHA-384 | AES-256 | AES-256 CBC | secp384r1 1182 ---------+----------+------------+----------+-------------+---------- 1183 256 | 512 | SHA-512 | AES-256 | AES-256 CBC | secp521r1 1184 ---------+----------+------------+----------+-------------+---------- 1186 When implementing SignedData, there are three algorithm related 1187 choices that need to be made: 1189 1) What is the public key size? 1190 2) What is the hash algorithm? 1191 3) What is the curve? 1193 Consideration must be given to the bits of security provided by each 1194 of these choices. Security is measured in bits, where a strong 1195 symmetric cipher with a key of X bits is said to provide X bits of 1196 security. It is recommended that the bits of security provided by 1197 each choice are roughly equivalent. The following table provides 1198 comparable minimum bits of security [SP800-57] for the ECDSA key 1199 sizes and message digest algorithms. It also lists curves [PKI-ALG] 1200 for the key sizes. 1202 Minimum | ECDSA | Message | Curve 1203 Bits of | Key Size | Digest | 1204 Security | | Algorithm | 1205 ---------+----------+-----------+----------- 1206 80 | 160-223 | SHA-1 | sect163k1 1207 | | SHA-224 | secp163r2 1208 | | SHA-256 | secp192r1 1209 | | SHA-384 | 1210 | | SHA-512 | 1211 ---------+----------+-----------+----------- 1212 112 | 224-255 | SHA-224 | secp224r1 1213 | | SHA-256 | sect233k1 1214 | | SHA-384 | sect233r1 1215 | | SHA-512 | 1216 ---------+----------+-----------+----------- 1217 128 | 256-383 | SHA-256 | secp256r1 1218 | | SHA-384 | sect283k1 1219 | | SHA-512 | sect283r1 1220 ---------+----------+-----------+----------- 1221 192 | 384-511 | SHA-384 | secp384r1 1222 | | SHA-512 | sect409k1 1223 | | | sect409r1 1224 ---------+----------+-----------+----------- 1225 256 | 512+ | SHA-512 | secp521r1 1226 | | | sect571k1 1227 | | | sect571r1 1228 ---------+----------+-----------+----------- 1230 To promote interoperability, the following choices are RECOMMENDED: 1232 Minimum | ECDSA | Message | Curve 1233 Bits of | Key Size | Digest | 1234 Security | | Algorithm | 1235 ---------+----------+-----------+----------- 1236 80 | 192 | SHA-256 | sect192r1 1237 ---------+----------+-----------+----------- 1238 112 | 224 | SHA-256 | secp224r1 1239 ---------+----------+-----------+----------- 1240 128 | 256 | SHA-256 | secp256r1 1241 ---------+----------+-----------+----------- 1242 192 | 384 | SHA-384 | secp384r1 1243 ---------+----------+-----------+----------- 1244 256 | 512+ | SHA-512 | secp521r1 1245 ---------+----------+-----------+----------- 1247 10. IANA Considerations 1249 This document makes extensive use of object identifiers to register 1250 originator public key types and algorithms. The algorithms object 1251 identifiers are registered in the ANSI X9.62, ANSI X9.63, NIST, RSA, 1252 and SECG arcs. Additionally, object identifiers are used to identify 1253 the ASN.1 modules found in Appendix A. These are defined in an arc 1254 delegated by IANA to the SMIME Working Group. No further action by 1255 IANA is necessary for this document or any anticipated updates. 1257 11. References 1259 11.1. Normative 1261 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 1262 3852, July 2004. 1264 [CMS-AES] Schaad, J., "Use of the Advanced Encryption Standard 1265 (AES) Encryption Algorithm in Cryptographic Message 1266 Syntax (CMS)", RFC 3565, July 2003. 1268 [CMS-AESCG] Housley, R., "Using AES-CCM and AES-GCM Authenticated 1269 Encryption in the Cryptographic Message Syntax 1270 (CMS)", RFC 5084, November 2007. 1272 [CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS) 1273 Algorithms", RFC 3370, August 2002. 1275 [CMS-AUTHENV] Housley, R. "Cryptographic Message Syntax (CMS) 1276 Authenticated-Enveloped-Data Content Type", RFC 5083, 1277 November 2007. 1279 [CMS-DH] Rescorla, E., "Diffie-Hellman Key Agreement Method", 1280 RFC 2631, June 1999. 1282 [CMS-SHA2] Turner, S., "Using SHA2 Algorithms with Cryptographic 1283 Message Syntax", work-in-progress. 1285 [FIPS180-3] National Institute of Standards and Technology 1286 (NIST), FIPS Publication 180-3: Secure Hash Standard, 1287 (draft) June 2003. 1289 [FIPS186-3] National Institute of Standards and Technology 1290 (NIST), FIPS Publication 186-3: Digital Signature 1291 Standard, (draft) March 2006. 1293 [HMAC-SHA1] Krawczyk, M., Bellare, M., and R. Canetti, "HMAC: 1294 Keyed-Hashing for Message Authentication", RFC 2104, 1295 February 1997. 1297 [HMAC-SHA2] Nystrom, M., "Identifiers and Test Vectors for HMAC- 1298 SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA- 1299 512", RFC 4231, December 2005. 1301 [MUST] Bradner, S., "Key Words for Use in RFCs to Indicate 1302 Requirement Levels", BCP 14, RFC 2119, March 1997. 1304 [MSG] Ramsdell, B., and S. Turner, "S/MIME Version 3.2 1305 Message Specification", draft-ietf-smime-3851bis, 1306 work-in-progress. 1308 [PKI] Cooper, D., Santesson, S., Farrell, S., Boeyen, S. 1309 Housley, R., and W. Polk, "Internet X.509 Public Key 1310 Infrastructure Certificate and Certificate Revocation 1311 List (CRL) Profile", RFC 5280, May 2008. 1313 [PKI-ALG] Turner, S., Brown, D., Yiu, K., Housley, R., and W. 1314 Polk, "Elliptic Curve Cryptography Subject Public Key 1315 Information", draft-ietf-pkix-ecc-subpubkeyinfo, 1316 work-in-progress. 1318 [RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller, 1319 "Randomness Recommendations for Security", RFC 4086, 1320 June 2005. 1322 [RSAOAEP] Schaad, J., Kaliski, B., and R. Housley, "Additional 1323 Algorithms and Identifiers for RSA Cryptography for 1324 use in the Internet X.509 Public Key Infrastructure 1325 Certificate and Certificate Revocation List (CRL) 1326 Profile", RFC 4055, June 2005. 1328 [SP800-56A] National Institute of Standards and Technology 1329 (NIST), Special Publication 800-56A: Recommendation 1330 Pair-Wise Key Establishment Schemes Using Discrete 1331 Logarithm Cryptography (Revised), March 2007. 1333 [X.208] ITU-T Recommendation X.208 (1988) | ISO/IEC 8824- 1334 1:1988. Specification of Abstract Syntax Notation One 1335 (ASN.1). 1337 11.2. Informative 1339 [BON] D. Boneh, "The Security of Multicast MAC", 1340 Presentation at Selected Areas of Cryptography 2000, 1341 Center for Applied Cryptographic Research, University 1342 of Waterloo, 2000. Paper version available from 1343 http://crypto.stanford.edu/~dabo/papers/mmac.ps 1345 [CERTCAP] Santesson, S., "X.509 Certificate Extension for 1346 Secure/Multipurpose Internet Mail Extensions (S/MIME) 1347 Capabilities", RFC 4262, December 2005. 1349 [CMS-ECC] Blake-Wilson, S., Brown, D., and P. Lambert, "Use of 1350 Elliptic Curve Cryptography (ECC) Algorithms in 1351 Cryptographic Message Syntax (CMS)", RFC 3278, April 1352 2002. 1354 [CMS-KEA] Pawling, J., "CMS KEA and SKIPJACK Conventions", RFC 1355 2876, July 2000. 1357 [CMS-ASN] Hoffman, P., and J. Schaad, "New ASN.1 Modules for 1358 CMS", draft-ietf-smime-new-asn1, work-in-progress. 1360 [K] B. Kaliski, "MQV Vulnerability", Posting to ANSI X9F1 1361 and IEEE P1363 newsgroups, 1998. 1363 [PKI-ASN] Hoffman, P., and J. Schaad, "New ASN.1 Modules for 1364 PKIX", draft-ietf-pkix-new-asn1, work-in-progress. 1366 [SP800-57] National Institute of Standards and Technology 1367 (NIST), Special Publication 800-57: Recommendation 1368 for Key Management - Part 1 (Revised), March 2007. 1370 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824- 1371 1 :2002. Information Technology - Abstract Syntax 1372 Notation One. 1374 [X.681] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824- 1375 2 :2002. Information Technology - Abstract Syntax 1376 Notation One: Information Object Specification. 1378 [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824- 1379 3 :2002. Information Technology - Abstract Syntax 1380 Notation One: Constraint Specification. 1382 [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824- 1383 4:2002. Information Technology - Abstract Syntax 1384 Notation One: Parameterization of ASN.1 1385 Specifications, 2002. 1387 Appendix A ASN.1 Modules 1389 Appendix A.1 provides the normative ASN.1 definitions for the 1390 structures described in this specification using ASN.1 as defined in 1391 [X.208]. 1393 Appendix A.2 provides an informative ASN.1 definitions for the 1394 structures described in this specification using ASN.1 as defined in 1395 [X.680], [X.681], [X.682], and [X.683]. This appendix contains the 1396 same information as Appendix A.1 in a more recent (and precise) ASN.1 1397 notation, however Appendix A.1 takes precedence in case of conflict. 1399 Appendix A.1 1988 ASN.1 Module 1401 SMIMEECCAlgs-1988 1402 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1403 smime(16) modules(0) TBA } 1405 DEFINITIONS IMPLICIT TAGS ::= 1407 BEGIN 1409 -- EXPORTS ALL 1411 IMPORTS 1413 -- From [PKI] 1415 AlgorithmIdentifier 1416 FROM PKIX1Explicit88 1417 { iso(1) identified-organization(3) dod(6) 1418 internet(1) security(5) mechanisms(5) pkix(7) mod(0) 1419 pkix1-explicit(18) } 1421 -- From [RSAOAEP] 1423 id-sha224, id-sha256, id-sha384, id-sha512 1424 FROM PKIX1-PSS-OAEP-Algorithms 1425 { iso(1) identified-organization(3) dod(6) internet(1) 1426 security(5) mechanisms(5) pkix(7) id-mod(0) 1427 id-mod-pkix1-rsa-pkalgs(33) } 1429 -- From [PKI-ALG] 1431 id-sha1, ecdsa-with-SHA1, ecdsa-with-SHA224, 1432 ecdsa-with-SHA256, ecdsa-with-SHA384, ecdsa-with-SHA512, 1433 id-ecPublicKey, ECDSA-Sig-Value, ECPoint 1434 FROM PKIXAlgs-2008 1435 { iso(1) identified-organization(3) dod(6) internet(1) 1436 security(5) mechanisms(5) pkix(7) id-mod(0) TBA } 1438 -- From [CMS] 1440 OriginatorPublicKey, UserKeyingMaterial 1441 FROM CryptographicMessageSyntax2004 1442 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1443 smime(16) modules(0) cms-2004(24) } 1445 -- From [CMS-ALG] 1447 hMAC-SHA1, des-ede3-cbc, id-alg-CMS3DESwrap, CBCParameter 1448 FROM CryptographicMessageSyntaxAlgorithms 1449 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1450 smime(16) modules(0) cmsalg-2001(16) } 1452 -- From [CMS-AES] 1454 id-aes128-CBC, id-aes192-CBC, id-aes256-CBC, AES-IV, 1455 id-aes128-wrap, id-aes192-wrap, id-aes256-wrap 1456 FROM CMSAesRsaesOaep 1457 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1458 smime(16) modules(0) id-mod-cms-aes(19) } 1460 -- From [CMS-AESCG] 1462 id-aes128-CCM, id-aes192-CCM, id-aes256-CCM, CCMParameters 1463 id-aes128-GCM, id-aes192-GCM, id-aes256-GCM, GCMParameters 1464 FROM CMS-AES-CCM-and-AES-GCM 1465 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1466 smime(16) modules(0) id-mod-cms-aes(32) } 1468 ; 1469 -- 1470 -- ECDSA with SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 1471 -- Algorithms. 1472 -- 1474 -- ecdsa-with-SHA1 Parameters are NULL 1475 -- ecdsa-with-SHA224 Parameters are absent 1476 -- ecdsa-with-SHA256 Parameters are absent 1477 -- ecdsa-with-SHA384 Parameters are absent 1478 -- ecdsa-with-SHA512 Parameters are absent 1480 -- ECDSA Signature Value 1481 -- Contents of SignatureValue OCTET STRING 1483 -- ECDSA-Sig-Value ::= SEQUENCE { 1484 -- r INTEGER, 1485 -- s INTEGER 1486 -- } 1488 -- 1489 -- Key Agreement Algorithms 1490 -- 1492 x9-63-scheme OBJECT IDENTIFIER ::= { 1493 iso(1) identified-organization(3) tc68(133) country(16) x9(840) 1494 x9-63(63) schemes(0) } 1496 secg-scheme OBJECT IDENTIFIER ::= { 1497 iso(1) identified-organization(3) certicom(132) schemes(1) } 1499 -- 1500 -- Diffie-Hellman Single Pass, Standard, with KDFs 1501 -- 1503 -- Parameters are always present and indicate the key wrap algorithm 1504 -- with KeyWrapAlgorithm 1506 dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 1507 x9-63-scheme 2 } 1509 dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 1510 secg-scheme 11 0 } 1512 dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 1513 secg-scheme 11 1 } 1515 dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 1516 secg-scheme 11 2 } 1518 dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 1519 secg-scheme 11 3 } 1521 -- 1522 -- Diffie-Hellman Single Pass, Cofactor, with KDFs 1523 -- 1525 dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 1526 x9-63-scheme 3 } 1528 dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 1529 secg-scheme 14 0 } 1531 dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 1532 secg-scheme 14 1 } 1534 dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 1535 secg-scheme 14 2 } 1537 dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 1538 secg-scheme 14 3 } 1540 -- 1541 -- MQV Single Pass, Cofactor, with KDFs 1542 -- 1544 mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= { 1545 x9-63-scheme 16 } 1547 mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= { 1548 secg-scheme 15 0 } 1550 mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= { 1551 secg-scheme 15 1 } 1553 mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= { 1554 secg-scheme 15 2 } 1556 mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= { 1557 secg-scheme 15 3 } 1559 -- 1560 -- Key Wrap Algorithms 1561 -- 1563 KeyWrapAlgorithm ::= AlgorithmIdentifier 1565 -- id-alg-CMS3DESwrap Parameters are NULL 1566 -- id-aes128-wrap Parameters are absent 1567 -- id-aes192-wrap Parameters are absent 1568 -- id-aes256-wrap Parameters are absent 1570 -- 1571 -- Content Encryption Algorithms 1572 -- 1574 -- des-ede3-cbc Parameters are CBCParameter 1575 -- id-aes128-CBC Parameters are AES-IV 1576 -- id-aes192-CBC Parameters are AES-IV 1577 -- id-aes256-CBC Parameters are AES-IV 1578 -- id-aes128-CCM Parameters are CCMParameters 1579 -- id-aes192-CCM Parameters are CCMParameters 1580 -- id-aes256-CCM Parameters are CCMParameters 1581 -- id-aes128-GCM Parameters are GCMParameters 1582 -- id-aes192-GCM Parameters are GCMParameters 1583 -- id-aes256-GCM Parameters are GCMParameters 1585 -- 1586 -- Message Digest Algorithms 1587 -- 1589 -- HMAC with SHA-1 1591 -- Parameters SHOULD be absent, MAY be NULL 1593 -- hMAC-SHA1 1595 -- HMAC with SHA-224, HMAC with SHA-256, HMAC with SHA-384, 1596 -- and HMAC with SHA-512 1598 -- Parameters are absent 1600 id-hmacWithSHA224 OBJECT IDENTIFIER ::= { 1601 iso(1) member-body(2) us(840) rsadsi(113549) 1602 digestAlgorithm(2) 8 } 1604 id-hmacWithSHA256 OBJECT IDENTIFIER ::= { 1605 iso(1) member-body(2) us(840) rsadsi(113549) 1606 digestAlgorithm(2) 9 } 1608 id-hmacWithSHA384 OBJECT IDENTIFIER ::= { 1609 iso(1) member-body(2) us(840) rsadsi(113549) 1610 digestAlgorithm(2) 10 } 1612 id-hmacWithSHA512 OBJECT IDENTIFIER ::= { 1613 iso(1) member-body(2) us(840) rsadsi(113549) 1614 digestAlgorithm(2) 11 } 1616 -- 1617 -- Originator Public Key Algorithms 1618 -- 1620 -- id-ecPublicKey Parameters are absent, NULL, or ECParameters 1622 -- Format for both ephemeral and static public keys 1624 -- ECPoint ::= OCTET STRING 1626 -- Format of KeyAgreeRecipientInfo ukm field when used with 1627 -- ECMQV 1629 MQVuserKeyingMaterial ::= SEQUENCE { 1630 ephemeralPublicKey OriginatorPublicKey, 1631 addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL 1632 } 1634 -- 'SharedInfo' for input to KDF when using ECDH and ECMQV with 1635 -- EnvelopedData, AuthenticatedData, or AuthEnvelopedData 1637 ECC-CMS-SharedInfo ::= SEQUENCE { 1638 keyInfo AlgorithmIdentifier, 1639 entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL, 1640 suppPubInfo [2] EXPLICIT OCTET STRING 1641 } 1642 -- 1643 -- S/MIME Capabilities 1644 -- 1646 -- 1647 -- S/MIME Capabilities: ECDSA with SHA-1, SHA-224, SHA-256, SHA-384, 1648 -- and SHA-512 Algorithms 1649 -- 1651 -- ecdsa-with-SHA1 Type NULL 1652 -- ecdsa-with-SHA224 Type NULL 1653 -- ecdsa-with-SHA256 Type NULL 1654 -- ecdsa-with-SHA384 Type NULL 1655 -- ecdsa-with-SHA512 Type NULL 1657 -- 1658 -- S/MIME Capabilities: ECDH, Single Pass, Standard 1659 -- 1661 -- dhSinglePass-stdDH-sha1kdf Type is the KeyWrapAlgorithm 1662 -- dhSinglePass-stdDH-sha224kdf Type is the KeyWrapAlgorithm 1663 -- dhSinglePass-stdDH-sha256kdf Type is the KeyWrapAlgorithm 1664 -- dhSinglePass-stdDH-sha384kdf Type is the KeyWrapAlgorithm 1665 -- dhSinglePass-stdDH-sha512kdf Type is the KeyWrapAlgorithm 1667 -- 1668 -- S/MIME Capabilities: ECDH, Single Pass, Cofactor 1669 -- 1671 -- dhSinglePass-cofactorDH-sha1kdf Type is the KeyWrapAlgorithm 1672 -- dhSinglePass-cofactorDH-sha224kdf Type is the KeyWrapAlgorithm 1673 -- dhSinglePass-cofactorDH-sha256kdf Type is the KeyWrapAlgorithm 1674 -- dhSinglePass-cofactorDH-sha384kdf Type is the KeyWrapAlgorithm 1675 -- dhSinglePass-cofactorDH-sha512kdf Type is the KeyWrapAlgorithm 1677 -- 1678 -- S/MIME Capabilities: ECMQV, Single Pass, Standard 1679 -- 1681 -- mqvSinglePass-sha1kdf Type is the KeyWrapAlgorithm 1682 -- mqvSinglePass-sha224kdf Type is the KeyWrapAlgorithm 1683 -- mqvSinglePass-sha256kdf Type is the KeyWrapAlgorithm 1684 -- mqvSinglePass-sha384kdf Type is the KeyWrapAlgorithm 1685 -- mqvSinglePass-sha512kdf Type is the KeyWrapAlgorithm 1687 END 1689 Appendix A.2 2004 ASN.1 Module 1691 SMIMEECCAlgs-2008 1692 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1693 smime(16) modules(0) TBA } 1695 DEFINITIONS IMPLICIT TAGS ::= 1697 BEGIN 1699 -- EXPORTS ALL 1701 IMPORTS 1703 -- FROM [PKI-ASN] 1705 KEY-WRAP, SIGNATURE-ALGORITHM, DIGEST-ALGORITHM, ALGORITHM, 1706 PUBLIC-KEY, MAC-ALGORITHM, CONTENT-ENCRYPTION, KEY-AGREE 1707 FROM AlgorithmInformation 1708 { iso(1) identified-organization(3) dod(6) internet(1) 1709 security(5) mechanisms(5) pkix(7) id-mod(0) 1710 id-mod-algorithInformation(TBA) } 1712 -- From [PKI-ALG] 1714 id-ecPublicKey, ECDSA-Sig-Value, ECPoint 1715 FROM PKIXAlgIDs-2008 1716 { iso(1) identified-organization(3) dod(6) internet(1) 1717 security(5) mechanisms(5) pkix(7) id-mod(0) TBA } 1719 -- From [PKI-ALG] 1721 mda-sha1, sa-ecdsaWithSHA1, sa-ecdsaWithSHA224, sa-ecdsaWithSHA256, 1722 sa-ecdsaWithSHA384, sa-ecdsaWithSHA512, ECParameters 1723 FROM PKIXAlgs-2008 1724 { iso(1) identified-organization(3) dod(6) internet(1) 1725 security(5) mechanisms(5) pkix(7) id-mod(0) TBA } 1727 -- From [PKI-ASN] 1729 mda-sha224, mda-sha256, mda-sha384, mda-sha512 1730 FROM PKIX1-PSS-OAEP-Algorithms 1731 { iso(1) identified-organization(3) dod(6) internet(1) 1732 security(5) mechanisms(5) pkix(7) id-mod(0) TBA } 1734 -- From [CMS] 1736 OriginatorPublicKey, UserKeyingMaterial 1737 FROM CryptographicMessageSyntax2004 1738 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1739 smime(16) modules(0) cms-2004(24) } 1741 -- From [CMS-ASN] 1743 maca-hMAC-SHA1, cea-des-ede3-cbc, kwa-3DESWrap, CBCParameter 1744 FROM CryptographicMessageSyntaxAlgorithms 1745 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1746 smime(16) modules(0) cmsalg-2001(16) } 1748 -- From [CMS-ASN] 1750 cea-aes128-CBC, cea-aes192-CBC, cea-aes256-CBC, kwa-aes128-wrap, 1751 kwa-aes192-wrap, kwa-aes256-wrap 1752 FROM CMSAesRsaesOaep 1753 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1754 smime(16) modules(0) id-mod-cms-aes(19) } 1756 -- From [CMS-ASN] 1758 cea-aes128-ccm, cea-aes192-ccm, cea-aes256-ccm, cea-aes128-gcm, 1759 cea-aes192-gcm, cea-aes256-gcm 1760 FROM CMS-AES-CCM-and-AES-GCM 1761 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1762 smime(16) modules(0) cms-aes-ccm-and-gcm(32) } 1764 ; 1766 -- Constrains the SignedData digestAlgorithms field 1767 -- Constrains the SignedData SignerInfo digestAlgorithm field 1768 -- Constrains the AuthenticatedData digestAlgorithm field 1770 -- MessageDigestAlgorithms DIGEST-ALGORITHM ::= { 1771 -- mda-sha1 | 1772 -- mda-sha224 | 1773 -- mda-sha256 | 1774 -- mda-sha384 | 1775 -- mda-sha512, 1776 -- ... -- Extensible 1777 -- } 1778 -- Constrains the SignedData SignerInfo signatureAlgorithm field 1780 -- SignatureAlgorithms SIGNATURE-ALGORITHM ::= { 1781 -- sa-ecdsaWithSHA1 | 1782 -- sa-ecdsaWithSHA224 | 1783 -- sa-ecdsaWithSHA256 | 1784 -- sa-ecdsaWithSHA384 | 1785 -- sa-ecdsaWithSHA512, 1786 -- ... -- Extensible 1787 -- } 1789 -- ECDSA Signature Value 1790 -- Contents of SignatureValue OCTET STRING 1792 -- ECDSA-Sig-Value ::= SEQUENCE { 1793 -- r INTEGER, 1794 -- s INTEGER 1795 -- } 1797 -- 1798 -- Key Agreement Algorithms 1799 -- 1801 -- Constrains the EnvelopedData RecipientInfo KeyAgreeRecipientInfo 1802 -- keyEncryption Algorithm field 1803 -- Constrains the AuthenticatedData RecipientInfo 1804 -- KeyAgreeRecipientInfo keyEncryption Algorithm field 1805 -- Constrains the AuthEnvelopedData RecipientInfo 1806 -- KeyAgreeRecipientInfo keyEncryption Algorithm field 1808 -- DH variants are not used with AuthenticatedData or 1809 -- AuthEnvelopedData 1810 KeyAgreementAlgorithms KEY-AGREE ::= { 1811 kaa-dhSinglePass-stdDH-sha1kdf | 1812 kaa-dhSinglePass-stdDH-sha224kdf | 1813 kaa-dhSinglePass-stdDH-sha256kdf | 1814 kaa-dhSinglePass-stdDH-sha384kdf | 1815 kaa-dhSinglePass-stdDH-sha512kdf | 1816 kaa-dhSinglePass-cofactorDH-sha1kdf | 1817 kaa-dhSinglePass-cofactorDH-sha224kdf | 1818 kaa-dhSinglePass-cofactorDH-sha256kdf | 1819 kaa-dhSinglePass-cofactorDH-sha384kdf | 1820 kaa-dhSinglePass-cofactorDH-sha512kdf | 1821 kaa-mqvSinglePass-sha1kdf | 1822 kaa-mqvSinglePass-sha224kdf | 1823 kaa-mqvSinglePass-sha256kdf | 1824 kaa-mqvSinglePass-sha384kdf | 1825 kaa-mqvSinglePass-sha512kdf, 1826 ... -- Extensible 1827 } 1829 x9-63-scheme OBJECT IDENTIFIER ::= { 1830 iso(1) identified-organization(3) tc68(133) country(16) x9(840) 1831 x9-63(63) schemes(0) } 1833 secg-scheme OBJECT IDENTIFIER ::= { 1834 iso(1) identified-organization(3) certicom(132) schemes(1) } 1836 -- 1837 -- Diffie-Hellman Single Pass, Standard, with KDFs 1838 -- 1840 -- Parameters are always present and indicate the Key Wrap Algorithm 1842 kaa-dhSinglePass-stdDH-sha1kdf KEY-AGREE ::= { 1843 IDENTIFIER dhSinglePass-stdDH-sha1kdf-scheme 1844 PARAMS TYPE KeyWrapAlgorithm ARE required 1845 UKM IS preferredPresent 1846 } 1848 dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 1849 x9-63-scheme 2 } 1851 kaa-dhSinglePass-stdDH-sha224kdf KEY-AGREE ::= { 1852 IDENTIFIER dhSinglePass-stdDH-sha224kdf-scheme 1853 PARAMS TYPE KeyWrapAlgorithm ARE required 1854 UKM IS preferredPresent 1855 } 1856 dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 1857 secg-scheme 11 0 } 1859 kaa-dhSinglePass-stdDH-sha256kdf KEY-AGREE ::= { 1860 IDENTIFIER dhSinglePass-stdDH-sha256kdf-scheme 1861 PARAMS TYPE KeyWrapAlgorithm ARE required 1862 UKM IS preferredPresent 1863 } 1865 dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 1866 secg-scheme 11 1 } 1868 kaa-dhSinglePass-stdDH-sha384kdf KEY-AGREE ::= { 1869 IDENTIFIER dhSinglePass-stdDH-sha384kdf-scheme 1870 PARAMS TYPE KeyWrapAlgorithm ARE required 1871 UKM IS preferredPresent 1872 } 1874 dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 1875 secg-scheme 11 2 } 1877 kaa-dhSinglePass-stdDH-sha512kdf KEY-AGREE ::= { 1878 IDENTIFIER dhSinglePass-stdDH-sha512kdf-scheme 1879 PARAMS TYPE KeyWrapAlgorithm ARE required 1880 UKM IS preferredPresent 1881 } 1883 dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 1884 secg-scheme 11 3 } 1886 -- 1887 -- Diffie-Hellman Single Pass, Cofactor, with KDFs 1888 -- 1890 kaa-dhSinglePass-cofactorDH-sha1kdf KEY-AGREE ::= { 1891 IDENTIFIER dhSinglePass-cofactorDH-sha1kdf-scheme 1892 PARAMS TYPE KeyWrapAlgorithm ARE required 1893 UKM IS preferredPresent 1894 } 1896 dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 1897 x9-63-scheme 3 } 1899 kaa-dhSinglePass-cofactorDH-sha224kdf KEY-AGREE ::= { 1900 IDENTIFIER dhSinglePass-cofactorDH-sha224kdf-scheme 1901 PARAMS TYPE KeyWrapAlgorithm ARE required 1902 UKM IS preferredPresent 1903 } 1905 dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 1906 secg-scheme 14 0 } 1908 kaa-dhSinglePass-cofactorDH-sha256kdf KEY-AGREE ::= { 1909 IDENTIFIER dhSinglePass-cofactorDH-sha256kdf-scheme 1910 PARAMS TYPE KeyWrapAlgorithm ARE required 1911 UKM IS preferredPresent 1912 } 1914 dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 1915 secg-scheme 14 1 } 1917 kaa-dhSinglePass-cofactorDH-sha384kdf KEY-AGREE ::= { 1918 IDENTIFIER dhSinglePass-cofactorDH-sha384kdf-scheme 1919 PARAMS TYPE KeyWrapAlgorithm ARE required 1920 UKM IS preferredPresent 1921 } 1923 dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 1924 secg-scheme 14 2 } 1926 kaa-dhSinglePass-cofactorDH-sha512kdf KEY-AGREE ::= { 1927 IDENTIFIER dhSinglePass-cofactorDH-sha512kdf-scheme 1928 PARAMS TYPE KeyWrapAlgorithm ARE required 1929 UKM IS preferredPresent 1930 } 1932 dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 1933 secg-scheme 14 3 } 1935 -- 1936 -- MQV Single Pass, Cofactor, with KDFs 1937 -- 1939 kaa-mqvSinglePass-sha1kdf KEY-AGREE ::= { 1940 IDENTIFIER mqvSinglePass-sha1kdf-scheme 1941 PARAMS TYPE KeyWrapAlgorithm ARE required 1942 UKM IS preferredPresent 1943 } 1944 mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= { 1945 x9-63-scheme 16 } 1947 kaa-mqvSinglePass-sha224kdf KEY-AGREE ::= { 1948 IDENTIFIER mqvSinglePass-sha224kdf-scheme 1949 PARAMS TYPE KeyWrapAlgorithm ARE required 1950 UKM IS preferredPresent 1951 } 1953 mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= { 1954 secg-scheme 15 0 } 1956 kaa-mqvSinglePass-sha256kdf KEY-AGREE ::= { 1957 IDENTIFIER mqvSinglePass-sha256kdf-scheme 1958 PARAMS TYPE KeyWrapAlgorithm ARE required 1959 UKM IS preferredPresent 1960 } 1962 mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= { 1963 secg-scheme 15 1 } 1965 kaa-mqvSinglePass-sha384kdf KEY-AGREE ::= { 1966 IDENTIFIER mqvSinglePass-sha384kdf-scheme 1967 PARAMS TYPE KeyWrapAlgorithm ARE required 1968 UKM IS preferredPresent 1969 } 1971 mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= { 1972 secg-scheme 15 2 } 1974 kaa-mqvSinglePass-sha512kdf KEY-AGREE ::= { 1975 IDENTIFIER mqvSinglePass-sha512kdf-scheme 1976 PARAMS TYPE KeyWrapAlgorithm ARE required 1977 UKM IS preferredPresent 1978 } 1980 mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= { 1981 secg-scheme 15 3 } 1983 -- 1984 -- Key Wrap Algorithms 1985 -- 1987 KeyWrapAlgorithm KEY-WRAP ::= { 1988 kwa-3des | 1989 kwa-aes128 | 1990 kwa-aes192 | 1991 kwa-aes256, 1992 ... -- Extensible 1993 } 1995 -- 1996 -- Content Encryption Algorithms 1997 -- 1999 -- Constrains the EnvelopedData EncryptedContentInfo encryptedContent 2000 -- field and the AuthEnvelopedData EncryptedContentInfo 2001 -- contentEncryptionAlgorithm field 2003 -- ContentEncryptionAlgorithms CONTENT-ENCRYPTION ::= { 2004 -- cea-des-ede3-cbc | 2005 -- cea-aes128-cbc | 2006 -- cea-aes192-cbc | 2007 -- cea-aes256-cbc | 2008 -- cea-aes128-ccm | 2009 -- cea-aes192-ccm | 2010 -- cea-aes256-ccm | 2011 -- cea-aes128-gcm | 2012 -- cea-aes192-gcm | 2013 -- cea-aes256-gcm, 2014 -- ... -- Extensible 2015 -- } 2017 -- des-ede3-cbc and aes*-cbc are used with EnvelopedData and 2018 -- EncryptedData 2019 -- aes*-ccm are used with AuthEnvelopedData 2020 -- aes*-gcm are used with AuthEnvelopedData 2021 -- (where * is 128, 192, and 256) 2022 -- 2023 -- Message Digest Algorithms 2024 -- 2026 -- Constrains the AuthenticatedData 2027 -- MessageAuthenticationCodeAlgorithm field 2028 -- Constrains the AuthEnvelopedData 2029 -- MessageAuthenticationCodeAlgorithm field 2031 MessageAuthenticationCodeAlgorithms MAC-ALGORITHM ::= { 2032 maca-sha1 | 2033 maca-sha224 | 2034 maca-sha256 | 2035 maca-sha384 | 2036 maca-sha512, 2037 ... -- Extensible 2038 } 2040 maca-sha224 MAC-ALGORITHM ::= { 2041 IDENTIFIER id-hmacWithSHA224 2042 PARAMS TYPE NULL ARE preferredPresent 2043 } 2045 id-hmacWithSHA224 OBJECT IDENTIFIER ::= { 2046 iso(1) member-body(2) us(840) rsadsi(113549) 2047 digestAlgorithm(2) 8 } 2049 maca-sha256 MAC-ALGORITHM ::= { 2050 IDENTIFIER id-hmacWithSHA256 2051 PARAMS TYPE NULL ARE preferredPresent 2052 } 2054 id-hmacWithSHA256 OBJECT IDENTIFIER ::= { 2055 iso(1) member-body(2) us(840) rsadsi(113549) 2056 digestAlgorithm(2) 9 } 2058 maca-sha384 MAC-ALGORITHM ::= { 2059 IDENTIFIER id-hmacWithSHA384 2060 PARAMS TYPE NULL ARE preferredPresent 2061 } 2063 id-hmacWithSHA384 OBJECT IDENTIFIER ::= { 2064 iso(1) member-body(2) us(840) rsadsi(113549) 2065 digestAlgorithm(2) 10 } 2067 maca-sha512 MAC-ALGORITHM ::= { 2068 IDENTIFIER id-hmacWithSHA512 2069 PARAMS TYPE NULL ARE preferredPresent 2070 } 2072 id-hmacWithSHA512 OBJECT IDENTIFIER ::= { 2073 iso(1) member-body(2) us(840) rsadsi(113549) 2074 digestAlgorithm(2) 11 } 2076 -- 2077 -- Originator Public Key Algorithms 2078 -- 2080 -- Constraints on KeyAgreeRecipientInfo OriginatorIdentifierOrKey 2081 -- OriginatorPublicKey algorithm field 2083 -- PARAMS are NULL 2085 OriginatorPKAlgorithms PUBLIC-KEY ::= { 2086 opka-ec, 2087 ... -- Extensible 2088 } 2090 opka-ec PUBLIC-KEY ::={ 2091 IDENTIFIER id-ecPublicKey 2092 KEY ECPoint 2093 PARAMS TYPE CHOICE { n NULL, p ECParameters } ARE preferredAbsent 2094 } 2096 -- Format for both ephemeral and static public keys 2098 -- ECPoint ::= OCTET STRING 2100 -- Format of KeyAgreeRecipientInfo ukm field when used with 2101 -- ECMQV 2103 MQVuserKeyingMaterial ::= SEQUENCE { 2104 ephemeralPublicKey OriginatorPublicKey, 2105 addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL 2106 } 2107 -- 'SharedInfo' for input to KDF when using ECDH and ECMQV with 2108 -- EnvelopedData, AuthenticatedData, or AuthEnvelopedData 2110 ECC-CMS-SharedInfo ::= SEQUENCE { 2111 keyInfo AlgorithmIdentifier { KeyWrapAlgorithm }, 2112 entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL, 2113 suppPubInfo [2] EXPLICIT OCTET STRING 2114 } 2116 -- 2117 -- S/MIME Capabilities 2118 -- 2120 SMIME-CAPS ::= CLASS { 2121 &Type OPTIONAL, 2122 &id OBJECT IDENTIFIER UNIQUE 2123 } 2124 WITH SYNTAX {TYPE &Type IDENTIFIED BY &id } 2126 SMIMECapability ::= SEQUENCE { 2127 capabilityID SMIME-CAPS.&id({SMimeCapsSet}), 2128 parameters SMIME-CAPS. 2129 &Type({SMimeCapsSet}{@capabilityID}) OPTIONAL 2130 } 2131 SMimeCapsSet SMIME-CAPS ::= { 2132 cap-ecdsa-with-SHA1 | 2133 cap-ecdsa-with-SHA224 | 2134 cap-ecdsa-with-SHA256 | 2135 cap-ecdsa-with-SHA384 | 2136 cap-ecdsa-with-SHA512 | 2137 cap-dhSinglePass-stdDH-sha1kdf | 2138 cap-dhSinglePass-stdDH-sha224kdf | 2139 cap-dhSinglePass-stdDH-sha256kdf | 2140 cap-dhSinglePass-stdDH-sha384kdf | 2141 cap-dhSinglePass-stdDH-sha512kdf | 2142 cap-dhSinglePass-cofactorDH-sha1kdf | 2143 cap-dhSinglePass-cofactorDH-sha224kdf | 2144 cap-dhSinglePass-cofactorDH-sha256kdf | 2145 cap-dhSinglePass-cofactorDH-sha384kdf | 2146 cap-dhSinglePass-cofactorDH-sha512kdf | 2147 cap-mqvSinglePass-sha1kdf | 2148 cap-mqvSinglePass-sha224kdf | 2149 cap-mqvSinglePass-sha256kdf | 2150 cap-mqvSinglePass-sha384kdf | 2151 cap-mqvSinglePass-sha512kdf, 2152 ... -- Extensible 2153 } 2155 -- 2156 -- S/MIME Capabilities: ECDSA with SHA-1, SHA-224, SHA-256, SHA-384, 2157 -- and SHA-512 Algorithms 2158 -- 2160 cap-ecdsa-with-SHA1 SMIME-CAPS ::= { 2161 TYPE NULL IDENTIFIED BY sa-ecdsaWithSHA1.&id } 2163 cap-ecdsa-with-SHA224 SMIME-CAPS ::= { 2164 TYPE NULL IDENTIFIED BY sa-ecdsaWithSHA224.&id } 2166 cap-ecdsa-with-SHA256 SMIME-CAPS ::= { 2167 TYPE NULL IDENTIFIED BY sa-ecdsaWithSHA256.&id } 2169 cap-ecdsa-with-SHA384 SMIME-CAPS ::= { 2170 TYPE NULL IDENTIFIED BY sa-ecdsaWithSHA384.&id } 2172 cap-ecdsa-with-SHA512 SMIME-CAPS ::= { 2173 TYPE NULL IDENTIFIED BY sa-ecdsaWithSHA512.&id } 2175 -- 2176 -- S/MIME Capabilities: ECDH, Single Pass, Standard 2177 -- 2179 cap-dhSinglePass-stdDH-sha1kdf SMIME-CAPS ::= { 2180 TYPE KeyWrapAlgorithm IDENTIFIED BY dhSinglePass-stdDH-sha1kdf } 2182 cap-dhSinglePass-stdDH-sha224kdf SMIME-CAPS ::= { 2183 TYPE KeyWrapAlgorithm IDENTIFIED BY dhSinglePass-stdDH-sha224kdf } 2185 cap-dhSinglePass-stdDH-sha256kdf SMIME-CAPS ::= { 2186 TYPE KeyWrapAlgorithm IDENTIFIED BY dhSinglePass-stdDH-sha256kdf } 2188 cap-dhSinglePass-stdDH-sha384kdf SMIME-CAPS ::= { 2189 TYPE KeyWrapAlgorithm IDENTIFIED BY dhSinglePass-stdDH-sha384kdf } 2191 cap-dhSinglePass-stdDH-sha512kdf SMIME-CAPS ::= { 2192 TYPE KeyWrapAlgorithm IDENTIFIED BY dhSinglePass-stdDH-sha512kdf } 2194 -- 2195 -- S/MIME Capabilities: ECDH, Single Pass, Cofactor 2196 -- 2198 cap-dhSinglePass-cofactorDH-sha1kdf SMIME-CAPS ::= { 2199 TYPE KeyWrapAlgorithm 2200 IDENTIFIED BY dhSinglePass-cofactorDH-sha1kdf } 2202 cap-dhSinglePass-cofactorDH-sha224kdf SMIME-CAPS ::= { 2203 TYPE KeyWrapAlgorithm 2204 IDENTIFIED BY dhSinglePass-cofactorDH-sha224kdf } 2206 cap-dhSinglePass-cofactorDH-sha256kdf SMIME-CAPS ::= { 2207 TYPE KeyWrapAlgorithm 2208 IDENTIFIED BY dhSinglePass-cofactorDH-sha256kdf } 2210 cap-dhSinglePass-cofactorDH-sha384kdf SMIME-CAPS ::= { 2211 TYPE KeyWrapAlgorithm 2212 IDENTIFIED BY dhSinglePass-cofactorDH-sha384kdf } 2214 cap-dhSinglePass-cofactorDH-sha512kdf SMIME-CAPS ::= { 2215 TYPE KeyWrapAlgorithm 2216 IDENTIFIED BY dhSinglePass-cofactorDH-sha512kdf } 2218 -- 2219 -- S/MIME Capabilities: ECMQV, Single Pass, Standard 2220 -- 2222 cap-mqvSinglePass-sha1kdf SMIME-CAPS ::= { 2223 TYPE KeyWrapAlgorithm IDENTIFIED BY mqvSinglePass-sha1kdf } 2225 cap-mqvSinglePass-sha224kdf SMIME-CAPS ::= { 2226 TYPE KeyWrapAlgorithm IDENTIFIED BY mqvSinglePass-sha224kdf } 2228 cap-mqvSinglePass-sha256kdf SMIME-CAPS ::= { 2229 TYPE KeyWrapAlgorithm IDENTIFIED BY mqvSinglePass-sha256kdf } 2231 cap-mqvSinglePass-sha384kdf SMIME-CAPS ::= { 2232 TYPE KeyWrapAlgorithm IDENTIFIED BY mqvSinglePass-sha384kdf } 2234 cap-mqvSinglePass-sha512kdf SMIME-CAPS ::= { 2235 TYPE KeyWrapAlgorithm IDENTIFIED BY mqvSinglePass-sha512kdf } 2237 END 2239 Acknowledgements 2241 The methods described in this document are based on work done by the 2242 ANSI X9F1 working group. The authors wish to extend their thanks to 2243 ANSI X9F1 for their assistance. The authors also wish to thank Peter 2244 de Rooij for his patient assistance. The technical comments of 2245 Francois Rousseau were valuable contributions. 2247 Many thanks go out to the other authors of RFC 3278: Simon Blake- 2248 Wilson and Paul Lambert. Without RFC 3278 this version wouldn't 2249 exist. 2251 The authors also wish to thank Alfred Hoenes, Paul Hoffman, Russ 2252 Housley, and Jim Schaad for their valuable input. 2254 Author's Addresses 2256 Sean Turner 2258 IECA, Inc. 2259 3057 Nutley Street, Suite 106 2260 Fairfax, VA 22031 2261 USA 2263 Email: turners@ieca.com 2265 Daniel R. L. Brown 2267 Certicom Corp 2268 5520 Explorer Drive #400 2269 Mississauga, ON L4W 5L1 2270 CANADA 2272 Email: dbrown@certicom.com 2274 Full Copyright Statement 2276 Copyright (C) The IETF Trust (2008). 2278 This document is subject to the rights, licenses and restrictions 2279 contained in BCP 78, and except as set forth therein, the authors 2280 retain all their rights. 2282 This document and the information contained herein are provided on an 2283 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2284 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2285 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2286 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2287 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2288 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2290 Intellectual Property 2292 The IETF takes no position regarding the validity or scope of any 2293 Intellectual Property Rights or other rights that might be claimed to 2294 pertain to the implementation or use of the technology described in 2295 this document or the extent to which any license under such rights 2296 might or might not be available; nor does it represent that it has 2297 made any independent effort to identify any such rights. Information 2298 on the procedures with respect to rights in RFC documents can be 2299 found in BCP 78 and BCP 79. 2301 Copies of IPR disclosures made to the IETF Secretariat and any 2302 assurances of licenses to be made available, or the result of an 2303 attempt made to obtain a general license or permission for the use of 2304 such proprietary rights by implementers or users of this 2305 specification can be obtained from the IETF on-line IPR repository at 2306 http://www.ietf.org/ipr. 2308 The IETF invites any interested party to bring to its attention any 2309 copyrights, patents or patent applications, or other proprietary 2310 rights that may cover technology that may be required to implement 2311 this standard. Please address the information to the IETF at 2312 ietf-ipr@ietf.org. 2314 Acknowledgment 2316 Funding for the RFC Editor function is provided by the IETF 2317 Administrative Support Activity (IASA).