idnits 2.17.1 draft-ietf-smime-3278bis-00.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 1606. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1617. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1624. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1630. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC3278, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 3, 2008) is 5798 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 1451 -- Looks like a reference, but probably isn't: '2' on line 1452 == Missing Reference: 'NISTSP800-57' is mentioned on line 900, but not defined == Unused Reference: 'MSG' is defined on line 984, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 S/MIME WG Sean Turner, IECA 2 Internet Draft Dan Brown, Certicom 3 Intended Status: Informational June 3, 2008 4 Obsoletes: 3278 (once approved) 5 Expires: December 3, 2008 7 Use of Elliptic Curve Cryptography (ECC) Algorithms 8 in Cryptographic Message Syntax (CMS) 9 draft-ietf-smime-3278bis-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on December 3, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document describes how to use Elliptic Curve Cryptography (ECC) 43 public-key algorithms in the Cryptographic Message Syntax (CMS). The 44 ECC algorithms support the creation of digital signatures and the 45 exchange of keys to encrypt or authenticate content. The definition 46 of the algorithm processing is based on the ANSI X9.62 standard, 47 developed by the ANSI X9F1 working group, the IEEE 1363 standard, and 48 the SEC 1 standard. 50 Discussion 52 This draft is being discussed on the 'ietf-smime' mailing list. To 53 subscribe, send a message to ietf-smime-request@imc.org with the 54 single word subscribe in the body of the message. There is a Web site 55 for the mailing list at . 57 Table of Contents 59 1. Introduction...................................................3 60 1.1. Requirements Terminology..................................3 61 1.2. Changes since RFC 3278....................................3 62 2. SignedData using ECC...........................................4 63 2.1. SignedData using ECDSA....................................4 64 2.1.1. Fields of the SignedData.............................5 65 2.1.2. Actions of the sending agent.........................5 66 2.1.3. Actions of the receiving agent.......................6 67 3. EnvelopedData using ECC Algorithms.............................6 68 3.1. EnvelopedData using (ephemeral-static) ECDH...............6 69 3.1.1. Fields of KeyAgreeRecipientInfo......................6 70 3.1.2. Actions of the sending agent.........................7 71 3.1.3. Actions of the receiving agent.......................7 72 3.2. EnvelopedData using 1-Pass ECMQV..........................7 73 3.2.1. Fields of KeyAgreeRecipientInfo......................8 74 3.2.2. Actions of the sending agent.........................8 75 3.2.3. Actions of the receiving agent.......................9 76 4. AuthenticatedData using ECC....................................9 77 4.1. AuthenticatedData using 1-pass ECMQV......................9 78 4.1.1. Fields of the KeyAgreeRecipientInfo.................10 79 4.1.2. Actions of the sending agent........................10 80 4.1.3. Actions of the receiving agent......................10 81 5. Recommended Algorithms and Elliptic Curves....................10 82 6. Certificates using ECC........................................11 83 7. SMIMECapabilities Attribute and ECC...........................12 84 8. ASN.1 Syntax..................................................14 85 8.1. Algorithm Identifiers....................................14 86 8.2. Other Sytnax.............................................17 87 9. Security Considerations.......................................18 88 10. IANA Considerations..........................................22 89 11. References...................................................22 90 11.1. Normative...............................................22 91 11.2. Informative.............................................23 93 Annex A ASN.1 Modules............................................25 94 Annex A.1 1988 ASN.1 Module...................................25 95 Annex A.2 2004 ASN.1 Module...................................25 97 1. Introduction 99 The Cryptographic Message Syntax (CMS) is cryptographic algorithm 100 independent. This specification defines a profile for the use of 101 Elliptic Curve Cryptography (ECC) public key algorithms in the CMS. 102 The ECC algorithms are incorporated into the following CMS content 103 types: 105 - 'SignedData' to support ECC-based digital signature methods 106 (ECDSA) to sign content 108 - 'EnvelopedData' to support ECC-based public-key agreement 109 methods (ECDH and ECMQV) to generate pairwise key-encryption 110 keys to encrypt content-encryption keys used for content 111 encryption 113 - 'AuthenticatedData' to support ECC-based public-key agreement 114 methods (ECMQV) to generate pairwise key-encryption keys to 115 encrypt MAC keys used for content authentication and integrity. 117 Certification of EC public keys is also described to provide public- 118 key distribution in support of the specified techniques. 120 1.1. Requirements Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [MUST]. 126 1.2. Changes since RFC 3278 128 The following summarizes the changes: 130 - Paragraph 2.1 added sentence indicating SHA is used with EDSA. 132 - Paragraph 2.1.1 limited the digest algorithm to SHA-1. This 133 document expands the allowed algorithms to SHA-224, SHA-256, SHA- 134 384, and SHA-512. 136 - Paragraph 3.1.1 used SHA1 in the KDF with ECDH std and cofactor 137 methods. This document expands the set of allowed algorithms by 138 adding SHA-224, SHA-256, SHA-384, and SHA-512. 140 - Paragraph 3.2.1 used SHA1 in the KDF with ECMQV. This document 141 expands the set of allowed algorithms by adding SHA-224, SHA-256, 142 SHA-384, and SHA-512. 144 - Paragraph 5 is updated to include requirements for hash algorithms 145 and recommendations for matching curves and hash algorithms. It 146 also was expanded to indicate which ECDH and ECMQV variants are 147 required. 149 - Paragraph 7 is updated to include S/MIME capabilities for ECDSA 150 with SHA-224, SHA-256, SHA-384, and SHA-512. It was also updated 151 to include S/MIME capabilities for ECDH and ECMQV using SHA2 152 algorithms as the KDF. 154 - Paragraph 8.1 listed the algorithm identifiers for SHA-1 and SHA-1 155 with ECDSA. This document adds algorithm identifiers for SHA-224, 156 SHA-256, SHA-384, and SHA-512 as well as SHA-224, SHA-256, SHA- 157 384, and SHA-512 with ECDSA. This document also updates the list 158 of algorithm identifiers for ECDH std, ECDH cofactor, and ECMQV 159 with SHA2 algorithms as the KDF. 161 - Deleted summary paragraph. 163 - Updated references. 165 - Updated security considerations. Security considerations paragraph 166 referring to definitions of SHA-224, SHA-256, SHA-384, and SHA- 167 512 is deleted. 169 - Added ASN.1 modules. 171 - Updated acknowledgements section. 173 2. SignedData using ECC 175 This section describes how to use ECC algorithms with the CMS 176 SignedData format to sign data. 178 2.1. SignedData using ECDSA 180 This section describes how to use the Elliptic Curve Digital 181 Signature Algorithm (ECDSA) with SignedData. ECDSA is specified in 182 [X9.62]. The method is the elliptic curve analog of the Digital 183 Signature Algorithm (DSA) [DSS]. ECDSA is used with the Secure Hash 184 Algorithm (SHA) [SHS]. 186 In an implementation that uses ECDSA with CMS SignedData, the 187 following techniques and formats MUST be used. 189 2.1.1. Fields of the SignedData 191 When using ECDSA with SignedData, the fields of SignerInfo are as in 192 [CMS], but with the following restrictions: 194 digestAlgorithm MUST contain the algorithm identifier of the hash 195 algorithm (see Section 8.1) which MUST be one of the following: 196 id-sha1 identifies the SHA-1 hash algorithm, id-sha224 identifies 197 the SHA-224 hash algorithm, id-sha256 identifies the SHA-256 hash 198 algorithm, id-sha384 identifies the SHA-384 algorithm, and id- 199 sha512 identifies the SHA-512 algorithm. 201 signatureAlgorithm contains the signature algorithm identifier 202 (see Section 8.1): ecdsa-with-SHA1, ecdsa-with-SHA224, ecdsa- 203 with-SHA256, ecdsa-with-SHA384, or ecdsa-with-SHA512. 205 signature MUST contain the DER encoding (as an octet string) of a 206 value of the ASN.1 type ECDSA-Sig-Value (see Section 8.2). 208 When using ECDSA, the SignedData certificates field MAY include the 209 certificate(s) for the EC public key(s) used in the generation of the 210 ECDSA signatures in SignedData. ECC certificates are discussed in 211 Section 6. 213 2.1.2. Actions of the sending agent 215 When using ECDSA with SignedData, the sending agent uses the message 216 digest calculation process and signature generation process for 217 SignedData that are specified in [CMS]. To sign data, the sending 218 agent uses the signature method specified in [X9.62, Section 5.3] 219 with the following exceptions: 221 - In [X9.62, Section 5.3.1], the integer "e" is instead determined 222 by converting the message digest generated according to [CMS, 223 Section 5.4] to an integer using the data conversion method in 224 [X9.62, Section 4.3.2]. 226 The sending agent encodes the resulting signature using the ECDSA- 227 Sig-Value syntax (see Section 8.2) and places it in the 228 SignerInfosignature field. 230 2.1.3. Actions of the receiving agent 232 When using ECDSA with SignedData, the receiving agent uses the 233 message digest calculation process and signature verification process 234 for SignedData that are specified in [CMS]. To verify SignedData, 235 the receiving agent uses the signature verification method specified 236 in [X9.62, Section 5.4] with the following exceptions: 238 - In [X9.62, Section 5.4.1] the integer "e'" is instead determined 239 by converting the message digest generated according to [CMS, 240 Section 5.4] to an integer using the data conversion method in 241 [X9.62, Section 4.3.2]. 243 In order to verify the signature, the receiving agent retrieves the 244 integers r and s from the SignerInfo signature field of the received 245 message. 247 3. EnvelopedData using ECC Algorithms 249 This section describes how to use ECC algorithms with the CMS 250 EnvelopedData format. 252 3.1. EnvelopedData using (ephemeral-static) ECDH 254 This section describes how to use the ephemeral-static Elliptic Curve 255 Diffie-Hellman (ECDH) key agreement algorithm with EnvelopedData. 256 Ephemeral-static ECDH is specified in [SEC1] and [IEEE1363]. 257 Ephemeral-static ECDH is the the elliptic curve analog of the 258 ephemeral-static Diffie-Hellman key agreement algorithm specified 259 jointly in the documents [CMS, Section 12.3.1.1] and [CMS-DH]. 261 In an implementation that uses ECDH with CMS EnvelopedData with key 262 agreement, the following techniques and formats MUST be used. 264 3.1.1. Fields of KeyAgreeRecipientInfo 266 When using ephemeral-static ECDH with EnvelopedData, the fields of 267 KeyAgreeRecipientInfo are as in [CMS], but with the following 268 restrictions: 270 originator MUST be the alternative originatorKey. The 271 originatorKey algorithm field MUST contain the id-ecPublicKey 272 object identifier (see Section 8.1) with NULL parameters. The 273 originatorKey publicKey field MUST contain the DER-encoding of a 274 value of the ASN.1 type ECPoint (see Section 8.2), which 275 represents the sending agent's ephemeral EC public key. 277 keyEncryptionAlgorithm MUST contain the key encryption algorithm 278 object identifier (see Section 8.1). The parameters field 279 contains KeyWrapAlgorithm. The KeyWrapAlgorithm is the algorithm 280 identifier that indicates the symmetric encryption algorithm used 281 to encrypt the content-encryption key (CEK) with the 282 key-encryption key (KEK). Algorithm requirements are found in 283 paragraph 5. 285 3.1.2. Actions of the sending agent 287 When using ephemeral-static ECDH with EnvelopedData, the sending 288 agent first obtains the recipient's EC public key and domain 289 parameters (e.g. from the recipient's certificate). The sending 290 agent then determines an integer "keydatalen", which is the 291 KeyWrapAlgorithm symmetric key-size in bits, and also a bit string 292 "SharedInfo", which is the DER encoding of ECC-CMS-SharedInfo (see 293 Section 8.2). The sending agent then performs the key deployment and 294 the key agreement operation of the Elliptic Curve Diffie-Hellman 295 Scheme specified in [SEC1, Section 6.1]. As a result the sending 296 agent obtains: 298 - an ephemeral public key, which is represented as a value of the 299 type ECPoint (see Section 8.2), encapsulated in a bit string and 300 placed in the KeyAgreeRecipientInfo originator field, and 302 - a shared secret bit string "K", which is used as the pairwise 303 key-encryption key for that recipient, as specified in [CMS]. 305 3.1.3. Actions of the receiving agent 307 When using ephemeral-static ECDH with EnvelopedData, the receiving 308 agent determines the bit string "SharedInfo", which is the DER 309 encoding of ECC-CMS-SharedInfo (see Section 8.2), and the integer 310 "keydatalen" from the key-size, in bits, of the KeyWrapAlgorithm. The 311 receiving agent retrieves the ephemeral EC public key from the bit 312 string KeyAgreeRecipientInfo originator, with a value of the type 313 ECPoint (see Section 8.2) encapsulated as a bit string. The 314 receiving agent performs the key agreement operation of the Elliptic 315 Curve Diffie-Hellman Scheme specified in [SEC1, Section 6.1]. As a 316 result, the receiving agent obtains a shared secret bit string "K", 317 which is used as the pairwise key-encryption key to unwrap the CEK. 319 3.2. EnvelopedData using 1-Pass ECMQV 321 This section describes how to use the 1-Pass elliptic curve MQV 322 (ECMQV) key agreement algorithm with EnvelopedData. ECMQV is 323 specified in [SEC1] and [IEEE1363]. Like the KEA algorithm [CMS- 324 KEA], 1-Pass ECMQV uses three key pairs: an ephemeral key pair, a 325 static key pair of the sending agent, and a static key pair of the 326 receiving agent. An advantage of using 1-Pass ECMQV is that it can 327 be used with both EnvelopedData and AuthenticatedData. 329 In an implementation that uses 1-Pass ECMQV with CMS EnvelopedData 330 with key agreement, the following techniques and formats MUST be 331 used. 333 3.2.1. Fields of KeyAgreeRecipientInfo 335 When using 1-Pass ECMQV with EnvelopedData, the fields of 336 KeyAgreeRecipientInfo are: 338 originator identifies the static EC public key of the sender. It 339 SHOULD be one of the alternatives, issuerAndSerialNumber or 340 subjectKeyIdentifier, and point to one of the sending agent's 341 certificates. 343 ukm MUST be present. The ukm field MUST contain an octet string 344 which is the DER encoding of the type MQVuserKeyingMaterial (see 345 Section 8.2). The MQVuserKeyingMaterial ephemeralPublicKey 347 algorithm field MUST contain the id-ecPublicKey object identifier 348 (see Section 8.1) with NULL parameters field. The 349 MQVuserKeyingMaterial ephemeralPublicKey publicKey field MUST 350 contain the DER-encoding of the ASN.1 type ECPoint (see Section 351 8.2) representing sending agent's ephemeral EC public key. The 352 MQVuserKeyingMaterial addedukm field, if present, SHOULD contain 353 an octet string of additional user keying material of the sending 354 agent. 356 keyEncryptionAlgorithm MUST be the key encryption algorithm 357 identifier (see Section 8.1), with the parameters field 358 KeyWrapAlgorithm. The KeyWrapAlgorithm indicates the symmetric 359 encryption algorithm used to encrypt the CEK with the KEK 360 generated using the 1-Pass ECMQV algorithm. Algorithm 361 requirements are found in paragraph 5. 363 3.2.2. Actions of the sending agent 365 When using 1-Pass ECMQV with EnvelopedData, the sending agent first 366 obtains the recipient's EC public key and domain parameters, (e.g. 367 from the recipient's certificate) and checks that the domain 368 parameters are the same. The sending agent then determines an 369 integer "keydatalen", which is the KeyWrapAlgorithm symmetric key- 370 size in bits, and also a bit string "SharedInfo", which is the DER 371 encoding of ECC-CMS-SharedInfo (see Section 8.2). The sending agent 372 then performs the key deployment and key agreement operations of the 373 Elliptic Curve MQV Scheme specified in [SEC1, Section 6.2]. As a 374 result, the sending agent obtains: 376 - an ephemeral public key, which is represented as a value of type 377 ECPoint (see Section 8.2), encapsulated in a bit string, placed 378 in an MQVuserKeyingMaterial ephemeralPublicKey publicKey field 379 (see Section 8.2), 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 The ephemeral public key can be re-used with an AuthenticatedData for 385 greater efficiency. 387 3.2.3. Actions of the receiving agent 389 When using 1-Pass ECMQV with EnvelopedData, the receiving agent 390 determines the bit string "SharedInfo", which is the DER encoding of 391 ECC-CMS-SharedInfo (see Section 8.2), and the integer "keydatalen" 392 from the key-size, in bits, of the KeyWrapAlgorithm. The receiving 393 agent then retrieves the static and ephemeral EC public keys of the 394 originator, from the originator and ukm fields as described in field 395 and checks that the domain parameters are the same. The receiving 396 agent then performs the key agreement operation of the Elliptic Curve 397 MQV Scheme [SEC1, Section 6.2]. As a result, the receiving agent 398 obtains a shared secret bit string "K" which is used as the pairwise 399 key-encryption key to unwrap the CEK. 401 4. AuthenticatedData using ECC 403 This section describes how to use ECC algorithms with the CMS 404 AuthenticatedData format. AuthenticatedData lacks non-repudiation, 405 and so in some instances is preferable to SignedData. (For example, 406 the sending agent might not want the message to be authenticated when 407 forwarded.) 409 4.1. AuthenticatedData using 1-pass ECMQV 411 This section describes how to use the 1-Pass elliptic curve MQV 412 (ECMQV) key agreement algorithm with AuthenticatedData. ECMQV is 413 specified in [SEC1]. An advantage of using 1-Pass ECMQV is that it 414 can be used with both EnvelopedData and AuthenticatedData. 416 4.1.1. Fields of the KeyAgreeRecipientInfo 418 The AuthenticatedData KeyAgreeRecipientInfo fields are used in the 419 same manner as the fields for the corresponding EnvelopedData 420 KeyAgreeRecipientInfo fields of Section 3.2.1 of this document. 422 4.1.2. Actions of the sending agent 424 The sending agent uses the same actions as for EnvelopedData with 1- 425 Pass ECMQV, as specified in Section 3.2.2 of this document. 427 The ephemeral public key can be re-used with an EnvelopedData for 428 greater efficiency. 430 Note: if there are multiple recipients, an attack is possible where 431 one recipient modifies the content without other recipients noticing 432 [BON]. A sending agent who is concerned with such an attack SHOULD 433 use a separate AuthenticatedData for each recipient. 435 4.1.3. Actions of the receiving agent 437 The receiving agent uses the same actions as for EnvelopedData with 438 1-Pass ECMQV, as specified in Section 3.2.3 of this document. 440 Note: see Note in Section 4.1.2. 442 5. Recommended Algorithms and Elliptic Curves 444 Implementations of this specification MUST implement either 445 SignedData with ECDSA or EnvelopedData with ephemeral-static ECDH. 446 Implementations of this specification SHOULD implement both 447 SignedData with ECDSA and EnvelopedData with ephemeral-static ECDH. 448 Implementations MAY implement the other techniques specified, such as 449 AuthenticatedData and 1-Pass ECMQV. 451 Furthermore, in order to encourage interoperability, implementations 452 SHOULD use the elliptic curve domain parameters specified by ANSI 453 [X9.62], NIST [DSS] and SECG [SEC2]. It is RECOMMENDED that the P- 454 256 curve be used with SHA-256, the P-384 curve be used with SHA-384, 455 and the P-521 curve be used with SHA-512. 457 Implementations of this specification MUST implement the SHA-256 hash 458 algorithm. The SHA-1, SHA-224, SHA-384, SHA-512 hash algorithms MAY 459 be supported. 461 When ECDSA, ECDH, or ECMQV is used, it is RECOMMENDED that the 462 P-256 curve be used with SHA-256, the P-384 curve be used with SHA- 463 384, and the P-521 curve be used with SHA-512. 465 Implementations of this specification that support EnvelopedData with 466 ephemeral-static ECDH standard primitive MUST support the 467 dhSinglePass-stdDH-sha256kdf-scheme algorithm. They MUST also support 468 the id-aes128-wrap algorithm. The dhSinglePass-stdDH-sha1kdf-scheme, 469 dhSinglePass-stdDH-sha224kdf-scheme, dhSinglePass-stdDH-sha384kdf- 470 scheme, and dhSinglePass-stdDH-sha512kdf-scheme algorithms MAY be 471 supported. Likewise, the id-alg-CMS3DESwrap, id-aes192-wrap, and id- 472 aes256wrap MAY be supported. 474 Implementations of this specification that support EnvelopedData with 475 ephemeral-static ECDH cofactor primitive MUST support the 476 dhSinglePass-cofactorDH-sha256kdf-scheme algorithm. They MUST also 477 support the id-aes128-wrap algorithm. The dhSinglePass-cofactorDH- 478 sha1kdf-scheme, dhSinglePass-cofactorDH-sha224kdf-scheme, 479 dhSinglePass-cofactorDH-sha384kdf-scheme, and dhSinglePass- 480 cofactorDH-sha512kdf-scheme algorithms MAY be supported. Likewise, 481 the id-alg-CMS3DESwrap, id-aes192-wrap, and id-aes256wrap MAY be 482 supported. 484 Implementations of this specification that support EnvelopedData with 485 ECMQV MUST support the mqvSinglePass-sha256kdf-scheme algorithm. They 486 MUST also support the id-aes128-wrap algorithm. The mqvSinglePass- 487 sha1kdf-scheme, mqvSinglePass-sha224kdf-scheme, mqvSinglePass- 488 sha384kdf-scheme, and mqvSinglePass-sha512kdf-scheme algorithms MAY 489 be supported. Likewise, the id-alg-CMS3DESwrap, id-aes192-wrap, and 490 id-aes256wrap MAY be supported. 492 Implementations of this specification that support AuthenticatedData 493 with ECMQV MUST support the 494 mqvSinglePass-sha256kdf-scheme algorithm. They MUST also support the 495 id-aes128-wrap algorithm. The mqvSinglePass-sha1kdf-scheme, 496 mqvSinglePass-sha224kdf-scheme, mqvSinglePass-sha384kdf-scheme, and 497 mqvSinglePass-sha512kdf-scheme algorithms MAY be supported. Likewise, 498 the id-alg-CMS3DESwrap, id-aes192-wrap, and id-aes256wrap MAY be 499 supported. 501 6. Certificates using ECC 503 Internet X.509 certificates [PKI] can be used in conjunction with 504 this specification to distribute agents' public keys. The use of ECC 505 algorithms and keys within X.509 certificates is specified in 506 [PKI-ALG]. 508 7. SMIMECapabilities Attribute and ECC 510 A sending agent MAY announce to receiving agents that it supports one 511 or more of the ECC algorithms in this document by using the 512 SMIMECapabilities signed attribute [MSG, Section 2.5.2]. 514 The SMIMECapability value to indicate support for the ECDSA signature 515 algorithm is the SEQUENCE with the capabilityID field containing the 516 object identifiers ecdsa-with-SHA* object identifiers (where * is 1, 517 224, 256, 384, or 512) all with NULL parameters. The DER encodings 518 are: 520 ecdsa-with-SHA1: 30 0b 06 07 2a 86 48 ce 3d 04 01 05 00 522 ecdsa-with-SHA224: 30 0c 06 08 2a 86 48 ce 3d 04 03 01 05 00 524 ecdsa-with-SHA256: 30 0c 06 08 2a 86 48 ce 3d 04 03 02 05 00 526 ecdsa-with-SHA384: 30 0c 06 08 2a 86 48 ce 3d 04 03 03 05 00 528 ecdsa-with-SHA512: 30 0c 06 08 2a 86 48 ce 3d 04 03 04 05 00 530 The SMIMECapability value to indicate support for 531 a) the standard ECDH key agreement algorithm, 532 b) the cofactor ECDH key agreement algorithm, or 533 c) the 1-Pass ECMQV key agreement algorithm 534 is a SEQUENCE with the capabilityID field containing the object 535 identifier 536 a) dhSinglePass-stdDH-sha*kdf-scheme, 537 b) dhSinglePass-cofactorDH-sha*kdf-scheme, or 538 c) mqvSinglePass-sha*kdf-scheme 539 respectively (where * is 1, 224, 256, 384, or 512) with the 540 parameters present. The parameters indicate the supported key- 541 encryption algorithm with the KeyWrapAlgorithm algorithm identifier. 543 Example DER encodings that indicate some capabilities are as follows 544 (KA is key agreement, KDF is key derivation function, and Wrap is key 545 wrap algorithm): 547 KA=ECDH standard KDF=SHA1 Wrap=3DES 549 30 1c 550 06 09 2b 81 05 10 86 48 3f 00 02 551 30 0f 552 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 553 05 00 555 KA=ECDH standard KDF=SHA256 Wrap=AES128 557 30 17 558 06 06 2b 81 04 01 0B 01 559 30 0d 560 06 09 60 86 48 01 65 03 04 01 05 561 05 00 563 KA=ECDH standard KDF=SHA384 Wrap=AES256 565 30 17 566 06 06 2b 81 04 01 0B 02 567 30 0d 568 06 09 60 86 48 01 65 03 04 01 2D 569 05 00 571 KA=ECDH cofactor KDF=SHA1 Wrap=3DES 573 30 1c 574 06 09 2b 81 05 10 86 48 3f 00 03 575 30 0f 576 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 577 05 00 579 KA=ECDH cofactor KDF=SHA256 Wrap=AES128 581 30 17 582 06 06 2b 81 04 01 0E 01 583 30 0d 584 06 09 60 86 48 01 65 03 04 01 05 585 05 00 587 KA=ECDH cofactor KDF=SHA384 Wrap=AES256 589 30 17 590 06 06 2b 81 04 01 0E 02 591 30 0d 592 06 09 60 86 48 01 65 03 04 01 2D 593 05 00 595 KA=ECMQV 1-Pass KDF=SHA1 Wrap=3DES 597 30 1c 598 06 09 2b 81 05 10 86 48 3f 00 10 599 30 0f 600 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 601 05 00 603 KA=ECMQV 1-Pass KDF=SHA256 Wrap=AES128 605 30 17 606 06 06 2b 81 04 01 0F 01 607 30 0d 608 06 09 60 86 48 01 65 03 04 01 05 609 05 00 611 KA=ECMQV 1-Pass KDF=SHA384 Wrap=AES256 613 30 17 614 06 06 2b 81 04 01 0F 02 615 30 0d 616 06 09 60 86 48 01 65 03 04 01 2D 617 05 00 619 8. ASN.1 Syntax 621 The ASN.1 syntax used in this document is gathered in this section 622 for reference purposes. 624 8.1. Algorithm Identifiers 626 The following object identifier indicates the hash algorithm used in 627 this document [SMIME-SHA2]: 629 id-sha1 OBJECT IDENTIFIER ::= { 630 iso(1) identified-organization(3) oiw(14) secsig(3) 631 algorithm(2) 26 } 633 id-sha224 OBJECT IDENTIFIER ::= { 634 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 635 csor(3) nistalgorithm(4) hashalgs(2) 4 } 637 id-sha256 OBJECT IDENTIFIER ::= { 638 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 639 csor(3) nistalgorithm(4) hashalgs(2) 1 } 641 id-sha384 OBJECT IDENTIFIER ::= { 642 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 643 csor(3) nistalgorithm(4) hashalgs(2) 2 } 645 id-sha512 OBJECT IDENTIFIER ::= { 646 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 647 csor(3) nistalgorithm(4) hashalgs(2) 3 } 649 The following object identifier is used in this document to indicate 650 an elliptic curve public key: 652 id-ecPublicKey OBJECT IDENTIFIER ::= { ansi-x9-62 keyType(2) 1 } 654 where 656 ansi-x9-62 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 657 10045 } 659 When the object identifier id-ecPublicKey is used here with an 660 algorithm identifier, the associated parameters contain NULL. 662 The following object identifier indicates the digital signature 663 algorithm used in this document: 665 ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { 666 ansi-x9-62 signatures(4) 1 } 668 ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { 669 ansi-x9-62 signatures(4) ecdsa-with-SHA2(3) 1 } 671 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { 672 ansi-x9-62 signatures(4) ecdsa-with-SHA2(3) 2 } 674 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { 675 ansi-x9-62 signatures(4) ecdsa-with-SHA2(3) 3 } 677 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { 678 ansi-x9-62 signatures(4) ecdsa-with-SHA2(3) 4 } 680 When the object identifiers ecdsa-with-SHA1, ecdsa-with-SHA224, 681 ecdsa-with-SHA256, ecdsa-with-SHA384, or ecdsa-with-SHA512 are used 682 within an algorithm identifier, the associated parameters field 683 contains NULL. 685 The following object identifiers indicate the key agreement 686 algorithms used in this document: 688 dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 689 x9-63-scheme 2 } 691 dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 692 secg-scheme 11 0 } 694 dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 695 secg-scheme 11 1 } 697 dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 698 secg-scheme 11 2 } 700 dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 701 secg-scheme 11 3 } 703 dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 704 x9-63-scheme 3 } 706 dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 707 secg-scheme 14 0 } 709 dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 710 secg-scheme 14 1 } 712 dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 713 secg-scheme 14 2 } 715 dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 716 secg-scheme 14 3 } 718 mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= { 719 x9-63-scheme 16 } 721 mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= { 722 secg-scheme 15 0 } 724 mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= { 725 secg-scheme 15 1 } 727 mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= { 728 secg-scheme 15 2 } 730 mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= { 731 secg-scheme 15 3 } 733 where 735 x9-63-scheme OBJECT IDENTIFIER ::= { 736 iso(1) identified-organization(3) tc68(133) country(16) 737 x9(840) x9-63(63) schemes(0) } 739 and 741 secg-scheme OBJECT IDENTIFIER ::= { 742 iso(1) identified-organization(3) certicom(132) schemes(1) } 744 When the object identifiers are used here within an algorithm 745 identifier, the associated parameters field contains the CMS 746 KeyWrapAlgorithm algorithm identifier. 748 8.2. Other Sytnax 750 The following additional syntax is used here. 752 When using ECDSA with SignedData, ECDSA signatures are encoded using 753 the type: 755 ECDSA-Sig-Value ::= SEQUENCE { 756 r INTEGER, 757 s INTEGER } 759 ECDSA-Sig-Value is specified in [X9.62]. Within CMS, ECDSA-Sig-Value 760 is DER-encoded and placed within a signature field of SignedData. 762 When using ECDH and ECMQV with EnvelopedData and AuthenticatedData, 763 ephemeral and static public keys are encoded using the type ECPoint. 765 ECPoint ::= OCTET STRING 767 When using ECMQV with EnvelopedData and AuthenticatedData, the 768 sending agent's ephemeral public key and additional keying material 769 are encoded using the type: 771 MQVuserKeyingMaterial ::= SEQUENCE { 772 ephemeralPublicKey OriginatorPublicKey, 773 addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL } 775 The ECPoint syntax in used to represent the ephemeral public key and 776 placed in the ephemeralPublicKey field. The additional user keying 777 material is placed in the addedukm field. Then the 778 MQVuserKeyingMaterial value is DER-encoded and placed within a ukm 779 field of EnvelopedData or AuthenticatedData. 781 When using ECDH or ECMQV with EnvelopedData or AuthenticatedData, the 782 key-encryption keys are derived by using the type: 784 ECC-CMS-SharedInfo ::= SEQUENCE { 785 keyInfo AlgorithmIdentifier, 786 entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL, 787 suppPubInfo [2] EXPLICIT OCTET STRING } 789 The fields of ECC-CMS-SharedInfo are as follows: 791 keyInfo contains the object identifier of the key-encryption 792 algorithm (used to wrap the CEK) and NULL parameters. 794 entityUInfo optionally contains additional keying material 795 supplied by the sending agent. When used with ECDH and CMS, the 796 entityUInfo field contains the octet string ukm. When used with 797 ECMQV and CMS, the entityUInfo contains the octet string addedukm 798 (encoded in MQVuserKeyingMaterial). 800 suppPubInfo contains the length of the generated KEK, in bits, 801 represented as a 32 bit number, as in [CMS-DH]. (E.g. for 3DES 802 it would be 00 00 00 c0.) 804 Within CMS, ECC-CMS-SharedInfo is DER-encoded and used as input to 805 the key derivation function, as specified in [SEC1, Section 3.6.1]. 807 Note that ECC-CMS-SharedInfo differs from the OtherInfo specified in 808 [CMS-DH]. Here, a counter value is not included in the keyInfo field 809 because the key derivation function specified in [SEC1, Section 810 3.6.1] ensures that sufficient keying data is provided. 812 9. Security Considerations 814 This specification is based on [CMS], [X9.62] and [SEC1] and the 815 appropriate security considerations of those documents apply. 817 In addition, implementors of AuthenticatedData should be aware of the 818 concerns expressed in [BON] when using AuthenticatedData to send 819 messages to more than one recipient. Also, users of MQV should be 820 aware of the vulnerability in [K]. 822 When implementing EnvelopedData or AuthenticatedData, there are five 823 algorithm related choices that need to be made: 825 1) What is the public key size? 826 2) What is the KDF? 827 3) What is the key wrap algorithm? 828 4) What is the content encryption algorithm? 829 5) What is the curve? 831 Consideration must be given to strength of the security provided by 832 each of these choices. Security is measured in bits, where a strong 833 symmetric cipher with a key of X bits is said to provide X bits of 834 security. It is recommended that the bits of security provided by 835 each are roughly equivalent. The following table provides comparable 836 minimum bits of security [NISTSP800-57] for the ECDH/ECMQV key sizes, 837 KDFs, key wrapping algorithms, and content encryption algorithms. It 838 also lists curves [PKI-ALG] for the key sizes. 840 Minimum | ECDH or | Key | Key | Content | Curves 841 Bits of | ECQMV | Derivation | Wrap | Encryption | 842 Security | Key Size | Function | Alg. | Alg. | 843 ---------+----------+------------+----------+-------------+---------- 844 80 | 160-223 | SHA1 | 3DES | 3DES CBC | sect163k1 845 | | SHA224 | AES-128 | AES-128 CBC | secp163r2 846 | | SHA256 | AES-192 | AES-192 CBC | secp192r1 847 | | SHA384 | AES-256 | AES-256 CBC | 848 | | SHA512 | | | 849 ---------+----------+------------+----------+-------------+--------- 850 112 | 224-255 | SHA1 | 3DES | 3DES CBC | secp224r1 851 | | SHA224 | AES-128 | AES-128 CBC | sect233k1 852 | | SHA256 | AES-192 | AES-192 CBC | sect233r1 853 | | SHA384 | AES-256 | AES-256 CBC | 854 | | SHA512 | | | 855 ---------+----------+------------+----------+-------------+--------- 856 128 | 256-383 | SHA1 | AES-128 | AES-128 CBC | secp256r1 857 | | SHA224 | AES-192 | AES-192 CBC | sect283k1 858 | | SHA256 | AES-256 | AES-256 CBC | sect283r1 859 | | SHA384 | | | 860 | | SHA512 | | | 861 ---------+----------+------------+----------+-------------+--------- 862 192 | 384-511 | SHA224 | AES-192 | AES-192 CBC | secp384r1 863 | | SHA256 | AES-256 | AES-256 CBC | sect409k1 864 | | SHA384 | | | sect409r1 865 | | SHA512 | | | 866 ---------+----------+------------+----------+-------------+--------- 867 256 | 512+ | SHA256 | AES-256 | AES-256 CBC | secp521r1 868 | | SHA384 | | | sect571k1 869 | | SHA512 | | | sect571r1 870 ---------+----------+------------+----------+-------------+--------- 871 To promote interoperability, the following choices are REOMMENDED: 873 Minimum | ECDH or | Key | Key | Content | Curve 874 Bits of | ECQMV | Derivation | Wrap | Encryption | 875 Security | Key Size | Function | Alg. | Alg. | 876 ---------+----------+------------+----------+-------------+---------- 877 80 | 192 | SHA256 | 3DES | 3DES CBC | secp192r1 878 ---------+----------+------------+----------+-------------+---------- 879 112 | 224 | SHA256 | 3DES | 3DES CBC | secp224r1 880 ---------+----------+------------+----------+-------------+---------- 881 128 | 256 | SHA256 | AES-128 | AES-128 CBC | secp256r1 882 ---------+----------+------------+----------+-------------+---------- 883 192 | 384 | SHA384 | AES-256 | AES-256 CBC | secp384r1 884 ---------+----------+------------+----------+-------------+---------- 885 256 | 512 | SHA512 | AES-256 | AES-256 CBC | secp521r1 886 ---------+----------+------------+----------+-------------+---------- 888 When implementing SignedData, there are three algorithm related 889 choices that need to be made: 891 1) What is the public key size? 892 2) What is the hash algorithm? 893 3) What is the curve? 895 Consideration must be given to the bits of security provided by each 896 of these choices. Security is measured in bits, where a strong 897 symmetric cipher with a key of X bits is said to provide X bits of 898 security. It is recommended that the bits of security provided by 899 each choice are roughly equivalent. The following table provides 900 comparable minimum bits of security [NISTSP800-57] for the ECDSA key 901 sizes and message digest algorithms. It also lists curves [PKI-ALG] 902 for the key sizes. 904 Minimum | ECDSA | Message | Curve 905 Bits of | Key Size | Digest | 906 Security | | Algorithm | 907 ---------+----------+-----------+----------- 908 80 | 160-223 | SHA1 | sect163k1 909 | | SHA224 | secp163r2 910 | | SHA256 | secp192r1 911 | | SHA384 | 912 | | SHA512 | 913 ---------+----------+-----------+----------- 914 112 | 224-255 | SHA224 | secp224r1 915 | | SHA256 | sect233k1 916 | | SHA384 | sect233r1 917 | | SHA512 | 918 ---------+----------+-----------+----------- 919 128 | 256-383 | SHA256 | secp256r1 920 | | SHA384 | sect283k1 921 | | SHA512 | sect283r1 922 ---------+----------+-----------+----------- 923 192 | 384-511 | SHA384 | secp384r1 924 | | SHA512 | sect409k1 925 | | | sect409r1 926 ---------+----------+-----------+----------- 927 256 | 512+ | SHA512 | secp521r1 928 | | | sect571k1 929 | | | sect571r1 930 ---------+----------+-----------+----------- 932 To promote interoperability, the following choices are RECOMMENDED: 934 Minimum | ECDSA | Message | Curve 935 Bits of | Key Size | Digest | 936 Security | | Algorithm | 937 ---------+----------+-----------+----------- 938 80 | 192 | SHA256 | sect192r1 939 ---------+----------+-----------+----------- 940 112 | 224 | SHA256 | secp224r1 941 ---------+----------+-----------+----------- 942 128 | 256 | SHA256 | secp256r1 943 ---------+----------+-----------+----------- 944 192 | 384 | SHA384 | secp384r1 945 ---------+----------+-----------+----------- 946 256 | 512+ | SHA512 | secp521r1 947 ---------+----------+-----------+----------- 949 10. IANA Considerations 951 None. 953 11. References 955 11.1. Normative 957 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 3852, 958 July. 960 [CMS-AES] Schaad, J., "Use of the Advanced Encryption Standard 961 (AES) Encryption Algorithm in Cryptographic Message 962 Syntax (CMS)", RFC 3565, July 2003. 964 [CMS-AESCG] Housley, R., "Using AES-CCM and AES-GCM Authenticated 965 Encryption in the Cryptographic Message Syntax (CMS)", 966 RFC 5084, November 2007. 968 [CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS) 969 Algorithms", RFC 3370, August 2002. 971 [CMS-DH] Rescorla, E., "Diffie-Hellman Key Agreement Method", 972 RFC 2631, June 1999. 974 [IEEE1363] IEEE P1363, "Standard Specifications for Public Key 975 Cryptography", Institute of Electrical and Electronics 976 Engineers, 2000. 978 [DSS] FIPS 186-2, "Digital Signature Standard", National 979 Institute of Standards and Technology, January 2000. 981 [MUST] Bradner, S., "Key Words for Use in RFCs to Indicate 982 Requirement Levels", BCP 14, RFC 2119, March 1997. 984 [MSG] Ramsdell, B., and S. Turner, "S/MIME Version 3.2 985 Message Specification", work-in-progress. 987 [PKI] Cooper, D., Santesson, S., Farrell, S., Boeyen, S. 988 Housley, R., and W. Polk, "Internet X.509 Public Key 989 Infrastructure Certificate and Certificate Revocation 990 List (CRL) Profile", RFC 5280, May 2008. 992 [PKI-ALG] Turner, S., Brown, D., Yiu, K., Housley, R., and W. 993 Polk, "Elliptic Curve Cryptography Subject Public Key 994 Information", work-in-progress. 996 [SEC1] SECG, "Elliptic Curve Cryptography", Standards for 997 Efficient Cryptography Group, 2000. Available from 998 www.secg.org/collateral/sec1.pdf. 1000 [SEC2] SECG, "Recommended Elliptic Curve Domain Parameters", 1001 Standards for Efficient Cryptography Group, 2000. 1002 Available from www.secg.org/collateral/sec2.pdf. 1004 [SHS] National Institute of Standards and Technology (NIST), 1005 FIPS Publication 180-2: Secure Hash Standard, August 1006 2002. 1008 [SMIME-SHA2] Turner, S., "Using SHA2 Algorithms with Cryptographic 1009 Message Syntax", work-in-progress. 1011 [X9.62] ANSI X9.62-2005, "Public Key Cryptography For The 1012 Financial Services Industry: The Elliptic Curve Digital 1013 Signature Algorithm (ECDSA)", American National 1014 Standards Institute, 2005. 1016 [X.208] CCITT Recommendation X.208: Specification of Abstract 1017 Syntax Notation One (ASN.1), 1988. 1019 [X.680] ITU-T Recommendation X.680: Information Technology - 1020 Abstract Syntax Notation One, 1997. 1022 [X.681] ITU-T Recommendation X.680: Information Technology - 1023 Abstract Syntax Notation One: Information Object 1024 Specification, 1997. 1026 [X.682] ITU-T Recommendation X.682: Information Technology - 1027 Abstract Syntax Notation One: Constraint Specification, 1028 2002. 1030 [X.683] ITU-T Recommendation X.683: Information Technology - 1031 Abstract Syntax Notation One: Parameterization of ASN.1 1032 Specifications, 2002. 1034 11.2. Informative 1036 [BON] D. Boneh, "The Security of Multicast MAC", Presentation 1037 at Selected Areas of Cryptography 2000, Center for 1038 Applied Cryptographic Research, University of Waterloo, 1039 2000. Paper version available from 1040 http://crypto.stanford.edu/~dabo/papers/mmac.ps 1042 [CMS-KEA] Pawling, J., "CMS KEA and SKIPJACK Conventions", RFC 1043 2876, July 2000. 1045 [K] B. Kaliski, "MQV Vulnerability", Posting to ANSI X9F1 1046 and IEEE P1363 newsgroups, 1998. 1048 Annex A ASN.1 Modules 1050 Appendix A.1 provides the normative ASN.1 definitions for the 1051 structures described in this specification using ASN.1 as defined in 1052 [X.208]. 1054 Appendix A.2 provides an informative ASN.1 definitions for the 1055 structures described in this specification using ASN.1 as defined in 1056 [X.680], [X.681], [X.682], [X.683]. This appendix contains the same 1057 information as Appendix A.1 in a more recent (and precise) ASN.1 1058 notation, however Appendix A.1 takes precedence in case of conflict. 1060 Annex A.1 1988 ASN.1 Module 1062 Annex A.2 2004 ASN.1 Module 1064 SMIMEECCAlgs-2008 1065 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1066 smime(16) modules(0) TBD } 1068 DEFINITIONS EXPLICIT TAGS ::= 1070 BEGIN 1072 -- EXPORTS ALL 1074 IMPORTS 1076 -- From [PKI-ALG] 1078 ALGORITHM, algorithmIdentifier, MessageDigestAlgorithms, 1079 SignatureAlgorithms 1080 ow-sha1, ow-sha224, ow-sha256, ow-sha384, ow-sha512, 1081 sa-ecdsaWithSHA1 1082 FROM PKIXAlgs-2008 1083 { iso(1) identified-organization(3) dod(6) internet(1) 1084 security(5) mechanisms(5) pkix(7) id-mod(0) TBD } 1086 -- From [CMS-AES] 1088 id-aes128-CBC, id-aes192-CBC, id-aes256-CBC, AES-IV 1089 id-aes128-wrap, id-aes192-wrap, id-aes1256-wrap 1090 FROM CMSAesRsaesOaep 1091 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1092 smime(16) modules(0) id-mod-cms-aes(19) } 1094 -- From [CMS-AESCG] 1096 id-aes128-CCM, id-aes192-CCM, id-aes256-CCM, CCMParameters 1097 id-aes128-GCM, id-aes192-GCM, id-aes256-GCM, GCMParameters 1098 FROM CMS-AES-CCM-and-AES-GCM 1099 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1100 smime(16) modules(0) id-mod-cms-aes(32) } 1102 -- From [CMS] 1104 OriginatorPublicKey, UserKeyingMaterial 1105 FROM CryptographicMessageSyntax2004 1106 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1107 smime(16) modules(0) cms-2004(24) } 1109 -- From [CMS-ALG] 1111 hMAC-SHA1, id-alg-CMS3DESwrap, CBCParameter 1112 FROM CryptographicMessageSyntaxAlgorithms 1113 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1114 smime(16) modules(0) cmsalg-2001(16) } 1116 ; 1118 -- Constrains the SignedData digestAlgorithms field 1119 -- Constrains the SignedData SignerInfo digestAlgorithm field 1120 -- Constrains the AuthenticatedData digestAlgorithm field 1122 MessageDigestAlgorithms ALGORITHM ::= { 1123 ow-sha1 | 1124 ow-sha224 | 1125 ow-sha256 | 1126 ow-sha384 | 1127 ow-sha512, 1128 ... -- Extensible 1129 } 1131 -- Constrains the SignedData SignerInfo signatureAlgorithm field 1133 SignatureAlgorithms ALGORITHM ::= { 1134 sa-ecdsaWithSHA1 | 1135 sa-ecdsaWithSHA224 | 1136 sa-ecdsaWithSHA256 | 1137 sa-ecdsaWithSHA384 | 1138 sa-ecdsaWithSHA512 , 1139 ... -- Extensible 1140 } 1141 sa-ecdsa-with-SHA224 ALGORITHM ::= { 1142 OID ecdsa-with-SHA224 PARMS NULL } 1144 ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { 1145 iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 1146 ecdsa-with-SHA2(3) 1 } 1148 sa-ecdsa-with-SHA256 ALGORITHM ::= { 1149 OID ecdsa-with-SHA256 PARMS NULL } 1151 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { 1152 iso(1) member-body(2) us(840)ansi-X9-62(10045) signatures(4) 1153 ecdsa-with-SHA2(3) 2 } 1155 sa-ecdsa-with-SHA384 ALGORITHM ::= { 1156 OID ecdsa-with-SHA384 PARMS NULL } 1158 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { 1159 iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 1160 ecdsa-with-SHA2(3) 3 } 1162 sa-ecdsa-with-SHA512 ALGORITHM ::= { 1163 OID ecdsa-with-SHA512 PARMS NULL } 1165 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { 1166 iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 1167 ecdsa-with-SHA2(3) 4 } 1169 -- ECDSA Signature Value 1170 -- Contents of SignatureValue OCTET STRING 1172 ECDSA-Sig-Value ::= SEQUENCE { 1173 r INTEGER, 1174 s INTEGER 1175 } 1176 -- Constrains the EnvelopedData RecipientInfo KeyAgreeRecipientInfo 1177 -- keyEncryption Algorithm field 1178 -- Constrains the AuthenticatedData RecipientInfo 1179 -- KeyAgreeRecipientInfo keyEncryption Algorithm field 1180 -- Constrains the AuthEnvelopedData RecipientInfo 1181 -- KeyAgreeRecipientInfo keyEncryption Algorithm field 1183 -- DH variants are not used with AuthenticatedData or 1184 -- AuthEnvelopedData 1186 KeyAgreementAlgorithms ALGORITHM ::= { 1187 kaa-dhSinglePass-stdDH-sha1kdf | 1188 kaa-dhSinglePass-stdDH-sha224kdf | 1189 kaa-dhSinglePass-stdDH-sha256kdf | 1190 kaa-dhSinglePass-stdDH-sha384kdf | 1191 kaa-dhSinglePass-stdDH-sha512kdf | 1192 kaa-dhSinglePass-cofactorDH-sha1kdf | 1193 kaa-dhSinglePass-cofactorDH-sha224kdf | 1194 kaa-dhSinglePass-cofactorDH-sha256kdf | 1195 kaa-dhSinglePass-cofactorDH-sha384kdf | 1196 kaa-dhSinglePass-cofactorDH-sha512kdf | 1197 kaa-mqvSinglePass-sha1kdf | 1198 kaa-mqvSinglePass-sha224kdf | 1199 kaa-mqvSinglePass-sha256kdf | 1200 kaa-mqvSinglePass-sha384kdf | 1201 kaa-mqvSinglePass-sha512kdf, 1202 ... -- Extensible 1203 } 1205 x9-63-scheme OBJECT IDENTIFIER ::= { 1206 iso(1) identified-organization(3) tc68(133) country(16) x9(840) 1207 x9-63(63) schemes(0) } 1209 secg-scheme OBJECT IDENTIFIER ::= { 1210 iso(1) identified-organization(3) certicom(132) schemes(1) } 1212 kaa-dhSinglePass-stdDH-sha1kdf ALGORITHM ::= { 1213 OID dhSinglePass-stdDH-sha1kdf-scheme PARMS KeyWrapAlgorithms } 1215 dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 1216 x9-63-scheme 2 } 1218 kaa-dhSinglePass-stdDH-sha224kdf ALGORITHM ::= { 1219 OID dhSinglePass-stdDH-sha224kdf-scheme PARMS KeyWrapAlgorithms } 1221 dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 1222 secg-scheme 11 0 } 1224 kaa-dhSinglePass-stdDH-sha256kdf ALGORITHM ::= { 1225 OID dhSinglePass-stdDH-sha256kdf-scheme PARMS KeyWrapAlgorithms } 1227 dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 1228 secg-scheme 11 1 } 1230 kaa-dhSinglePass-stdDH-sha384kdf ALGORITHM ::= { 1231 OID dhSinglePass-stdDH-sha384kdf-scheme PARMS KeyWrapAlgorithms } 1233 dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 1234 secg-scheme 11 2 } 1236 kaa-dhSinglePass-stdDH-sha512kdf ALGORITHM ::= { 1237 OID dhSinglePass-stdDH-sha512kdf-scheme PARMS KeyWrapAlgorithms } 1239 dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 1240 secg-scheme 11 3 } 1242 kaa-dhSinglePass-cofactorDH-sha1kdf ALGORITHM ::= { 1243 OID dhSinglePass-cofactorDH-sha1kdf-scheme PARMS KeyWrapAlgorithms } 1245 dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { 1246 x9-63-scheme 3 } 1248 kaa-dhSinglePass-cofactorDH-sha224kdf ALGORITHM ::= { 1249 OID dhSinglePass-cofactorDH-sha224kdf-scheme 1250 PARMS KeyWrapAlgorithms } 1252 dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { 1253 secg-scheme 14 0 } 1255 kaa-dhSinglePass-cofactorDH-sha256kdf ALGORITHM ::= { 1256 OID dhSinglePass-cofactorDH-sha256kdf-scheme 1257 PARMS KeyWrapAlgorithms } 1259 dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 1260 secg-scheme 14 1 } 1262 kaa-dhSinglePass-cofactorDH-sha384kdf ALGORITHM ::= { 1263 OID dhSinglePass-cofactorDH-sha384kdf-scheme 1264 PARMS KeyWrapAlgorithms } 1266 dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { 1267 secg-scheme 14 2 } 1269 kaa-dhSinglePass-cofactorDH-sha512kdf ALGORITHM ::= { 1270 OID dhSinglePass-cofactorDH-sha512kdf-scheme 1271 PARMS KeyWrapAlgorithms } 1273 dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { 1274 secg-scheme 14 3 } 1276 kaa-mqvSinglePass-sha1kdf ALGORITHM ::= { 1277 OID mqvSinglePass-sha1kdf-scheme PARMS KeyWrapAlgorithms } 1279 mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= { 1280 x9-63-scheme 16 } 1282 kaa-mqvSinglePass-sha224kdf ALGORITHM ::= { 1283 OID mqvSinglePass-sha224kdf-scheme PARMS KeyWrapAlgorithms } 1285 mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= { 1286 secg-scheme 15 0 } 1288 kaa-mqvSinglePass-sha256kdf ALGORITHM ::= { 1289 OID mqvSinglePass-sha256kdf-scheme PARMS KeyWrapAlgorithms } 1291 mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= { 1292 secg-scheme 15 1 } 1294 kaa-mqvSinglePass-sha384kdf ALGORITHM ::= { 1295 OID mqvSinglePass-sha384kdf-scheme PARMS KeyWrapAlgorithms } 1297 mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= { 1298 secg-scheme 15 2 } 1300 kaa-mqvSinglePass-sha512kdf ALGORITHM ::= { 1301 OID mqvSinglePass-sha512kdf-scheme PARMS KeyWrapAlgorithms } 1303 mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= { 1304 secg-scheme 15 3 } 1306 KeyWrapAlgorithms ALGORITHM ::= { 1307 kwa-3des | 1308 kwa-aes128 | 1309 kwa-aes192 | 1310 kwa-aes256, 1311 ... -- Extensible 1312 } 1314 kwa-3des ALGORITHM :: = { 1315 OID id-alg-CMS3DESwrap PARMS NULL } 1317 kwa-aes128 ALGORITHM ::= { 1318 OID id-aes128-wrap PARMS ABSENT } 1320 kwa-aes192 ALGORITHM ::= { 1321 OID id-aes192-wrap PARMS ABSENT } 1323 kwa-aes256 ALGORITHM ::= { 1324 OID id-aes256-wrap PARMS ABSENT } 1326 -- Constrains the EnvelopedData EncryptedContentInfo encryptedContent 1327 -- field 1329 ContentEncryptionAlgorithms ALGORITHM ::= { 1330 cea-des-ede3-cbc | 1331 cea-aes128-cbc | 1332 cea-aes192-cbc | 1333 cea-aes256-cbc | 1334 cea-aes128-ccm | 1335 cea-aes192-ccm | 1336 cea-aes256-ccm | 1337 cea-aes128-gcm | 1338 cea-aes192-gcm | 1339 cea-aes256-gcm, 1340 ... -- Extensible 1341 } 1343 cea-des-ede3-cbc ALGORITHM ::= { 1344 OID des-ede3-cbc PARMS CBCParameter } 1346 cea-aes128-cbc ALGORITHM ::= { 1347 OID id-aes128-CBC PARMS AES-IV } 1349 cea-aes192-cbc ALGORITHM ::= { 1350 OID id-aes192-CBC PARMS AES-IV } 1352 cea-aes256-cbc ALGORITHM ::= { 1353 OID id-aes256-CBC PARMS AES-IV } 1355 cea-aes128-ccm ALGORITHM ::= { 1356 OID id-aes128-CCM PARMS CCMParameters } 1358 cea-aes192-ccm ALGORITHM ::= { 1359 OID id-aes192-CCM PARMS CCMParameters } 1361 cea-aes256-ccm ALGORITHM ::= { 1362 OID id-aes256-CCM PARMS CCMParameters } 1364 cea-aes128-gcm ALGORITHM ::= { 1365 OID id-aes128-GCM PARMS GCMParameters } 1367 cea-aes192-gcm ALGORITHM ::= { 1368 OID id-aes192-GCM PARMS GCMParameters } 1370 cea-aes256-gcm ALGORITHM ::= { 1371 OID id-aes256-GCM PARMS GCMParameters } 1373 -- Constrains the AuthenticatedData 1374 -- MessageAuthenticationCodeAlgorithm field 1375 -- Constrains the AuthEnvelopedData 1376 -- MessageAuthenticationCodeAlgorithm field 1378 MessageAuthenticationCodeAlgorithms ALGORITHM ::= { 1379 maca-sha1 | 1380 maca-sha224 | 1381 maca-sha256 | 1382 maca-sha384 | 1383 maca-sha512, 1384 ... -- Extensible 1385 } 1387 maca-sha1 ALGORITHM ::= { 1388 OID hMAC-SHA1 PARMS NULL } 1390 maca-sha224 ALGORITHM ::= { 1391 OID id-hmacWithSHA224 PARMS NULL } 1393 -- Would love to import the HMAC224-512 OIDS but they're not in a 1394 -- module (that I could find) 1396 id-hmacWithSHA224 OBJECT IDENTIFIER ::= { 1397 iso(1) member-body(2) us(840) rsadsi(113549) 1398 digestAlgorithm(2) 8 } 1400 maca-sha256 ALGORITHM ::= { 1401 OID id-hmacWithSHA256 PARMS NULL } 1403 id-hmacWithSHA256 OBJECT IDENTIFIER ::= { 1404 iso(1) member-body(2) us(840) rsadsi(113549) 1405 digestAlgorithm(2) 9 } 1407 maca-sha384 ALGORITHM ::= { 1408 OID id-hmacWithSHA384 PARMS NULL } 1410 id-hmacWithSHA384 OBJECT IDENTIFIER ::= { 1411 iso(1) member-body(2) us(840) rsadsi(113549) 1412 digestAlgorithm(2) 10 } 1414 maca-sha512 ALGORITHM ::= { 1415 OID id-hmacWithSHA512 PARMS NULL } 1417 id-hmacWithSHA512 OBJECT IDENTIFIER ::= { 1418 iso(1) member-body(2) us(840) rsadsi(113549) 1419 digestAlgorithm(2) 11 } 1421 -- Constraints on KeyAgreeRecipientInfo OriginatorIdentifierOrKey 1422 -- OriginatorPublicKey algorithm field 1424 -- PARMS are NULL 1426 OriginatorPKAlgorithms ALGORITHM ::= { 1427 opka-ec, 1428 ... -- Extensible 1429 } 1431 opka-ec AGLORITHM ::={ 1432 OID id-ecPublicKey PARMS NULL } 1434 -- Format for both ephemeral and static public keys 1436 ECPoint ::= OCTET STRING 1438 -- Format of KeyAgreeRecipientInfo ukm field when used with 1439 -- ECMQV 1441 MQVuserKeyingMaterial ::= SEQUENCE { 1442 ephemeralPublicKey OriginatorPublicKey, 1443 addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL 1444 } 1446 -- Format for ECDH and ECMQV key-encryption keys when using 1447 -- EnvelopedData or AuthenticatedData 1449 ECC-CMS-SharedInfo ::= SEQUENCE { 1450 keyInfo AlgorithmIdentifier { KeyWrapAlgorithms }, 1451 entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL, 1452 suppPubInfo [2] EXPLICIT OCTET STRING 1453 } 1454 SMIME-CAPS ::= CLASS { 1455 &Type OPTIONAL, 1456 &id OBJECT IDENTIFIER UNIQUE 1457 } 1458 WITH SYNTAX {TYPE &Type IDENTIFIED BY &id } 1460 SMIMECapability ::= SEQUENCE { 1461 capabilityID SMIME-CAPS.&id({SMimeCapsSet}), 1462 parameters SMIME-CAPS. 1463 &Type({SMimeCapsSet}{@capabilityID}) OPTIONAL 1464 } 1466 SMimeCapsSet SMIME-CAPS ::= { 1467 cap-ecdsa-with-SHA1 | 1468 cap-ecdsa-with-SHA224 | 1469 cap-ecdsa-with-SHA256 | 1470 cap-ecdsa-with-SHA384 | 1471 cap-ecdsa-with-SHA512 | 1472 cap-dhSinglePass-stdDH-sha1kdf | 1473 cap-dhSinglePass-stdDH-sha224kdf | 1474 cap-dhSinglePass-stdDH-sha256kdf | 1475 cap-dhSinglePass-stdDH-sha384kdf | 1476 cap-dhSinglePass-stdDH-sha512kdf | 1477 cap-dhSinglePass-cofactorDH-sha1kdf | 1478 cap-dhSinglePass-cofactorDH-sha224kdf | 1479 cap-dhSinglePass-cofactorDH-sha256kdf | 1480 cap-dhSinglePass-cofactorDH-sha384kdf | 1481 cap-dhSinglePass-cofactorDH-sha512kdf | 1482 cap-mqvSinglePass-sha1kdf | 1483 cap-mqvSinglePass-sha224kdf | 1484 cap-mqvSinglePass-sha256kdf | 1485 cap-mqvSinglePass-sha384kdf | 1486 cap-mqvSinglePass-sha512kdf, 1487 ... -- Extensible 1488 } 1490 cap-ecdsa-with-SHA1 SMIME-CAPS ::= { 1491 TYPE NULL IDENTIFIED BY ecdsa-with-SHA1 } 1493 cap-ecdsa-with-SHA224 SMIME-CAPS ::= { 1494 TYPE NULL IDENTIFIED BY ecdsa-with-SHA224 } 1496 cap-ecdsa-with-SHA256 SMIME-CAPS ::= { 1497 TYPE NULL IDENTIFIED BY ecdsa-with-SHA256 } 1499 cap-ecdsa-with-SHA384 SMIME-CAPS ::= { 1500 TYPE NULL IDENTIFIED BY ecdsa-with-SHA384 } 1502 cap-ecdsa-with-SHA512 SMIME-CAPS ::= { 1503 TYPE NULL IDENTIFIED BY ecdsa-with-SHA512 } 1505 cap-dhSinglePass-stdDH-sha1kdf SMIME-CAPS ::= { 1506 TYPE KeyWrapAlgorithms IDENTIFIED BY dhSinglePass-stdDH-sha1kdf } 1508 cap-dhSinglePass-stdDH-sha224kdf SMIME-CAPS ::= { 1509 TYPE KeyWrapAlgorithms IDENTIFIED BY dhSinglePass-stdDH-sha224kdf } 1511 cap-dhSinglePass-stdDH-sha256kdf SMIME-CAPS ::= { 1512 TYPE KeyWrapAlgorithms IDENTIFIED BY dhSinglePass-stdDH-sha256kdf } 1514 cap-dhSinglePass-stdDH-sha384kdf SMIME-CAPS ::= { 1515 TYPE KeyWrapAlgorithms IDENTIFIED BY dhSinglePass-stdDH-sha384kdf } 1517 cap-dhSinglePass-stdDH-sha512kdf SMIME-CAPS ::= { 1518 TYPE KeyWrapAlgorithms IDENTIFIED BY dhSinglePass-stdDH-sha512kdf } 1520 cap-dhSinglePass-cofactorDH-sha1kdf SMIME-CAPS ::= { 1521 TYPE KeyWrapAlgorithms 1522 IDENTIFIED BY dhSinglePass-cofactorDH-sha1kdf } 1524 cap-dhSinglePass-cofactorDH-sha224kdf SMIME-CAPS ::= { 1525 TYPE KeyWrapAlgorithms 1526 IDENTIFIED BY dhSinglePass-cofactorDH-sha224kdf } 1528 cap-dhSinglePass-cofactorDH-sha256kdf SMIME-CAPS ::= { 1529 TYPE KeyWrapAlgorithms 1530 IDENTIFIED BY dhSinglePass-cofactorDH-sha256kdf } 1532 cap-dhSinglePass-cofactorDH-sha384kdf SMIME-CAPS ::= { 1533 TYPE KeyWrapAlgorithms 1534 IDENTIFIED BY dhSinglePass-cofactorDH-sha384kdf } 1536 cap-dhSinglePass-cofactorDH-sha512kdf SMIME-CAPS ::= { 1537 TYPE KeyWrapAlgorithms 1538 IDENTIFIED BY dhSinglePass-cofactorDH-sha512kdf } 1540 cap-mqvSinglePass-sha1kdf SMIME-CAPS ::= { 1541 TYPE KeyWrapAlgorithms IDENTIFIED BY mqvSinglePass-sha1kdf } 1543 cap-mqvSinglePass-sha224kdf SMIME-CAPS ::= { 1544 TYPE KeyWrapAlgorithms IDENTIFIED BY mqvSinglePass-sha224kdf } 1546 cap-mqvSinglePass-sha256kdf SMIME-CAPS ::= { 1547 TYPE KeyWrapAlgorithms IDENTIFIED BY mqvSinglePass-sha256kdf } 1549 cap-mqvSinglePass-sha384kdf SMIME-CAPS ::= { 1550 TYPE KeyWrapAlgorithms IDENTIFIED BY mqvSinglePass-sha384kdf } 1552 cap-mqvSinglePass-sha512kdf SMIME-CAPS ::= { 1553 TYPE KeyWrapAlgorithms IDENTIFIED BY mqvSinglePass-sha512kdf } 1555 END 1557 Acknowledgements 1559 The methods described in this document are based on work done by the 1560 ANSI X9F1 working group. The authors wish to extend their thanks to 1561 ANSI X9F1 for their assistance. The authors also wish to thank Peter 1562 de Rooij for his patient assistance. The technical comments of 1563 Francois Rousseau were valuable contributions. 1565 Many thanks go out to the other authors of RFC 3278: Simon Blake- 1566 Wilson, Paul Lambert, and Dan Brown. Without the initial version of 1567 RFC3278 this version wouldn't exist. 1569 The authors also wish to thank Alfred Hines, Jim Schaad, and Russ 1570 Housley for their valuable input. 1572 Author's Addresses 1574 Sean Turner 1576 IECA, Inc. 1577 3057 Nutley Street, Suite 106 1578 Fairfax, VA 22031 1579 USA 1581 Email: turners@ieca.com 1583 Daniel R. L. Brown 1585 Certicom Corp 1586 5520 Explorer Drive #400 1587 Mississauga, ON L4W 5L1 1588 CANADA 1590 Email: dbrown@certicom.com 1592 Full Copyright Statement 1594 Copyright (C) The IETF Trust (2008). 1596 This document is subject to the rights, licenses and restrictions 1597 contained in BCP 78, and except as set forth therein, the authors 1598 retain all their rights. 1600 This document and the information contained herein are provided on an 1601 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1602 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1603 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1604 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1605 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1606 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1608 Intellectual Property 1610 The IETF takes no position regarding the validity or scope of any 1611 Intellectual Property Rights or other rights that might be claimed to 1612 pertain to the implementation or use of the technology described in 1613 this document or the extent to which any license under such rights 1614 might or might not be available; nor does it represent that it has 1615 made any independent effort to identify any such rights. Information 1616 on the procedures with respect to rights in RFC documents can be 1617 found in BCP 78 and BCP 79. 1619 Copies of IPR disclosures made to the IETF Secretariat and any 1620 assurances of licenses to be made available, or the result of an 1621 attempt made to obtain a general license or permission for the use of 1622 such proprietary rights by implementers or users of this 1623 specification can be obtained from the IETF on-line IPR repository at 1624 http://www.ietf.org/ipr. 1626 The IETF invites any interested party to bring to its attention any 1627 copyrights, patents or patent applications, or other proprietary 1628 rights that may cover technology that may be required to implement 1629 this standard. Please address the information to the IETF at 1630 ietf-ipr@ietf.org. 1632 Acknowledgment 1634 Funding for the RFC Editor function is provided by the IETF 1635 Administrative Support Activity (IASA).