idnits 2.17.1 draft-ietf-smime-ecc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of lines with control characters in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 678 == Missing Reference: 'SECG-WG-EC' is mentioned on line 601, but not defined == Unused Reference: 'FIPS-180' is defined on line 717, but no explicit reference was found in the text == Unused Reference: 'FIPS-186' is defined on line 721, but no explicit reference was found in the text == Unused Reference: 'GEC1' is defined on line 725, but no explicit reference was found in the text == Unused Reference: 'KEA' is defined on line 728, but no explicit reference was found in the text == Unused Reference: 'LAW98' is defined on line 731, but no explicit reference was found in the text == Unused Reference: 'LL97' is defined on line 736, but no explicit reference was found in the text == Unused Reference: 'MSG' is defined on line 742, but no explicit reference was found in the text == Unused Reference: 'NIST-ECC' is defined on line 748, but no explicit reference was found in the text == Unused Reference: 'IEEE1363' is defined on line 753, but no explicit reference was found in the text == Unused Reference: 'SEC1' is defined on line 757, but no explicit reference was found in the text == Unused Reference: 'SEC-WG-EC' is defined on line 760, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2630 (ref. 'CMS') (Obsoleted by RFC 3369, RFC 3370) -- Possible downref: Non-RFC (?) normative reference: ref. 'EPKIX' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-186' -- Possible downref: Non-RFC (?) normative reference: ref. 'GEC1' -- Possible downref: Non-RFC (?) normative reference: ref. 'KEA' -- Possible downref: Non-RFC (?) normative reference: ref. 'LAW98' -- Possible downref: Non-RFC (?) normative reference: ref. 'LL97' ** Obsolete normative reference: RFC 2633 (ref. 'MSG') (Obsoleted by RFC 3851) -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-ECC' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE1363' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC-WG-EC' ** Downref: Normative reference to an Informational RFC: RFC 2785 (ref. 'SSG') Summary: 8 errors (**), 0 flaws (~~), 15 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Daniel R. L. Brown 2 draft-ietf-smime-ecc-01.txt Certicom Corp 3 14 July, 2000 Expires: 14 January 2001 5 Use of ECC Algorithms in S/MIME 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. Internet-Drafts are 11 working documents of the Internet Engineering Task Force (IETF), 12 its areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet-Drafts 18 as reference material or to cite them other than as "work in 19 progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Abstract 29 This document is the second draft of a profile for the 30 incorporation of Elliptic Curve Cryptography (ECC) public key 31 algorithms in the Cryptographic Message Syntax (CMS). The ECC 32 algorithms support the creation of digital signatures and the 33 exchange of keys to encrypt or authenticate message content. The 34 definition of the algorithm processing is based on the ANSI X9.62 35 standard and the ANSI X9.63 draft, developed by the ANSI X9F1 36 working group. 38 Table of Contents 40 1 Introduction ........................................ 3 41 1.1 Requirement terminology ........................ 3 42 2 EnvelopedData using ECC ............................. 3 43 2.1 EnvelopedData using X9.63 ECDH ................. 3 44 2.1.1 Fields of KeyAgreeRecipientInfo type .... 4 45 2.1.2 Actions of the sending agent ............ 5 46 2.1.3 Actions of the receiving agent .......... 5 47 2.2 EnvelopedData using X9.63 modified ECDH ........ 5 48 2.2.1 Fields of KeyAgreeRecipientInfo type .... 6 49 2.2.2 Actions of the sending agent ............ 6 50 2.2.3 Actions of the receiving agent .......... 6 51 2.3 EnvelopedData using X9.63 1-Pass MQV ........... 7 52 2.3.1 Fields of KeyAgreeRecipientInfo type .... 7 53 2.3.2 Actions of the sending agent ............ 9 54 2.3.3 Actions of the receiving agent .......... 9 55 2.3.4 Originator certificates ................. 9 56 3 AuthenticatedData using X9.63 1-Pass MQV ............ 10 57 3.1 AuthenticatedData using X9.63 1-pass MQV ....... 11 58 3.1.1 Fields of KeyAgreeRecipientInfo type .... 11 59 3.1.2 Actions of the sending agent ............ 11 60 3.1.3 Actions of the receiving agent .......... 11 61 3.1.4 Originator certificates ................. 11 62 3.1.5 Re-using a KEK with 1-Pass MQV .......... 11 63 4 SignedData using ECC ................................ 12 64 4.1 SignedData using X9.62 ECDSA ................... 12 65 4.1.1 Fields of the SignedData type ........... 13 66 4.1.2 Actions of the sending agent ............ 14 67 4.1.3 Actions of the receiving agent .......... 14 68 5 Certificates using ECC .............................. 15 69 6 SMIMECapabilites Attribute and ECC .................. 15 70 7 ASN.1 Types and Identifiers ......................... 15 71 7.1 Object identifiers ............................. 15 72 7.2 Type definitions ............................... 17 73 8 Summary ............................................. 17 74 References ............................................. 18 75 Security Considerations ................................ 19 76 Intellectual Property Rights ........................... 19 77 Acknowledgments ........................................ 20 78 Author's Address ....................................... 20 79 Full Copyright Statement ............................... 20 81 1 Introduction 83 The Cryptographic Message Syntax (CMS) is cryptographic algorithm 84 independent. This specification defines a standard profile for the 85 use of Elliptic Curve Cryptography (ECC) public key algorithms in 86 the CMS. The ECC algorithms are incorporated into following CMS 87 content types: 89 - 'EnvelopedData' to support ECC public key agreement methods 90 (ECDH and MQV) to generate pairwise key-encryption keys to 91 encrypt content-encryption keys used for content encryption 93 - 'AuthenticatedData' to support ECC based public key agreement 94 methods (MQV) to generate pairwise key-encryption keys to 95 encrypt MAC keys used for content authentication 97 - 'SignedData' to support ECC based digital signature methods 98 (ECDSA) to sign content 100 Certificates based on ECC digital signatures (ECDSA) are also 101 supported. 103 1.1 Requirements terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 107 this document are to be interpreted as described in RFC 2119 108 [MUST]. 110 2 EnvelopedData using X9.63 ECC methods 112 Elliptic curve cryptography (ECC) methods for key agreement are 113 specified in [X9.63]. This specification refers to [X9.63] for the 114 cryptographic operations. 116 Note: all the key agreement methods here use the key derivation 117 method specified in [X9.63, Section 5.6.3]. 119 2.1 EnvelopedData using X9.63 (standard) ephemeral-static ECDH 121 Ephemeral-static Elliptic Curve Diffie-Hellman (ECDH) key agreement 122 algorithm is the elliptic curve analog of the Diffie-Hellman key 123 agreement algorithm specified jointly in the documents [CMS, 124 Section 12.3.1.1] and [DH-X9.42]. The key agreement method is 125 adapted to use the elliptic curve methods from [X9.63, Section 126 6.2], the "1-Pass Diffie-Hellman scheme" using the standard 127 Diffie-Hellman primitive [X9.63, Section 5.4.1]. 129 2.1.1 Fields of KeyAgreeRecipientInfo type 131 When using ephemeral-static ECDH, the EnvelopedData RecipientInfos 132 KeyAgreementInfo fields must be used as follows: 134 version is 3, as in [CMS, section 12.3.1.1]. 136 originator is the alternative originatorKey, as in [CMS, Section 137 12.3.1.1]. The originatorKey algorithm fields contains the 138 id-ecPublicKey object identifer with absent parameters. The 139 id-ecPublicKey object identifier is: 141 id-ecPublicKey OBJECT IDENTIFIER ::= { iso(1) member-body(2) 142 ansi-x9-62(10045) keyType(2) 1 } 144 The originatorKey publicKey field contains the sender's 145 ephemeral EC public key as determined below (by methods of 146 [X9.63]). 148 ukm may be absent, as in [CMS, Section 12.3.1.1], and has the 149 same meaning as in [CMS]. 151 keyEncryptionAlgorithm is the dhSinglePass-stdDH-sha1kdf-scheme 152 algorithm identifier, with parameter field KeyWrapAlgorithm 153 present, with the follow value and syntax: 155 dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 156 iso(1) identified-organization(3) tc68(133) country(16) 157 x9(840) x9-63(63) schemes(0) 2} 159 KeyWrapAlgorithm ::= AlgorithmIdentifier 161 The KeyWrapAlgorithm indicates the symmetric encryption 162 algorithm used to encrypt the CEK with the KEK. 164 recipientEncryptedKeys contains an encrypted (wrapped) 165 content-encryption key and an identifier for each recipient, as 166 in [CMS, section 12.3.1.1]. 168 The next two sections specify actions of sending and receiving 169 agents to handle ephemeral-static ECDH in keyAgreeRecipientInfo 170 fields of EnvelopedData. 172 2.1.2 Actions of the sending agent 174 When using ephemeral-static ECDH to generate EnvelopedData 175 KeyAgreeRecipientInfo fields, the sending agent selects groups of 176 recipients with common EC domain parameters. For each group, the 177 sending agent selects an ephemeral EC public key pair, as per the 178 1-Pass Diffie-Hellman scheme initiator transformation, specified in 179 [X9.63, Section 6.2.1]. The sending agent determines an integer 180 "keydatalen" from key-size of the KeyWrapAlgorithm and a bit string 181 "SharedData" from the ukm field if present. For each recipient in 182 the group, the sending agent completes the X9.63 1-Pass 183 Diffie-Hellman initiator transformation using the selected 184 ephemeral EC public key and the recipient's static EC public key 185 (i.e. from a certificate) to obtain a bit string "KeyData". The 186 "KeyData" bit string becomes the pairwise key-encryption key for 187 the recipient. 189 2.1.3 Actions of the receiving agent 191 The receiving agent uses the following process on an EnvelopedData 192 to detect if ephemeral-static Diffie-Hellman is used to transfer 193 the CEK to the receiving agent, and if so to compute the 194 key-encryption key used to unwrap the CEK. 196 The receiving agent determines the bit string "SharedData" from the 197 ukm field if present, and the integer "keydatalen" from the 198 key-size of the KeyWrapAlgorithm and completes the X9.63 1-Pass 199 Diffie-Hellman responder transformation [X9.63, Section 6.2.2], 200 using the ephemeral EC public key and the identified receiving 201 agent's static EC public key, to obtain a bit string "KeyData". 202 The "KeyData" bit string becomes the pairwise key-encryption key 203 for the receiving agent. 205 2.2 EnvelopedData using X9.63 modified ephemeral-static ECDH 207 Modified ephemeral-static Elliptic Curve Diffie-Hellman (ECDH) key 208 agreement algorithm is identical to standard ECDH except that a 209 modified version of the Diffie-Hellman primitive [X9.63, Section 210 5.4.2] is used. The modification involves multiplication by a 211 cofactor. A purpose of the modification is to prevent the 212 small-subgroup attack [SSG]. To indicate that the modified 213 Diffie-Hellman primitive is used, a different algorithm identifider 214 for this key agreement algorithm is provided, as specified below. 216 2.2.1 Fields of KeyAgreeRecipientInfo type 218 When using modified ephemeral-static ECDH, the EnvelopedData 219 RecipientInfos KeyAgreementInfo fields are the same as in those 220 specified in Section 2.1.1 of this document, except: 222 keyEncryptionAlgorithm is the 223 dhSinglePass-cofactorDH-sha1kdf-scheme algorithm identifier, 224 with parameter KeyWrapAlgorithm present, and the following value 225 and syntax: 227 dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= 228 { iso(1) identified-organization(3) tc68(133) country(16) 229 x9(840) x9-63(63) schemes(0) 3} 231 KeyWrapAlgorithm ::= AlgorithmIdentifier 233 2.2.2 Actions of the sending agent 235 The actions of the sending agent are identical to the actions of 236 sending agent using standard ephemeral-static ECDH specified above 237 in Section 2.1.2, except that: 239 - The sending agent uses the modified Diffie-Hellman primitive 240 of [X9.63, Section 5.4.2] rather than the standard 241 Diffie-Hellman primitive [X9.63, Section 5.4.1]. 243 Note: modified and standard ephemeral-static ECDH can only be used 244 within separate KeyAgreeRecipientInfo fields. 246 2.2.3 Actions of the receiving agent 248 The actions of the receiving agent are identical to the actions of 249 receiving agent using standard ephemeral-static ECDH specified 250 above in Section 2.1.2, except that: 252 - The receiving agent uses the modified Diffie-Hellman primitive 253 of [X9.63, Section 5.4.2] rather than the standard 254 Diffie-Hellman primitive [X9.63, Section 5.4.1]. 256 2.3 EnvelopedData using X9.63 1-Pass MQV 258 In [X9.63, Appendix H.4.5], 1-Pass MQV is suggested for 259 store-and-forward applications such as e-mail. 261 The 1-Pass MQV key agreement method, specified in [X9.63, Section 262 6.9], uses three EC public keys to generate keying data 263 (i.e. pairwise key-encryption key). The three keys are: a static 264 recipient key, a static originator key, and an ephemeral originator 265 key. 267 The originator's static EC public key is identified in the 268 originator field, usually by reference to a certificate. The 269 originator's ephemeral EC public is specified within the ukm field. 270 The recipient's static EC public key is identified according to 271 [CMS], within a rid field. 273 2.3.1 Fields of KeyAgreeRecipientInfo type 275 When using 1-Pass MQV, the EnvelopedData RecipientInfos 276 KeyAgreementInfo fields are used as follows: 278 version is 3, as in [CMS, section 12.3.1.1]. 280 originator identifies the static EC public key of the sender. 281 It should be the one of the alternatives issuerAndSerialNumber 282 or subjectKeyIdentifier and point to one of the sender's 283 certificates supplied in the EnvelopedData originatorInfo field. 284 (If necessary, it may be the alternative originatorKey, as in 285 [CMS, Section 12.3.1.1], and if so, the originatorKey algorithm 286 field contains the id-ecPublicKey object identifer with absent 287 parameters. The id-ecPublicKey object identifier is: 289 id-ecPublicKey OBJECT IDENTIFIER ::= { iso(1) member-body(2) 290 ansi-x9-62(10045) keyType(2) 1 } 292 The originatorKey publicKey field contains the sender's static 293 EC public key.) 294 ukm is present. It identifies the ephemeral EC public key of 295 the sender. It may also identify some additional information 296 for purposes similar to those specified in [CMS, Section 297 12.3.1.1]. The ukm field contains an octet string which is the 298 DER encoding of the following ASN.1 type 300 MQVuserKeyingMaterial ::= SEQUENCE { 301 ephemeralPublicKey OriginatorPublicKey, 302 addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL } 304 The MQVuserKeyingMaterial ephemeralPublicKey algorithm field 305 contains the id-ecPublicKey object identifer with absent 306 parameters. The id-ecPublicKey object identifier is: 308 id-ecPublicKey OBJECT IDENTIFIER ::= { iso(1) 309 member-body(2) ansi-x9-62(10045) keyType(2) 1 } 311 The MQVuserKeyingMaterial ephemeralPublicKey publicKey field 312 contains the sender's ephemeral EC public key as determined 313 below (by methods of [X9.63]). The MQVuserKeyingMaterial 314 addedukm field, if present, contains an octet string, whose 315 meaning is similar to meaning of the ukm field in [CMS, 316 Section 12.3.1.1]. 318 keyEncryptionAlgorithm is the mqvSinglePass-sha1kdf-scheme 319 algorithm identifier, with parameter field KeyWrapAlgorithm 320 present, with the following values and syntax: 322 mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 323 identified-organization(3) tc68(133) country(16) x9(840) 324 x9-63(63) schemes(0) 16} 326 KeyWrapAlgorithm ::= AlgorithmIdentifier 328 The KeyWrapAlgorithm indicates the symmetric encryption 329 algorithm used to encrypt the CEK with the KEK generated using 330 the 1-Pass MQV algorithm. 332 recipientEncryptedKeys contains an encrypted (wrapped) 333 content-encryption key and an identifier for each recipient, as 334 in [CMS, section 12.3.1.1]. 336 2.3.2 Actions of the sending agent 338 When using 1-Pass MQV to generate EnvelopedData 339 KeyAgreeRecipientInfo fields, the sending agent selects groups of 340 recipients with common EC domain parameters. For each group, the 341 sending agent selects an ephemeral EC public key pair, as per the 342 1-Pass MQV scheme initiator transformation, specified in [X9.63, 343 Section 6.9.1]. The sending agent specifies the ephemeral EC 344 public key in the KeyAgreeRecipientInfo ukm field, ASN.1 encoded 345 within in the MQVuserKeyingMaterial ephemeralPublickey publicKey 346 field. The sending agent determines an integer "keydatalen" from 347 key-size of the KeyWrapAlgorithm and a bit string "SharedData" from 348 the MQVuserKeyingMaterial addedukm field (if present) ASN.1 encoded 349 in the ukm field. For each recipient in the group, the sending 350 agent completes the 1-Pass MQV initiator transformation using the 351 selected ephemeral EC public key pair, the static EC public keys 352 (i.e. from certificates) of the originator and the recipient, and 353 the bit string "SharedData" if present, to obtain a bit string 354 "KeyData". The bit string "KeyData" becomes the pairwise 355 key-encryption key (KEK) for the recipient. 357 2.3.3 Actions of the receiving agent 359 The receiving agent uses the following process on an EnvelopedData 360 to detect if 1-Pass MQV is used to agree on the pairwise KEK for 361 the receiving agent, and if so to compute the pairwise KEK. 363 The receiving agent determines the bit string "SharedData" from the 364 ukm field if present, and the integer "keydatalen" from the 365 key-size of the KeyWrapAlgorithm and completes the 1-Pass MQV 366 responder transformation [X9.63, Section 6.9.2], using the 367 ephemeral EC public key, the identified static EC public keys of 368 the recipient and originator, and the bit string "SharedData" if 369 present, to obtain a bit string "KeyData". The bit string 370 "KeyData" becomes the the pairwise key-encryption key (KEK) for the 371 receiving agent. 373 2.3.4 Originator's certificates 375 If some recipients do not have other means to obtain the 376 originator's certificate for a static EC public key used in 1-Pass 377 MQV, then the originator's certificate containing the originator 378 static EC public key should be included in the EnvelopedData 379 originatorInfo field. 381 3 AuthenticatedData using ECC 383 The 1-Pass MQV scheme of [X9.63] has been selected in this document 384 for AuthenticatedData using ECC because it has security attributes 385 that are appropriate for the AuthenticatedData CMS type. 387 Note: in general, pure 'ephemeral-static' key agreement methods are 388 not suitable for AuthenticatedData because the originator's key is 389 ephemeral and therefore not authenticated. 391 Note: both SignedData and AuthenticatedData provide assurance to 392 the receiving agent that the content data originated from the 393 purported originator and the content was in no way modified. 394 However, SignedData and AuthenticatedData differ in some important 395 respects: 397 1. In AuthenticatedData the assurance of the content origin and 398 integrity is only provided to the specific recipients of the 399 AuthenticatedData. In SignedData, the assurance of content 400 origin and integrity is provided to potentially everyone. 402 2. In AuthenticatedData, the sending agent and receiving agent 403 are equally capable producing any given AuthenticatedData. In 404 SignedData, only the sending agent is capable of producing the 405 SignedData. 407 Careful consideration should be applied to the choice of using 408 AuthenticatedData or SignedData because of the these differences. 409 In particular, in AuthenticatedData the originator has less 410 'commitment' to the content than SignedData because 411 AuthenticatedData does not have the non-repudiative feature of 412 SignedData. 414 3.1 AuthenticatedData using 1-pass MQV 416 In general, using 1-Pass MQV in AuthenticatedData is similar to 417 using 1-Pass MQV in EnvelopedData (see Section 2.3 of this 418 document). Further details are provided in Sections 3.1.1 to 419 3.1.4. 421 However, 1-Pass MQV, AuthenticatedData and EnvelopedData can be use 422 together more efficiently by the re-using pairwise key-encryption 423 keys. A method to do this is specified in Section 3.1.5. 425 3.1.1 Fields of the KeyAgreementInfo type 427 The AuthenticatedData KeyAgreeRecipientInfo fields are used in the 428 same manner as the fields for the corresponding EnvelopedData 429 KeyAgreeRecipeintInfo fields of Section 2.3.1 of this document. 431 Note: the originator field should be one of the alternatives 432 issuerAndSerialNumber or subjectKeyIdentifier. If it is necessary 433 to use the originatorKey alternative, the recipients should have 434 other means (i.e. without certificates) to authenticate the 435 originator's static key. 437 3.1.2 Actions of the sending agent 439 The sending agent may use the same actions as for EnvelopedData 440 with 1-Pass MQV, as specified in Section 2.3.2 of this document. 442 3.1.3 Actions of the receiving agent 444 The receiving agent may use the same actions as for EnvelopedData 445 with 1-Pass MQV, as specified in Section 2.3.3 of this document. 447 3.1.4 Originator certificates 449 If some recipients do not have other means to obtain the 450 originator's certificate for a static EC public key used in 1-Pass 451 MQV, then the originator's certificate certifying the originator 452 static EC public key should be included in the AuthenticatedData 453 originatorInfo field. 455 For recipients that do not have other measn to obtain all the issue 456 certificates necessary to authenticate the originator's static EC 457 public key, then the necessary certificates (i.e. CA 458 cross-certifcates) may be included in the AuthenticatedData 459 originatorInfo field. 461 3.1.5 Re-using a KEK with 1-Pass MQV 463 When using 1-Pass MQV for an AuthenticatedData whose content is an 464 EnvelopedData, or for an AuthenticatedData which is the content is 465 an EnvelopedData, the KEKRecipientInfo type of [CMS] is an 466 efficient way to re-use a 1-Pass MQV generated pairwise KEK from 467 the EnvelopedData. Re-use of the EnvelopedData KEK helps to reduce 468 the total length of the ASN.1 encoding of the AuthenticatedData and 469 the total number of public key cryptographic operations performed 470 by both sending agents and receiving agents. 472 The KEKRecipientInfo encryptedKey field contains the wrapped "MAC" 473 key, encrypted with the previously generated KEK using 1-Pass MQV. 474 Generally, the pairwise KEK will have been generated within an 475 EnvelopedData. The KEKRecipientInfo KEKIdentifier keyIdentifier 476 field may be used to identify the re-used secret pairwise KEK 477 by providing an octet encoding of the originator's ephemeral EC 478 public key used in a 1-Pass MQV to to generate the KEK. 480 The KEKIdentifier other field may be absent, if it is certain that 481 the KEK is unambiguously identified. If the KEKIdentifier 482 keyIdentifier field alone is insufficient to identify the KEK 483 (perhaps because the receiving agent supports other methods that 484 use KEKReicipientInfo) then the KEKIdentifier other keyAttrId 485 field may be object identifier mqvSinglePass-sha1kdf-scheme (see 486 Section 2.3.1 of this document). 488 Note: if the content of the AuthenticatedData is an EnvelopedData, 489 then the KeyAgreeRecipientInfo fields of the EnvelopedData are in 490 plaintext and therefore, the KEK can be computed before the 491 EnvelopedData is decrypted or encrypted. If the content of an 492 EnvelopedData is an AuthenticatedData the KEK will be computed 493 before the AuthenticatedData is encrypted or decrypted. In the 494 either case, both the sending agent and receiving agent are able to 495 determine the necessary KEK from the EnvelopedData. 497 4 SignedData using ECC 499 An elliptic curve cryptography (ECC) method for signing is 500 specified in [X9.62]. In a single SignedData type [CMS] many 501 signing algorithms may be used but within each SignerInfo field 502 only one signing algorithm can be used. 504 4.1 SignedData using X9.62 ECDSA 506 The Elliptic Curve Digital Signature Algorithm (ECDSA) is specified 507 in [X9.62]. The method is the elliptic curve analog of the [X9.30] 508 Digital Signature Algorithm (DSA). In [CMS] the meanings of the 509 fields of SignedData are specified, the actions of the sending 510 agent to generate SignedData are specified and the actions of the 511 receiving agent to process SignedData are specified. In [CMS], the 512 specificiations are algorithm independent. The following 513 subsections provide additional details about the SignedData fields 514 and actions of S/MIME agents when [X9.62] ECDSA is being used with 515 SignedData. 517 4.1.1 Fields of the SignedData type 519 When using [X9.62] ECDSA in an SignedData SignerInfo type the 520 fields are as in [CMS], but with the following restrictions. 522 digestAlgorithm is the following algorithm identifier for SHA-1: 524 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 525 oiw(14) secsig(3) algorithm(2) 26 } 527 signatureAlgorithm is an algorithm identifer with parameters 528 field absent that identifies the ECDSA signature algorithm with 529 the object identifier: 531 ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 532 us(840) 10045 signatures(4) 1 } 534 signature is the DER encoding (as an octet string) of a value of 535 the [X9.62] ASN.1 type: 537 ECDSA-Sig-Value ::= SEQUENCE { 538 r INTEGER, 539 s INTEGER } 541 where the integers r and s are caculated according to [X9.62, 542 Section 5.3] using the signer's private key except that the 543 integer "e" is the result of the SignedData message digest 544 specified in [CMS] converted from an octet string to an intger 545 (i.e. not the result of [X9.63, Section 5.3.1]). 547 When using [X9.62] ECDSA the SignedData certificates field may 548 include the certificates for the EC public keys used in generation 549 of ECDSA signatures in the SignedData. If it is expected that 550 recipients have alternative means of obtaining the certain 551 certificates necessary to authenticate the EC public keys used for 552 signing, then such certificates may be omitted from the SignedData 553 certificates field. All certificates necessary for the 554 authentication of the EC public keys using for signing for which it 555 is not expected that the recipients have alternative means of 556 obtaining should be included in the SignedData certificates field. 558 4.1.2 Actions of the sending agent 560 The sending agent uses the message digest calculation process and 561 signature generation process for SignedData that are specified in 562 [CMS]. The sending agent follows the actions for ECDSA signature 563 generation specified in [X9.62, Section 5.3] with the following 564 exceptions: 566 - In [X9.62, Section 5.3.1], the integer "e" shall instead 567 be determined by converting the octet string resulting from 568 [CMS, Section 5.4] to an integer using the data conversion 569 method in [X9.62, Section 4.3.2]. 571 The sending agent uses the encoding process specified [X9.62, 572 Section 6.5] to convert (encode) the ECDSA signature as an octet 573 string. This octet string is the value of the SignerInfo 574 SignatureValue field. The sending agent uses DER encoding rules 575 and includes the entire encoding of the ASN.1 type ECDSA-Sig-Value 576 (see above and [X9.62]) including the tag and length octets in the 577 octet string SignerInfo SignatureValue. 579 4.1.3 Actions of the receiving agent 581 The receiving agent uses the message digest calculation process 582 and signature verification process for SignedData that are 583 specified in [CMS]. The receiving agent follows the actions 584 for ECDSA signature verification specified in [X9.62, Section 5.4] 585 with the following exceptions: 587 - In [X9.62, Section 5.4.1] the integer "e" shall instead be 588 determined by converting the octet string resulting from [CMS, 589 Section 5.4] to an integer using the data conversion method in 590 [X9.62, Section 4.3.2]. 592 The receiving agent uses the encoding process specified in [X9.62, 593 Section 6.5] to convert (decode) the octet string value of the 594 SignerInfo SignatureValue field to the [X9.62] signature. The 595 receiving agent uses DER decoding rules. 597 5 Certificates using ECC 599 The use of a certificates with ECC is specified in [EPKIX]. 600 Further information on the use ECC with certificates is given in 601 [SECG-WG-EC]. 603 6 SMIMECapabilities Attribute and ECC 605 A sending agent may choose to announce to receiving agents that it 606 supports one or more of the ECC algorithms in this document by 607 using SMIMECapabilities signed attribute as specified in [MSG, 608 Section 2.5.2]. 610 The SMIMECapability capabilityID object identifiers for the 611 supported key agreement algorithms in this document are 612 dhSinglePass-stdDH-sha1kdf-scheme, 613 dhSinglePass-cofactorDH-sha1kdf-scheme, and 614 mqvSinglePass-sha1kdf-scheme. For each of these SMIMECapability 615 SEQUENCEs the parameters field is present and indicates the 616 supported key-encryption algorithm with the KeyWrapAlgorithm 617 algorithm identifier. 619 The SMIMECapability value to indicate support for the ECDSA 620 signature algorithm is the SEQUENCE with the capabilityID field 621 containing the object identifier ecdsa-with-SHA1 and the parameters 622 field absent. 624 7 ASN.1 Types and Identifiers 626 The ASN.1 types and object identifiers that are used in this 627 document are gathered together in this section for reference 628 purposes. 630 7.1 Object identifiers 632 The object identifiers used in this document are taken from [CMS], 633 [X9.63] and [X9.62]. 635 The following object identifiers indicate the key agreement 636 algorithms used in this document: 638 dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 639 identified-organization(3) tc68(133) country(16) x9(840) 640 x9-63(63) schemes(0) 2} 642 dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 643 iso(1) identified-organization(3) tc68(133) country(16) 644 x9(840) x9-63(63) schemes(0) 3} 646 mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= { iso(1) 647 identified-organization(3) tc68(133) country(16) x9(840) 648 x9-63(63) schemes(0) 16} 650 The following object identifier indicates the digital signature 651 algorithm used in this document: 653 ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 654 us(840) 10045 signatures(4) 1 } 656 The following object identifier indicates the hash algorithm used 657 in this document: 659 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 660 oiw(14) secsig(3) algorithm(2) 26 } 662 The following object identifier is used in this document to 663 indicate an elliptic curve public key: 665 id-ecPublicKey OBJECT IDENTIFIER ::= { iso(1) member-body(2) 666 ansi-x9-62(10045) keyType(2) 1 } 668 7.2 Type definitions 670 The following ASN.1 type defintions are used. 672 ECDSA-Sig-Value ::= SEQUENCE { 673 r INTEGER, 674 s INTEGER } 676 MQVuserKeyingMaterial ::= SEQUENCE { 677 ephemeralPublicKey OriginatorPublicKey, 678 addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL } 680 The former is taken from [X9.62]. In this document, DER encodings 681 as octet strings of values of the two above ASN.1 types 682 ECDSA-Sig-Value and MQVuserKeyingMaterial are used as values of 683 octet string ASN.1 types from [CMS]. An encoding of 684 ECDSA-Sig-Value is used as the value of a SignedData SignerInfo 685 SignatureValue and an encoding of MQVuserKeyingMaterial is used as 686 the value of EnvelopedData KeyAgreeRecipeintInfo UserKeyingMaterial 687 or AuthenticatedData KeyAgreeRecipeintInfo UserKeyingMaterial. 689 8 Summary 691 This document specifies how to use ECC methods with S/MIME CMS 692 type. The most notable advantage of ECC methods over integer 693 arithmetic based methods (Diffie-Hellman, DSA and RSA) is the 694 shorter length of cryptographic overhead in signatures, 695 certificates, encrypted and authenticated messages.. 697 This document specifies a cryptographic method to be used with the 698 [CMS] content type AuthenticatedData. The cryptographic method is 699 X9.63 1-Pass MQV scheme. The AuthenticateData type achieves 700 authentication without 'non-repudiation'. For certain kinds of 701 data, AuthenticatedData may be preferrable to SignedData. 703 References 705 [CMS] R. Housley, "Cryptographic Message Syntax", RFC 2630, 706 June 1999. 708 [DH-X9.42] E. Rescorla, "Diffie-Hellman Key Agreement Method", RFC 709 2631, June 1999. 711 [EPKIX] L. Bassham and D. Johnson, "Internet X.509 Public Key 712 Infrastructure Representation of Elliptic Curve Digital 713 Signature Algorithm (ECDSA) Keys and Signatures in 714 Internet X.509 Public Key Infrastructure Certificates", 715 PKIX Working Group Internet-Draft, October, 1999. 717 [FIPS-180] Federal Information Processing Standards Publication 718 (FIPS PUB) 180-1, "Secure Hash Standard", 1995 April 719 17. 721 [FIPS-186] Federal Information Processing Standards Publication 722 (FIPS PUB) 186, "Digital Signature Standard", 1994 May 723 19. 725 [GEC1] Certicom Research, "Guidelines for Efficinet 726 Cryptography", GEC1, February, 1999. 728 [KEA] J. Pawling, "CMS KEA and SKIPJACK Conventions", S/MIME 729 Working Group Internet-Draft, December, 1999. 731 [LAW98] L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone, 732 "An efficient protocol for authenticated key 733 agreement", Technical report CORR 98-05, University of 734 Waterloo, 1998. 736 [LL97] C.H. Lim and P.J. Lee, "A key recovery attack on 737 discrete log-based schemes using a prime order 738 subgroup", B.S. Kaliski, Jr., editor, Advances in 739 Cryptology - Crypto '97, Lecture Notes in Computer 740 Science, vol. 1295, 1997, Springer-Verlag, pp. 249-263. 742 [MSG] B. Ramsdell, "S/MIME Version 3 Message Specification", 743 RFC 2633, June 1999. 745 [MUST] S. Bradner, "Key Words for Use in RFCs to Indicate 746 Requirement Levels", RFC 2119, March 1997. 748 [NIST-ECC] National Institute for Standards and Technology, 749 "Recommended Elliptic Curves for Federal Government 750 Use", July 1999, 751 753 [IEEE1363] IEEE, "Standard Specifications for Public Key 754 Cryptography", IEEE 1363-2000 Specification, 2000, 755 Annex D. 757 [SEC1] Certicom Research, "Elliptic Curve Cryptography", SEC1, 758 February, 1999. 760 [SEC-WG-EC] Certicom Research, "ECC in X.509", SEC X.509 Working 761 Group Draft, August, 1999. 763 [SSG] R. Zuccherato, "Methods for Avoiding the Small-Subgroup 764 Attacks on the Diffie-Hellman Key Agreement Method for 765 S/MIME", RFC 2785, March 2000. 767 [X9.30] ANSI X9.30-1995, Part 1, "Public key cryptography using 768 irreversible algorithms for the financial services 769 industry: The Digital Signature Algorithm (Revised)", 770 1995. 772 [X9.42] "Agreement Of Symmetric Keys Using Diffie-Hellman and 773 MQV Algorithms", ANSI draft, May 1999. 775 [X9.62] ANSI X9.62-1999, "Public Key Cryptography For The 776 Financial Services Industry: The Elliptic Curve Digital 777 Signature Algorithm (ECDSA)", 1999. 779 [X9.63] "Public Key Cryptography For The Financial Services 780 Industry: Key Agreement and Key Transport Using 781 Elliptic Curve Cryptography", Draft ANSI X9F1, October 782 1999. 784 Security Considerations 786 This specification is based on [CMS], [X9.62] and [X9.63] and the 787 appropriate security considerations of those documents apply. 789 Intellectual Property Rights 791 This specification is based on ANSI specification X9.62 and X9.63. 792 A variety of patent statements in these working may apply to this 793 specification. A later draft will attempt to identify a reference 794 for the ANSI X9F1 related claims. 796 Acknowledgments 798 The key agreement methods described in this document is based on 799 work done by the ANSI X9F1 working group. The author wishes to 800 extend his thanks for their assistance. 802 The author also wishes to thank Paul Lambert, Simon Blake-Wilson, 803 and Peter de Rooij for their patient assistance. The basis of this 804 work is derived from the ANSI X9F1 working group and their 805 specifications for ECDSA and EC key agreement techniques. 807 Author's Address 809 Daniel R. L. Brown 810 Certicom Corp 811 5520 Explorer Drive #400 812 Mississauga, ON L4W 5L1 814 EMail: dbrown@certicom.com 816 Full Copyright Statement 818 Copyright (C) The Internet Society (2000). All Rights Reserved. 820 This document and translations of it may be copied and furnished to 821 others, and derivative works that comment on or otherwise explain 822 it or assist in its implementation may be prepared, copied, 823 published and distributed, in whole or in part, without restriction 824 of any kind, provided that the above copyright notice and this 825 paragraph are included on all such copies and derivative works. 826 However, this document itself may not be modified in any way, such 827 as by removing the copyright notice or references to the Internet 828 Society or other Internet organizations, except as needed for the 829 purpose of developing Internet standards in which case the 830 procedures for copyrights defined in the Internet Standards process 831 must be followed, or as required to translate it into languages 832 other than English. 834 The limited permissions granted above are perpetual and will not be 835 revoked by the Internet Society or its successors or assigns. 837 This document and the information contained herein is provided on 838 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 839 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 840 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 841 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 842 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.