idnits 2.17.1 draft-ietf-smime-ecc-05.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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. 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) == Missing Reference: 'FIPS 186-2' is mentioned on line 118, but not defined == Missing Reference: 'SEC3' is mentioned on line 393, but not defined -- Looks like a reference, but probably isn't: '0' on line 535 -- Looks like a reference, but probably isn't: '2' on line 536 == Missing Reference: 'FIPS' is mentioned on line 641, but not defined == Unused Reference: 'FIPS-180' is defined on line 588, but no explicit reference was found in the text == Unused Reference: 'LMQSV' is defined on line 610, but no explicit reference was found in the text == Unused Reference: 'MSG' is defined on line 618, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'PKI-ALG' -- Possible downref: Non-RFC (?) normative reference: ref. 'BON' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-186-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKI' ** Obsolete normative reference: RFC 2630 (ref. 'CMS') (Obsoleted by RFC 3369, RFC 3370) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE1363' -- Possible downref: Non-RFC (?) normative reference: ref. 'K' -- Possible downref: Non-RFC (?) normative reference: ref. 'LMQSV' ** Downref: Normative reference to an Informational RFC: RFC 2876 (ref. 'CMS-KEA') ** Obsolete normative reference: RFC 2633 (ref. 'MSG') (Obsoleted by RFC 3851) -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC2' Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Simon Blake-Wilson, Certicom Corp 2 draft-ietf-smime-ecc-05.txt Daniel R. L. Brown, Certicom Corp 3 Paul Lambert, Cosine Communications 4 7 May, 2001 Expires: 6 November, 2001 6 Use of ECC Algorithms in CMS 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. Internet-Drafts are 12 working documents of the Internet Engineering Task Force (IETF), 13 its areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet-Drafts 19 as reference material or to cite them other than as "work in 20 progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This document describes how to use Elliptic Curve Cryptography 31 (ECC) public-key algorithms in the Cryptographic Message Syntax 32 (CMS). The ECC algorithms support the creation of digital 33 signatures and the exchange of keys to encrypt or authenticate 34 content. The definition of the algorithm processing is based on 35 the ANSI X9.62 standard, developed by the ANSI X9F1 working group, 36 and the IEEE 1363 standard and the SEC 1 standard. 38 The readers attention is called to the Intellectual Property Rights 39 section at the end of this document. 41 Table of Contents 43 1 Introduction ........................................ 3 44 1.1 Requirements terminology ....................... 3 45 2 SignedData using ECC ................................ 3 46 2.1 SignedData using ECDSA ......................... 3 47 2.1.1 Fields of the SignedData ................ 3 48 2.1.2 Actions of the sending agent ............ 4 49 2.1.3 Actions of the receiving agent .......... 4 50 3 EnvelopedData using ECC ............................. 5 51 3.1 EnvelopedData using ECDH ....................... 5 52 3.1.1 Fields of KeyAgreeRecipientInfo ......... 5 53 3.1.2 Actions of the sending agent ............ 6 54 3.1.3 Actions of the receiving agent .......... 6 55 3.2 EnvelopedData using 1-Pass ECMQV ............... 6 56 3.2.1 Fields of KeyAgreeRecipientInfo ......... 7 57 3.2.2 Actions of the sending agent ............ 7 58 3.2.3 Actions of the receiving agent .......... 8 59 4 AuthenticatedData using ECC ............ ............ 8 60 4.1 AuthenticatedData using 1-pass ECMQV ........... 8 61 4.1.1 Fields of KeyAgreeRecipientInfo ......... 8 62 4.1.2 Actions of the sending agent ............ 8 63 4.1.3 Actions of the receiving agent .......... 9 64 5 Recommended Algorithms and Elliptic Curves .......... 9 65 6 Certificates using ECC .............................. 9 66 7 SMIMECapabilities Attribute and ECC ................. 9 67 8 ASN.1 Syntax ........................................ 10 68 8.1 Algorithm identifiers .......................... 10 69 8.2 Other syntax ................................... 11 70 9 Summary ............................................. 13 71 References ............................................. 13 72 Security Considerations ................................ 14 73 Intellectual Property Rights ........................... 14 74 Acknowledgments ........................................ 15 75 Authors' Addresses ..................................... 15 76 Full Copyright Statement ............................... 16 78 1 Introduction 80 The Cryptographic Message Syntax (CMS) is cryptographic algorithm 81 independent. This specification defines a standard profile for the 82 use of Elliptic Curve Cryptography (ECC) public key algorithms in 83 the CMS. The ECC algorithms are incorporated into the following 84 CMS content types: 86 - 'SignedData' to support ECC-based digital signature methods 87 (ECDSA) to sign content 89 - 'EnvelopedData' to support ECC-based public-key agreement 90 methods (ECDH and ECMQV) to generate pairwise key-encryption 91 keys to encrypt content-encryption keys used for content 92 encryption 94 - 'AuthenticatedData' to support ECC-based public-key agreement 95 methods (ECMQV) to generate pairwise key-encryption keys to 96 encrypt MAC keys used for content authentication and integrity 98 Certification of EC public keys is also described to provide 99 public-key distribution in support of the specified techniques. 101 1.1 Requirements terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 105 this document are to be interpreted as described in RFC 2119 106 [MUST]. 108 2 SignedData using ECC 110 This section describes how to use ECC algorithms with the CMS 111 SignedData format to sign data. 113 2.1 SignedData using ECDSA 115 This section describes how to use the Elliptic Curve Digital 116 Signature Algorithm (ECDSA) with SignedData. ECDSA is specified in 117 [X9.62]. The method is the elliptic curve analog of the 118 Digital Signature Algorithm (DSA) [FIPS 186-2]. 120 In an implementation that uses ECDSA with CMS SignedData, the 121 following techniques and formats MUST be used. 123 2.1.1 Fields of the SignedData 125 When using ECDSA with SignedData the fields of SignerInfo are as in 126 [CMS], but with the following restrictions: 128 digestAlgorithm MUST contain the algorithm identifier sha-1 (see 129 Section 8.1) which identifies the SHA-1 hash algorithm. 130 signatureAlgorithm contains the algorithm identifier 131 ecdsa-with-SHA1 (see Section 8.1) which identifies the ECDSA 132 signature algorithm. 134 signature MUST contain the DER encoding (as an octet string) of 135 a value of the ASN.1 type ECDSA-Sig-Value (see Section 8.2). 137 When using ECDSA, the SignedData certificates field MAY include the 138 certificate(s) for the EC public key(s) used in the generation of 139 the ECDSA signatures in SignedData. ECC certificates are discussed 140 in Section 6. 142 2.1.2 Actions of the sending agent 144 When using ECDSA with SignedData, the sending agent uses the 145 message digest calculation process and signature generation process 146 for SignedData that are specified in [CMS]. To sign data, the 147 sending agent uses the signature method specified in [X9.62, 148 Section 5.3] with the following exceptions: 150 - In [X9.62, Section 5.3.1], the integer "e" is instead 151 determined by converting the message digest generated 152 according to [CMS, Section 5.4] to an integer using the data 153 conversion method in [X9.62, Section 4.3.2]. 155 The sending agent encodes the resulting signature using the 156 ECDSA-Sig-Value syntax (see Section 8.2) and places it in the 157 SignerInfo signature field. 159 2.1.3 Actions of the receiving agent 161 When using ECDSA with SignedData, the receiving agent uses the 162 message digest calculation process and signature verification 163 process for SignedData that are specified in [CMS]. To verify 164 SignedData, the receiving agent uses the signature verification 165 method specified in [X9.62, Section 5.4] with the following 166 exceptions: 168 - In [X9.62, Section 5.4.1] the integer "e'" is instead 169 determined by converting the message digest generated 170 according to [CMS, Section 5.4] to an integer using the data 171 conversion method in [X9.62, Section 4.3.2]. 173 In order to verify the signature, the receiving agent retrieves the 174 integers r and s from the SignerInfo signature field of the 175 received message. 177 3 EnvelopedData using ECC Algorithms 179 This section describes how to use ECC algorithms with the CMS 180 EnvelopedData format. 182 3.1 EnvelopedData using (ephemeral-static) ECDH 184 This section describes how to use ephemeral-static Elliptic Curve 185 Diffie-Hellman (ECDH) key agreement algorithm with EnvelopedData. 186 Ephemeral-static ECDH is specified in [SEC1] and [IEEE1363]. 187 Ephemeral-static ECDH is the the elliptic curve analog of the 188 ephemeral-static Diffie-Hellman key agreement algorithm specified 189 jointly in the documents [CMS, Section 12.3.1.1] and [CMS-DH]. 191 In an implementation that uses ECDH with CMS EnvelopedData with key 192 agreement, the following techniques and formats MUST be used. 194 3.1.1 Fields of KeyAgreeRecipientInfo 196 When using ephemeral-static ECDH with EnvelopedData, the fields of 197 KeyAgreeRecipientInfo are as in [CMS], but with the following 198 restrictions: 200 originator MUST be the alternative originatorKey. The 201 originatorKey algorithm field MUST contain the id-ecPublicKey 202 object identifier (see Section 8.1) with NULL parameters. The 203 originatorKey publicKey field MUST contain the DER-encoding of a 204 value of the ASN.1 type ECPoint (see Section 8.2), which 205 represents the sending agent's ephemeral EC public key. 207 keyEncryptionAlgorithm MUST contain the 208 dhSinglePass-stdDH-sha1kdf-scheme object identifier (see Section 209 8.1) if standard ECDH primitive is used, or the 210 dhSinglePass-cofactorDH-sha1kdf-scheme object identifier (see 211 Section 8.1) if the cofactor ECDH primitive is used. The 212 parameters field contains KeyWrapAlgorithm. The 213 KeyWrapAlgorithm is the algorithm identifier that indicates the 214 symmetric encryption algorithm used to encrypt the CEK with the 215 KEK. 217 3.1.2 Actions of the sending agent 219 When using ephemeral-static ECDH with EnvelopedData, the sending 220 agent first obtains the recipient's EC public key and domain 221 parameters (e.g. from the recipient's certificate). The sending 222 agent then determines an integer "keydatalen", which is the 223 KeyWrapAlgorithm symmetric key-size in bits, and also a bit string 224 "SharedInfo", which is the DER encoding of ECC-CMS-SharedInfo (see 225 Section 8.2). The sending agent then performs the key deployment 226 and the key agreement operation of the Elliptic Curve 227 Diffie-Hellman Scheme specified in [SEC1, Section 6.1]. As a 228 result the sending agent obtains: 230 - an ephemeral public key, which is represented as a value of 231 the type ECPoint (see Section 8.2), encapsulated in a bit 232 string and placed in the KeyAgreeRecipientInfo originator 233 field, and 235 - a shared secret bit string "K" which is used as the pairwise 236 key-encryption key for that recipient, as specified in [CMS]. 238 3.1.3 Actions of the receiving agent 240 When using ephemeral-static ECDH with EnvelopedData, the receiving 241 agent determines the bit string "SharedInfo", which is the DER 242 encoding of ECC-CMS-SharedInfo (see Section 8.2), and the integer 243 "keydatalen" from the key-size, in bits, of the KeyWrapAlgorithm. 244 The receiving agent retrieves the ephemeral EC public key from the 245 bit string KeyAgreeRecipientInfo originator, which an value of the 246 type ECPoint (see Section 8.2) encapsulated as a bit string. The 247 receiving agent performs the key agreement operation of the 248 Elliptic Curve Diffie-Hellman Scheme specified in [SEC1, Section 249 6.1]. As a result the receiving agent obtains a shared secret bit 250 string "K" which is used as the pairwise key-encryption key to 251 unwrap the CEK. 253 3.2 EnvelopedData using 1-Pass ECMQV 255 This section describes how to use the 1-Pass elliptic curve MQV 256 (ECMQV) key agreement algorithm with EnvelopedData. ECMQV is 257 specified in [SEC1] and [IEEE1363]. Like the KEA algorithm 258 [CMS-KEA], 1-Pass ECMQV uses three key pairs: an ephemeral key 259 pair, a static key pair of the sending agent, and a static key pair 260 of the receiving agent. An advantage of using 1-Pass ECMQV is that 261 it can be used with both EnvelopedData and AuthenticatedData. 263 In an implementation that uses 1-Pass ECMQV with CMS EnvelopedData 264 with key agreement, the following techniques and formats MUST be 265 used. 267 3.2.1 Fields of KeyAgreeRecipientInfo 269 When using 1-Pass ECMQV with EnvelopedData the fields of 270 KeyAgreeRecipientInfo are: 272 originator identifies the static EC public key of the sender. 273 It SHOULD be the one of the alternatives issuerAndSerialNumber 274 or subjectKeyIdentifier and point to one of the sending agent's 275 certificates. 277 ukm MUST be present. The ukm field MUST contain an octet string 278 which is the DER encoding of the type MQVuserKeyingMaterial (see 279 Section 8.2). The MQVuserKeyingMaterial ephemeralPublicKey 280 algorithm field MUST contain the id-ecPublicKey object 281 identifier (see Section 8.1) with NULL parameters field. The 282 MQVuserKeyingMaterial ephemeralPublicKey publicKey field MUST 283 contain the DER-encoding of the ASN.1 type ECPoint (see Section 284 8.2) representing sending agent's ephemeral EC public key. The 285 MQVuserKeyingMaterial addedukm field, if present, SHOULD contain 286 an octet string of additional user keying material of the 287 sending agent. 289 keyEncryptionAlgorithm MUST be the mqvSinglePass-sha1kdf-scheme 290 algorithm identifier (see Section 8.1), with parameters field 291 KeyWrapAlgorithm. The KeyWrapAlgorithm indicates the symmetric 292 encryption algorithm used to encrypt the CEK with the KEK 293 generated using the 1-Pass ECMQV algorithm. 295 3.2.2 Actions of the sending agent 297 When using 1-Pass ECMQV with EnvelopedData, the sending agent first 298 obtains the recipient's EC public key and domain parameters, 299 (e.g. from the recipient's certificate) and checks that the domain 300 parameters are the same. The sending agent then determines an 301 integer "keydatalen", which is the KeyWrapAlgorithm symmetric 302 key-size in bits, and also a bit string "SharedInfo", which is the 303 DER encoding of ECC-CMS-SharedInfo (see Section 8.2). The sending 304 agent then performs the key deployment and key agreement operations 305 of the Elliptic Curve MQV Scheme specified in [SEC1, Section 6.2]. 306 As a result the sending agent obtains 308 - an ephemeral public key, which is represented as a value of 309 type ECPoint (see Section 8.2), encapsulated in a bit string, 310 placed in an MQVuserKeyingMaterial ephemeralPublicKey 311 publicKey field (see Section 8.2), and 313 - a shared secret bit string "K" which is used as the pairwise 314 key-encryption key for that recipient, as specified in [CMS]. 316 The ephemeral public key can be re-used with an AuthenticatedData 317 for greater efficiency. 319 3.2.3 Actions of the receiving agent 321 When using 1-Pass ECMQV with EnvelopedData, the receiving agent 322 determines the bit string "SharedInfo", which is the DER encoding 323 of ECC-CMS-SharedInfo (see Section 8.2), and the integer 324 "keydatalen" from the key-size, in bits, of the KeyWrapAlgorithm. 325 The receiving agent then retrieves the static and ephemeral EC 326 public keys of the originator, from the originator and ukm fields 327 as described in Section 3.2.1, and its static EC public key 328 identified in the rid field and checks that the domain parameters 329 are the same. The receiving agent then performs the key agreement 330 operation of the Elliptic Curve MQV Scheme [SEC1, Section 6.2]. As 331 a result the receiving agent obtains a shared secret bit string "K" 332 which is used as the pairwise key-encryption key to unwrap the CEK. 334 4 AuthenticatedData using ECC 336 This section describes how to use ECC algorithms with the CMS 337 AuthenticatedData format. AuthenticatedData lacks non-repudiation, 338 and so in some instances is preferable to SignedData. (For 339 example, the sending agent might not want the message to be 340 authenticated when forwarded.) 342 4.1 AuthenticatedData using 1-pass ECMQV 344 This section describes how to use the 1-Pass elliptic curve MQV 345 (ECMQV) key agreement algorithm with AuthenticatedData. ECMQV is 346 specified in [SEC1]. An advantage of using 1-Pass ECMQV is that it 347 can be used with both EnvelopedData and AuthenticatedData. 349 4.1.1 Fields of the KeyAgreeRecipientInfo 351 The AuthenticatedData KeyAgreeRecipientInfo fields are used in the 352 same manner as the fields for the corresponding EnvelopedData 353 KeyAgreeRecipientInfo fields of Section 3.2.1 of this document. 355 4.1.2 Actions of the sending agent 357 The sending agent uses the same actions as for EnvelopedData 358 with 1-Pass ECMQV, as specified in Section 3.2.2 of this document. 360 The ephemeral public key can be re-used with an EnvelopedData for 361 greater efficiency. 363 Note: if there are multiple recipients then an attack is possible 364 where one recipient modifies the content without other recipients 365 noticing [BON]. A sending agent who is concerned with such an 366 attack SHOULD use a separate AuthenticatedData for each recipient. 368 4.1.3 Actions of the receiving agent 370 The receiving agent uses the same actions as for EnvelopedData 371 with 1-Pass ECMQV, as specified in Section 3.2.3 of this document. 373 Note: see Note in Section 4.1.2. 375 5 Recommended Algorithms and Elliptic Curves 377 Implementations of this specification MUST implement either 378 SignedData with ECDSA or EnvelopedData with ephemeral-static ECDH. 379 Implementations of this specification SHOULD implement both 380 SignedData with ECDSA and EnvelopedData with ephemeral-static ECDH. 381 Implementations MAY implement the other techniques specified, such 382 as AuthenticatedData and 1-Pass ECMQV. 384 Furthermore, in order to encourage interoperability, 385 implementations SHOULD use the elliptic curve domain parameters 386 specified by ANSI [X9.62], NIST [FIPS-186-2] and SECG [SEC2]. 388 6 Certificates using ECC 390 Internet X.509 certificates [PKI] can be used in conjunction with 391 this specification to distribute agents' public keys. The use of 392 ECC algorithms and keys within X.509 certificates is specified in 393 [PKI-ALG]. More details can be found in [SEC3]. 395 7 SMIMECapabilities Attribute and ECC 397 A sending agent MAY announce to receiving agents that it supports 398 one or more of the ECC algorithms in this document by using the 399 SMIMECapabilities signed attribute [MSG, Section 2.5.2]. 401 The SMIMECapability value to indicate support for the ECDSA 402 signature algorithm is the SEQUENCE with the capabilityID field 403 containing the object identifier ecdsa-with-SHA1 with NULL 404 parameters. The DER encoding is: 406 30 0b 06 07 2a 86 48 ce 3d 04 01 05 00 408 The SMIMECapability capabilityID object identifiers for the 409 supported key agreement algorithms in this document are 410 dhSinglePass-stdDH-sha1kdf-scheme, 411 dhSinglePass-cofactorDH-sha1kdf-scheme, and 412 mqvSinglePass-sha1kdf-scheme. For each of these SMIMECapability 413 SEQUENCEs the parameters field is present and indicates the 414 supported key-encryption algorithm with the KeyWrapAlgorithm 415 algorithm identifier. The DER encodings that indicate capability 416 of the three key agreement algorithms with CMS Triple-DES key wrap 417 are: 419 30 1c 06 09 2b 81 05 10 86 48 3f 00 02 30 0f 06 420 0b 2a 86 48 86 f7 0d 01 09 10 03 06 05 00 422 for ephemeral-static ECDH, 424 30 1c 06 09 2b 81 05 10 86 48 3f 00 03 30 0f 06 425 0b 2a 86 48 86 f7 0d 01 09 10 03 06 05 00 427 for ephemeral-static ECDH with cofactor method, and 429 30 1c 06 09 2b 81 05 10 86 48 3f 00 10 30 0f 06 430 0b 2a 86 48 86 f7 0d 01 09 10 03 06 05 00 432 for ECMQV. 434 8 ASN.1 Syntax 436 The ASN.1 syntax that is used in this document is gathered together 437 in this section for reference purposes. 439 8.1 Algorithm identifiers 441 The algorithm identifiers used in this document are taken from 442 [X9.62], [SEC1] and [SEC2]. 444 The following object identifier indicates the hash algorithm used 445 in this document: 447 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 448 oiw(14) secsig(3) algorithm(2) 26 } 450 The following object identifier is used in this document to 451 indicate an elliptic curve public key: 453 id-ecPublicKey OBJECT IDENTIFIER ::= { ansi-x9-62 keyType(2) 1 } 455 where 457 ansi-x9-62 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 458 10045 } 460 When the object identifier id-ecPublicKey is used here with an 461 algorithm identifier, the associated parameters contain NULL. 463 The following object identifier indicates the digital signature 464 algorithm used in this document: 466 ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { ansi-x9-62 signatures(4) 467 1 } 469 When the object identifier ecdsa-with-SHA1 is used within an 470 algorithm identifier, the associated parameters field contains 471 NULL. 473 The following object identifiers indicate the key agreement 474 algorithms used in this document: 476 dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 477 x9-63-scheme 2} 479 dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 480 x9-63-scheme 3} 482 mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= { 483 x9-63-scheme 16} 485 where 487 x9-63-scheme OBJECT IDENTIFIER ::= { iso(1) 488 identified-organization(3) tc68(133) country(16) x9(840) 489 x9-63(63) schemes(0) } 491 When the object identifiers are used here within an algorithm 492 identifier, the associated parameters field contains the CMS 493 KeyWrapAlgorithm algorithm identifier. 495 8.2 Other syntax 497 The following additional syntax is used here. 499 When using ECDSA with SignedData, ECDSA signatures are encoded 500 using the type: 502 ECDSA-Sig-Value ::= SEQUENCE { 503 r INTEGER, 504 s INTEGER } 506 ECDSA-Sig-Value is specified in [X9.62]. Within CMS, 507 ECDSA-Sig-Value is DER-encoded and placed within a signature field 508 of SignedData. 510 When using ECDH and ECMQV with EnvelopedData and AuthenticatedData, 511 ephemeral and static public keys are encoded using the type 512 ECPoint. 514 ECPoint ::= OCTET STRING 516 When using ECMQV with EnvelopedData and AuthenticatedData, the 517 sending agent's ephemeral public key and additional keying material 518 are encoded using the type: 520 MQVuserKeyingMaterial ::= SEQUENCE { 521 ephemeralPublicKey OriginatorPublicKey, 522 addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL } 524 The ECPoint syntax in used to represent the ephemeral public key 525 and placed in the ephemeralPublicKey field. The additional user 526 keying material is place in the addedukm field. Then the 527 MQVuserKeyingMaterial value is DER-encoded and placed within in a 528 ukm field of EnvelopedData or AuthenticatedData. 530 When using ECDH or ECMQV with EnvelopedData or AuthenticatedData, 531 the key-encryption keys are derived by using the type: 533 ECC-CMS-SharedInfo ::= SEQUENCE { 534 keyInfo AlgorithmIdentifier, 535 entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL, 536 suppPubInfo [2] EXPLICIT OCTET STRING } 538 The fields of ECC-CMS-SharedInfo are as follows: 540 keyInfo contains the object identifier of the key-encryption 541 algorithm (used to wrap the CEK) and NULL parameters. 543 entityUInfo optionally contains additional keying material 544 supplied by the sending agent. When used with ECDH and CMS, the 545 entityUInfo field contains the octet string ukm. When used with 546 ECMQV and CMS, the entityUInfo contains the octet string 547 addedukm (encoded in MQVuserKeyingMaterial). 549 suppPubInfo contains the length of the generated KEK, in bits, 550 represented as a 32 bit number, as in [CMS-DH]. (E.g. for 3DES 551 it would be 00 00 00 c0.) 553 Within CMS, ECC-CMS-SharedInfo is DER-encoded and used as input to 554 the key derivation function, as specified in [SEC1, Section 3.6.1]. 555 Note that ECC-CMS-SharedInfo differs from the OtherInfo specified 556 in [CMS-DH]. Here a counter value is not included in the keyInfo 557 field because the key derivation function specified in [SEC1, 558 Section 3.6.1] ensures that sufficient keying data is provided. 560 9 Summary 562 This document specifies how to use ECC algorithms with the S/MIME 563 CMS. Use of ECC algorithm within CMS can result in reduced 564 processing requirements for S/MIME agents, and reduced bandwidth 565 for CMS messages. 567 References 569 [X9.62] ANSI X9.62-1998, "Public Key Cryptography For The 570 Financial Services Industry: The Elliptic Curve 571 Digital Signature Algorithm (ECDSA)", American 572 National Standards Institute, 1999. 574 [PKI-ALG] L. Bassham, R. Housley and W. Polk, "Algorithms and 575 Identifiers for the Internet X.509 Public Key 576 Infrastructure Certificate and CRL profile", PKIX 577 Working Group Internet-Draft, November 2000. 579 [BON] D. Boneh, "The Security of Multicast MAC", 580 Presentation at Selected Areas of Cryptography 2000, 581 Center for Applied Cryptographic Research, University 582 of Waterloo, 2000. Paper version available from 583 http://crypto.stanford.edu/~dabo/papers/mmac.ps 585 [MUST] S. Bradner, "Key Words for Use in RFCs to Indicate 586 Requirement Levels", RFC 2119, March 1997. 588 [FIPS-180] FIPS 180-1, "Secure Hash Standard", National Institute 589 of Standards and Technology, April 17, 1995. 591 [FIPS-186-2] FIPS 186-2, "Digital Signature Standard", National 592 Institute of Standards and Technology, 15 February 593 2000. 595 [PKI] W. Ford, R. Housley, W. Polk and D. Solo, "Internet X.509 596 Public Key Infrastructure Certificate and CRL 597 Profile", PKIX Working Group Internet-Draft, January 598 2001. 600 [CMS] R. Housley, "Cryptographic Message Syntax", RFC 2630, 601 June 1999. 603 [IEEE1363] IEEE P1363, "Standard Specifications for Public Key 604 Cryptography", Institute of Electrical and Electronics 605 Engineers, 2000. 607 [K] B. Kaliski, "MQV Vulnerabilty", Posting to ANSI X9F1 608 and IEEE P1363 newsgroups, 1998. 610 [LMQSV] L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone, 611 "An efficient protocol for authenticated key agreement", 612 Technical report CORR 98-05, University of Waterloo, 613 1998. 615 [CMS-KEA] J. Pawling, "CMS KEA and SKIPJACK Conventions", RFC 616 2876, July 2000. 618 [MSG] B. Ramsdell, "S/MIME Version 3 Message Specification", 619 RFC 2633, June 1999. 621 [CMS-DH] E. Rescorla, "Diffie-Hellman Key Agreement Method", 622 RFC 2631, June 1999. 624 [SEC1] SECG, "Elliptic Curve Cryptography", Standards for 625 Efficient Cryptography Group, 2000. 627 [SEC2] SECG, "Recommended Elliptic Curve Domain Parameters", 628 Standards for Efficient Cryptography Group, 2000. 630 Security Considerations 632 This specification is based on [CMS], [X9.62] and [SEC1] and the 633 appropriate security considerations of those documents apply. 635 In addition, implementors of AuthenticatedData should be aware of 636 the concerns expressed in [BON] when using AuthenticatedData to 637 send messages to more than one recipient. Also, users of MQV 638 should be aware of the vulnerability in [K]. 640 When 256, 384, and 512 bit hash functions succeed SHA-1 in future 641 revisions of [FIPS], [FIPS-186-2], [X9.62] and [SEC1], then they 642 can similarly succeed SHA-1 in a future revision of this document. 644 Intellectual Property Rights 646 The IETF has been notified of intellectual property rights claimed 647 in regard to the specification contained in this document. For 648 more information, consult the online list of claimed rights 649 (http://www.ietf.org/ipr.html). 651 The IETF takes no position regarding the validity or scope of any 652 intellectual property or other rights that might be claimed to 653 pertain to the implementation or use of the technology described in 654 this document or the extent to which any license under such rights 655 might or might not be available; neither does it represent that it 656 has made any effort to identify any such rights. Information on the 657 IETF's procedures with respect to rights in standards-track and 658 standards-related documentation can be found in BCP-11. Copies of 659 claims of rights made available for publication and any assurances 660 of licenses to be made available, or the result of an attempt made 661 to obtain a general license or permission for the use of such 662 proprietary rights by implementors or users of this specification 663 can be obtained from the IETF Secretariat. 665 Acknowledgments 667 The methods described in this document are based on work done by 668 the ANSI X9F1 working group. The authors wish to extend their 669 thanks to ANSI X9F1 for their assistance. The authors also wish to 670 thank Peter de Rooij for his patient assistance. The technical 671 comments of Francois Rousseau were valuable contributions. 673 Authors' Addresses 675 Simon Blake-Wilson 676 Certicom Corp 677 5520 Explorer Drive #400 678 Mississauga, ON L4W 5L1 680 e-mail: sblakewi@certicom.com 682 Daniel R. L. Brown 683 Certicom Corp 684 5520 Explorer Drive #400 685 Mississauga, ON L4W 5L1 687 e-mail: dbrown@certicom.com 689 Paul Lambert 690 Director of Security Applications 691 CoSine Communications 692 1200 Bridge Parkway 693 Redwood City, CA, 94065 694 http://www.cosinecom.com 696 e-mail: plambert@cosinecom.com 698 Full Copyright Statement 700 Copyright (C) The Internet Society (2001). All Rights Reserved. 702 This document and translations of it may be copied and furnished to 703 others, and derivative works that comment on or otherwise explain 704 it or assist in its implementation may be prepared, copied, 705 published and distributed, in whole or in part, without restriction 706 of any kind, provided that the above copyright notice and this 707 paragraph are included on all such copies and derivative works. 708 However, this document itself may not be modified in any way, such 709 as by removing the copyright notice or references to the Internet 710 Society or other Internet organizations, except as needed for the 711 purpose of developing Internet standards in which case the 712 procedures for copyrights defined in the Internet Standards process 713 must be followed, or as required to translate it into languages 714 other than English. 716 The limited permissions granted above are perpetual and will not be 717 revoked by the Internet Society or its successors or assigns. 719 This document and the information contained herein is provided on 720 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 721 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 722 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 723 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 724 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.