draft-ietf-smime-3278bis-05.txt   draft-ietf-smime-3278bis-06.txt 
S/MIME WG Sean Turner, IECA S/MIME WG Sean Turner, IECA
Internet Draft Dan Brown, Certicom Internet Draft Dan Brown, Certicom
Intended Status: Informational January 5, 2009 Intended Status: Informational April 14, 2009
Obsoletes: 3278 (once approved) Obsoletes: 3278 (once approved)
Expires: July 5, 2009 Expires: October 14, 2009
Use of Elliptic Curve Cryptography (ECC) Algorithms Use of Elliptic Curve Cryptography (ECC) Algorithms
in Cryptographic Message Syntax (CMS) in Cryptographic Message Syntax (CMS)
draft-ietf-smime-3278bis-05.txt draft-ietf-smime-3278bis-06.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on June 5, 2008. This Internet-Draft will expire on October 14, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
This document describes how to use Elliptic Curve Cryptography (ECC) This document describes how to use Elliptic Curve Cryptography (ECC)
public-key algorithms in the Cryptographic Message Syntax (CMS). The public-key algorithms in the Cryptographic Message Syntax (CMS). The
ECC algorithms support the creation of digital signatures and the ECC algorithms support the creation of digital signatures and the
exchange of keys to encrypt or authenticate content. The definition exchange of keys to encrypt or authenticate content. The definition
of the algorithm processing is based on the NIST FIPS 186-3 for of the algorithm processing is based on the NIST FIPS 186-3 for
digital signature, NIST SP800-56A and SEC1 for key agreement, RFC digital signature, NIST SP800-56A and SEC1 for key agreement, RFC
3370 and RFC 3565 for key wrap and content encryption, NIST FIPS 180- 3370 and RFC 3565 for key wrap and content encryption, NIST FIPS 180-
skipping to change at page 2, line 28 skipping to change at page 2, line 39
Discussion Discussion
This draft is being discussed on the 'ietf-smime' mailing list. To This draft is being discussed on the 'ietf-smime' mailing list. To
subscribe, send a message to ietf-smime-request@imc.org with the subscribe, send a message to ietf-smime-request@imc.org with the
single word subscribe in the body of the message. There is a Web site single word subscribe in the body of the message. There is a Web site
for the mailing list at <http://www.imc.org/ietf-smime/>. for the mailing list at <http://www.imc.org/ietf-smime/>.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
1.1. Requirements Terminology..................................3 1.1. Requirements Terminology..................................4
2. SignedData using ECC...........................................3 2. SignedData using ECC...........................................4
2.1. SignedData using ECDSA....................................4 2.1. SignedData using ECDSA....................................4
3. EnvelopedData using ECC Algorithms.............................5 3. EnvelopedData using ECC Algorithms.............................5
3.1. EnvelopedData using (ephemeral-static) ECDH...............5 3.1. EnvelopedData using (ephemeral-static) ECDH...............5
3.2. EnvelopedData using 1-Pass ECMQV..........................7 3.2. EnvelopedData using 1-Pass ECMQV..........................8
4. AuthenticatedData and AuthEnvelopedData using ECC.............10 4. AuthenticatedData and AuthEnvelopedData using ECC.............10
4.1. AuthenticatedData using 1-pass ECMQV.....................10 4.1. AuthenticatedData using 1-pass ECMQV.....................11
4.2. AuthEnvelopedData using 1-pass ECMQV.....................11 4.2. AuthEnvelopedData using 1-pass ECMQV.....................12
5. Certificates using ECC........................................12 5. Certificates using ECC........................................13
6. SMIMECapabilities Attribute and ECC...........................12 6. SMIMECapabilities Attribute and ECC...........................13
7. ASN.1 Syntax..................................................20 7. ASN.1 Syntax..................................................21
7.1. Algorithm Identifiers....................................20 7.1. Algorithm Identifiers....................................21
7.2. Other Syntax.............................................24 7.2. Other Syntax.............................................24
8. Recommended Algorithms and Elliptic Curves....................25 8. Recommended Algorithms and Elliptic Curves....................26
9. Security Considerations.......................................28 9. Security Considerations.......................................28
10. IANA Considerations..........................................33 10. IANA Considerations..........................................33
11. References...................................................33 11. References...................................................33
11.1. Normative...............................................33 11.1. Normative...............................................33
11.2. Informative.............................................35 11.2. Informative.............................................35
Appendix A ASN.1 Modules.........................................36 Appendix A ASN.1 Modules.........................................36
Appendix A.1 1988 ASN.1 Module................................36 Appendix A.1 1988 ASN.1 Module................................36
Appendix A.2 2004 ASN.1 Module................................43 Appendix A.2 2004 ASN.1 Module................................43
Appendix B Changes since RFC 3278................................53 Appendix B Changes since RFC 3278................................53
Acknowledgements.................................................56 Acknowledgements.................................................56
Author's Addresses...............................................56 Authors' Addresses...............................................56
1. Introduction 1. Introduction
The Cryptographic Message Syntax (CMS) is cryptographic algorithm The Cryptographic Message Syntax (CMS) is cryptographic algorithm
independent. This specification defines a profile for the use of independent. This specification defines a profile for the use of
Elliptic Curve Cryptography (ECC) public key algorithms in the CMS. Elliptic Curve Cryptography (ECC) public key algorithms in the CMS.
The ECC algorithms are incorporated into the following CMS content The ECC algorithms are incorporated into the following CMS content
types: types:
- 'SignedData' to support ECC-based digital signature methods - 'SignedData' to support ECC-based digital signature methods
skipping to change at page 4, line 28 skipping to change at page 4, line 39
When using ECDSA with SignedData, the fields of SignerInfo are as in When using ECDSA with SignedData, the fields of SignerInfo are as in
[CMS], but with the following restrictions: [CMS], but with the following restrictions:
- digestAlgorithm MUST contain the algorithm identifier of the hash - digestAlgorithm MUST contain the algorithm identifier of the hash
algorithm (see Section 7.1.1) which MUST be one of the algorithm (see Section 7.1.1) which MUST be one of the
following: id-sha1, id-sha224, id-sha256, id-sha384, or id- following: id-sha1, id-sha224, id-sha256, id-sha384, or id-
sha512. sha512.
- signatureAlgorithm contains the signature algorithm identifier - signatureAlgorithm contains the signature algorithm identifier
(see Section 7.1.3): ecdsa-with-SHA1, ecdsa-with-SHA224, ecdsa- (see Section 7.1.3): ecdsa-with-SHA1, ecdsa-with-SHA224, ecdsa-
with-SHA256, ecdsa-with-SHA384, or ecdsa-with-SHA512. with-SHA256, ecdsa-with-SHA384, or ecdsa-with-SHA512. The hash
algorithm identified in the name of the signature algorithm MUST
be the same as the digestAlgorithm (e.g., digestAlgorithm is id-
sha256 therefore signatureAlgorithm is ecdsa-with-SHA256).
- signature MUST contain the DER encoding (as an octet string) of a - signature MUST contain the DER encoding (as an octet string) of a
value of the ASN.1 type ECDSA-Sig-Value (see Section 7.2). value of the ASN.1 type ECDSA-Sig-Value (see Section 7.2).
When using ECDSA, the SignedData certificates field MAY include the When using ECDSA, the SignedData certificates field MAY include the
certificate(s) for the EC public key(s) used in the generation of the certificate(s) for the EC public key(s) used in the generation of the
ECDSA signatures in SignedData. ECC certificates are discussed in ECDSA signatures in SignedData. ECC certificates are discussed in
Section 5. Section 5.
2.1.2. Actions of the sending agent 2.1.2. Actions of the sending agent
skipping to change at page 6, line 7 skipping to change at page 6, line 17
3.1.1. Fields of KeyAgreeRecipientInfo 3.1.1. Fields of KeyAgreeRecipientInfo
When using ephemeral-static ECDH with EnvelopedData, the fields of When using ephemeral-static ECDH with EnvelopedData, the fields of
KeyAgreeRecipientInfo are as follows: KeyAgreeRecipientInfo are as follows:
- version MUST be 3. - version MUST be 3.
- originator MUST be the alternative originatorKey. The - originator MUST be the alternative originatorKey. The
originatorKey algorithm field MUST contain the id-ecPublicKey originatorKey algorithm field MUST contain the id-ecPublicKey
object identifier (see Section 7.1.3). The parameters object identifier (see Section 7.1.2). The parameters
associated with id-ecPublicKey MUST be absent or ECParameters. associated with id-ecPublicKey MUST be absent, ECParameters, or
NOTE: The previous version of this document required NULL to be NULL. The parameters associated with id-ecPublicKey SHOULD be
present; support for this legacy form is OPTIONAL. The absent or ECParameters, and NULL is allowed to support legacy
originatorKey publicKey field MUST contain the value of the implementations. The previous version of this document required
ASN.1 type ECPoint (see Section 7.2), which represents the NULL to be present. If the parameters are ECParameters, then
sending agent's ephemeral EC public key. The ECPoint in they MUST be namedCurve. The originatorKey publicKey field MUST
uncompressed form MUST be supported. contain the value of the ASN.1 type ECPoint (see Section 7.2),
which represents the sending agent's ephemeral EC public key.
The ECPoint in uncompressed form MUST be supported.
- ukm MAY be present or absent. However, message originators - ukm MAY be present or absent. However, message originators
SHOULD include the ukm. As specified in RFC 3852 [CMS], SHOULD include the ukm. As specified in RFC 3852 [CMS],
implementations MUST support ukm message recipient processing, implementations MUST support ukm message recipient processing,
so interoperability is not a concern if the ukm is present or so interoperability is not a concern if the ukm is present or
absent. The ukm is placed in the entityUInfo field of the ECC- absent. The ukm is placed in the entityUInfo field of the ECC-
CMS-SharedInfo structure. When present, the ukm is used to CMS-SharedInfo structure. When present, the ukm is used to
ensure that a different key-encryption key is generated, even ensure that a different key-encryption key is generated, even
when the ephemeral private key is improperly used more than when the ephemeral private key is improperly used more than
once, by using the ECC-CMS-SharedInfo as an input to the key once, by using the ECC-CMS-SharedInfo as an input to the key
skipping to change at page 7, line 17 skipping to change at page 7, line 29
"SharedInfo", which is the DER encoding of ECC-CMS-SharedInfo (see "SharedInfo", which is the DER encoding of ECC-CMS-SharedInfo (see
Section 7.2). The sending agent then performs the key deployment and Section 7.2). The sending agent then performs the key deployment and
the key agreement operation of the Elliptic Curve Diffie-Hellman the key agreement operation of the Elliptic Curve Diffie-Hellman
Scheme specified in [SP800-56A] or [SEC1]; in either case, use the Scheme specified in [SP800-56A] or [SEC1]; in either case, use the
KDF defined in Section 3.6.1 of [SEC1] with the hash algorithm KDF defined in Section 3.6.1 of [SEC1] with the hash algorithm
identified in the key agreement algorithm. As a result the sending identified in the key agreement algorithm. As a result the sending
agent obtains: agent obtains:
- an ephemeral public key, which is represented as a value of the - an ephemeral public key, which is represented as a value of the
type ECPoint (see Section 7.2), encapsulated in a bit string and type ECPoint (see Section 7.2), encapsulated in a bit string and
placed in the KeyAgreeRecipientInfo originator field, and placed in the KeyAgreeRecipientInfo originator originatorKey
publicKey field, and
- a shared secret bit string "K", which is used as the pairwise - a shared secret bit string "K", which is used as the pairwise
key-encryption key for that recipient, as specified in [CMS]. key-encryption key for that recipient, as specified in [CMS].
In a single message, if there are multiple layers for a recipient, In a single message, if there are multiple layers for a recipient,
then the ephemeral public key can be reused by the originator for then the ephemeral public key can be reused by the originator for
that recipient in each of the different layers. that recipient in each of the different layers.
3.1.3. Actions of the receiving agent 3.1.3. Actions of the receiving agent
skipping to change at page 8, line 36 skipping to change at page 8, line 49
- originator identifies the static EC public key of the sender. It - originator identifies the static EC public key of the sender. It
SHOULD be one of the alternatives, issuerAndSerialNumber or SHOULD be one of the alternatives, issuerAndSerialNumber or
subjectKeyIdentifier, and point to one of the sending agent's subjectKeyIdentifier, and point to one of the sending agent's
certificates. certificates.
- ukm MUST be present. The ukm field is an octet string which MUST - ukm MUST be present. The ukm field is an octet string which MUST
contain the DER encoding of the type MQVuserKeyingMaterial (see contain the DER encoding of the type MQVuserKeyingMaterial (see
Section 7.2). The MQVuserKeyingMaterial ephemeralPublicKey Section 7.2). The MQVuserKeyingMaterial ephemeralPublicKey
algorithm field MUST contain the id-ecPublicKey object algorithm field MUST contain the id-ecPublicKey object
identifier (see Section 7.1.3). The parameters associated with identifier (see Section 7.1.2). The parameters associated with
id-ecPublicKey MUST be absent or ECParameters. NOTE: The id-ecPublicKey MUST be absent, ECParameters, or NULL. The
previous version of this document required NULL to be present; parameters associated with id-ecPublicKey SHOULD be absent or
support for this legacy form is OPTIONAL. The ECParameters, as NULL is allowed to support legacy
MQVuserKeyingMaterial ephemeralPublicKey publicKey field MUST implementations. The previous version of this document required
contain the DER-encoding of the ASN.1 type ECPoint (see Section NULL to be present. If the parameters are ECParameters, then
7.2) representing the sending agent's ephemeral EC public key. they MUST be namedCurve. The MQVuserKeyingMaterial
The MQVuserKeyingMaterial addedukm field, if present, contains ephemeralPublicKey publicKey field MUST contain the DER-encoding
of the ASN.1 type ECPoint (see Section 7.2) representing the
sending agent's ephemeral EC public key. The
MQVuserKeyingMaterial addedukm field, if present, contains
additional user keying material from the sending agent. additional user keying material from the sending agent.
- keyEncryptionAlgorithm MUST contain the object identifier of the - keyEncryptionAlgorithm MUST contain the object identifier of the
key encryption algorithm, which in this case is a key agreement key encryption algorithm, which in this case is a key agreement
algorithm (see Section 7.1.4). The parameters field contains algorithm (see Section 7.1.4). The parameters field contains
KeyWrapAlgorithm. The KeyWrapAlgorithm indicates the symmetric KeyWrapAlgorithm. The KeyWrapAlgorithm indicates the symmetric
encryption algorithm used to encrypt the CEK with the KEK encryption algorithm used to encrypt the CEK with the KEK
generated using the 1-Pass ECMQV algorithm and any associated generated using the 1-Pass ECMQV algorithm and any associated
parameters (see Section 7.1.5). Algorithm requirements are parameters (see Section 7.1.5). Algorithm requirements are
found in Section 8. found in Section 8.
skipping to change at page 12, line 6 skipping to change at page 12, line 34
The receiving agent uses the same actions as for EnvelopedData with The receiving agent uses the same actions as for EnvelopedData with
1-Pass ECMQV, as specified in Section 3.2.3 of this document. 1-Pass ECMQV, as specified in Section 3.2.3 of this document.
4.2. AuthEnvelopedData using 1-pass ECMQV 4.2. AuthEnvelopedData using 1-pass ECMQV
This section describes how to use the 1-Pass elliptic curve MQV This section describes how to use the 1-Pass elliptic curve MQV
(ECMQV) key agreement algorithm with AuthEnvelopedData. ECMQV is (ECMQV) key agreement algorithm with AuthEnvelopedData. ECMQV is
method C(1, 2, ECC MQV) from [SP800-56A]. method C(1, 2, ECC MQV) from [SP800-56A].
When using ECMQV with AuthEnvelopedData, the fields of When using ECMQV with AuthEnvelopedData, the fields of
AuthenticatedData are as in [CMS-AUTHENV]. AuthEnvelopedData are as in [CMS-AUTHENV].
As 1-Pass ECMQV is a key agreement algorithm, the RecipientInfo kari As 1-Pass ECMQV is a key agreement algorithm, the RecipientInfo kari
choice is used. When using 1-Pass ECMQV, the AuthEnvelopedData choice is used. When using 1-Pass ECMQV, the AuthEnvelopedData
originatorInfo field MAY include the certificate(s) for the EC public originatorInfo field MAY include the certificate(s) for the EC public
key used in the formation of the pairwise key. ECC certificates are key used in the formation of the pairwise key. ECC certificates are
discussed in Section 5. discussed in Section 5.
4.2.1. Fields of the KeyAgreeRecipientInfo 4.2.1. Fields of the KeyAgreeRecipientInfo
The AuthEnvelopedData KeyAgreeRecipientInfo fields are used in the The AuthEnvelopedData KeyAgreeRecipientInfo fields are used in the
skipping to change at page 13, line 16 skipping to change at page 14, line 4
ecdsa-with-SHA1: 30 0b 06 07 2a 86 48 ce 3d 04 01 05 00 ecdsa-with-SHA1: 30 0b 06 07 2a 86 48 ce 3d 04 01 05 00
ecdsa-with-SHA224: 30 0a 06 08 2a 86 48 ce 3d 04 03 01 ecdsa-with-SHA224: 30 0a 06 08 2a 86 48 ce 3d 04 03 01
ecdsa-with-SHA256: 30 0a 06 08 2a 86 48 ce 3d 04 03 02 ecdsa-with-SHA256: 30 0a 06 08 2a 86 48 ce 3d 04 03 02
ecdsa-with-SHA384: 30 0a 06 08 2a 86 48 ce 3d 04 03 03 ecdsa-with-SHA384: 30 0a 06 08 2a 86 48 ce 3d 04 03 03
ecdsa-with-SHA512: 30 0a 06 08 2a 86 48 ce 3d 04 03 04 ecdsa-with-SHA512: 30 0a 06 08 2a 86 48 ce 3d 04 03 04
NOTE: The SMIMECapabilities attribute indicates that parameters for NOTE: The SMIMECapabilities attribute indicates that parameters for
ECDSA with SHA-1 are NULL, however, the parameters are absent when ECDSA with SHA-1 are NULL; however, the parameters are absent when
used to generate a digital signature. used to generate a digital signature.
The SMIMECapabilities attribute value indicates support for The SMIMECapabilities attribute value indicates support for
a) the standard ECDH key agreement algorithm, a) the standard ECDH key agreement algorithm,
b) the cofactor ECDH key agreement algorithm, or b) the cofactor ECDH key agreement algorithm, or
c) the 1-Pass ECMQV key agreement algorithm c) the 1-Pass ECMQV key agreement algorithm and
is a SEQUENCE with the capabilityID field containing the object is a SEQUENCE with the capabilityID field containing the object
identifier identifier
a) dhSinglePass-stdDH-sha*kdf-scheme, a) dhSinglePass-stdDH-sha*kdf-scheme,
b) dhSinglePass-cofactorDH-sha*kdf-scheme, or b) dhSinglePass-cofactorDH-sha*kdf-scheme, or
c) mqvSinglePass-sha*kdf-scheme c) mqvSinglePass-sha*kdf-scheme
respectively (where * is 1, 224, 256, 384, or 512) with the respectively (where * is 1, 224, 256, 384, or 512) with the
parameters present. The parameters indicate the supported key- parameters present. The parameters indicate the supported key-
encryption algorithm with the KeyWrapAlgorithm algorithm identifier. encryption algorithm with the KeyWrapAlgorithm algorithm identifier.
The DER encodings that indicate capabilities are as follows (KA is The DER encodings that indicate capabilities are as follows (KA is
skipping to change at page 14, line 18 skipping to change at page 15, line 4
KA=ECDH standard KDF=SHA-384 Wrap=Triple-DES KA=ECDH standard KDF=SHA-384 Wrap=Triple-DES
30 19 06 06 2b 81 04 01 0B 02 30 0f 06 0b 2a 86 48 86 f7 0d 01 30 19 06 06 2b 81 04 01 0B 02 30 0f 06 0b 2a 86 48 86 f7 0d 01
09 10 03 06 05 00 09 10 03 06 05 00
KA=ECDH standard KDF=SHA-512 Wrap=Triple-DES KA=ECDH standard KDF=SHA-512 Wrap=Triple-DES
30 19 06 06 2b 81 04 01 0B 03 30 0f 06 0b 2a 86 48 86 f7 0d 01 30 19 06 06 2b 81 04 01 0B 03 30 0f 06 0b 2a 86 48 86 f7 0d 01
09 10 03 06 05 00 09 10 03 06 05 00
KA=ECDH standard KDF=SHA-1 Wrap=AES-128 KA=ECDH standard KDF=SHA-1 Wrap=AES-128
30 1a 06 09 2b 81 05 10 86 48 3f 00 02 30 0d 06 09 60 86 48 01 30 18 06 09 2b 81 05 10 86 48 3f 00 02 30 0b 06 09 60 86 48 01
65 03 04 01 05 05 00 65 03 04 01 05
KA=ECDH standard KDF=SHA-224 Wrap=AES-128 KA=ECDH standard KDF=SHA-224 Wrap=AES-128
30 17 06 06 2b 81 04 01 0B 00 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0B 00 30 0b 06 09 60 86 48 01 65 03 04
01 05 05 00 01 05
KA=ECDH standard KDF=SHA-256 Wrap=AES-128 KA=ECDH standard KDF=SHA-256 Wrap=AES-128
30 17 06 06 2b 81 04 01 0B 01 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0B 01 30 0b 06 09 60 86 48 01 65 03 04
01 05 05 00 01 05
KA=ECDH standard KDF=SHA-384 Wrap=AES-128 KA=ECDH standard KDF=SHA-384 Wrap=AES-128
30 17 06 06 2b 81 04 01 0B 02 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0B 02 30 0b 06 09 60 86 48 01 65 03 04
01 05 05 00 01 05
KA=ECDH standard KDF=SHA-512 Wrap=AES-128 KA=ECDH standard KDF=SHA-512 Wrap=AES-128
30 17 06 06 2b 81 04 01 0B 03 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0B 03 30 0b 06 09 60 86 48 01 65 03 04
01 05 05 00 01 05
KA=ECDH standard KDF=SHA-1 Wrap=AES-192 KA=ECDH standard KDF=SHA-1 Wrap=AES-192
30 1a 06 09 2b 81 05 10 86 48 3f 00 02 30 0d 06 09 60 86 48 01 30 18 06 09 2b 81 05 10 86 48 3f 00 02 30 0b 06 09 60 86 48 01
65 03 04 01 2D 05 00 65 03 04 01 19
KA=ECDH standard KDF=SHA-224 Wrap=AES-192 KA=ECDH standard KDF=SHA-224 Wrap=AES-192
30 17 06 06 2b 81 04 01 0B 00 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0B 00 30 0b 06 09 60 86 48 01 65 03 04
01 2D 05 00 01 19
KA=ECDH standard KDF=SHA-256 Wrap=AES-192 KA=ECDH standard KDF=SHA-256 Wrap=AES-192
30 17 06 06 2b 81 04 01 0B 01 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0B 01 30 0b 06 09 60 86 48 01 65 03 04
01 2D 05 00 01 19
KA=ECDH standard KDF=SHA-384 Wrap=AES-192 KA=ECDH standard KDF=SHA-384 Wrap=AES-192
30 17 06 06 2b 81 04 01 0B 02 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0B 02 30 0b 06 09 60 86 48 01 65 03 04
01 2D 05 00 01 19
KA=ECDH standard KDF=SHA-512 Wrap=AES-192 KA=ECDH standard KDF=SHA-512 Wrap=AES-192
30 17 06 06 2b 81 04 01 0B 03 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0B 03 30 0b 06 09 60 86 48 01 65 03 04
01 2D 05 00 01 19
KA=ECDH standard KDF=SHA-1 Wrap=AES-256 KA=ECDH standard KDF=SHA-1 Wrap=AES-256
30 1a 06 09 2b 81 05 10 86 48 3f 00 02 30 0d 06 09 60 86 48 01 30 18 06 09 2b 81 05 10 86 48 3f 00 02 30 0b 06 09 60 86 48 01
65 03 04 01 2D 05 00 65 03 04 01 2D
KA=ECDH standard KDF=SHA-224 Wrap=AES-256 KA=ECDH standard KDF=SHA-224 Wrap=AES-256
30 17 06 06 2b 81 04 01 0B 00 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0B 00 30 0b 06 09 60 86 48 01 65 03 04
01 2D 05 00 01 2D
KA=ECDH standard KDF=SHA-256 Wrap=AES-256 KA=ECDH standard KDF=SHA-256 Wrap=AES-256
30 17 06 06 2b 81 04 01 0B 01 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0B 01 30 0b 06 09 60 86 48 01 65 03 04
01 2D 05 00 01 2D
KA=ECDH standard KDF=SHA-384 Wrap=AES-256 KA=ECDH standard KDF=SHA-384 Wrap=AES-256
30 17 06 06 2b 81 04 01 0B 02 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0B 02 30 0b 06 09 60 86 48 01 65 03 04
01 2D 05 00 01 2D 05 00
KA=ECDH standard KDF=SHA-512 Wrap=AES-256 KA=ECDH standard KDF=SHA-512 Wrap=AES-256
30 17 06 06 2b 81 04 01 0B 03 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0B 03 30 0b 06 09 60 86 48 01 65 03 04
01 2D 05 00 01 2D
KA=ECDH cofactor KDF=SHA-1 Wrap=Triple-DES KA=ECDH cofactor KDF=SHA-1 Wrap=Triple-DES
30 1c 06 09 2b 81 05 10 86 48 3f 00 03 30 0f 06 0b 2a 86 48 86 30 1c 06 09 2b 81 05 10 86 48 3f 00 03 30 0f 06 0b 2a 86 48 86
f7 0d 01 09 10 03 06 05 00 f7 0d 01 09 10 03 06 05 00
KA=ECDH cofactor KDF=SHA-224 Wrap=Triple-DES KA=ECDH cofactor KDF=SHA-224 Wrap=Triple-DES
30 19 06 06 2b 81 04 01 0E 00 30 0f 06 0b 2a 86 48 86 f7 0d 01 30 19 06 06 2b 81 04 01 0E 00 30 0f 06 0b 2a 86 48 86 f7 0d 01
09 10 03 06 05 00 09 10 03 06 05 00
skipping to change at page 16, line 31 skipping to change at page 17, line 16
30 19 06 06 2b 81 04 01 0E 02 30 0f 06 0b 2a 86 48 86 f7 0d 01 30 19 06 06 2b 81 04 01 0E 02 30 0f 06 0b 2a 86 48 86 f7 0d 01
09 10 03 06 05 00 09 10 03 06 05 00
KA=ECDH cofactor KDF=SHA-512 Wrap=Triple-DES KA=ECDH cofactor KDF=SHA-512 Wrap=Triple-DES
30 19 06 06 2b 81 04 01 0E 03 30 0f 06 0b 2a 86 48 86 f7 0d 01 30 19 06 06 2b 81 04 01 0E 03 30 0f 06 0b 2a 86 48 86 f7 0d 01
09 10 03 06 05 00 09 10 03 06 05 00
KA=ECDH cofactor KDF=SHA-1 Wrap=AES-128 KA=ECDH cofactor KDF=SHA-1 Wrap=AES-128
30 1a 06 09 2b 81 05 10 86 48 3f 00 03 30 0d 06 09 60 86 48 01 30 18 06 09 2b 81 05 10 86 48 3f 00 03 30 0b 06 09 60 86 48 01
65 03 04 01 05 05 00 65 03 04 01 05
KA=ECDH cofactor KDF=SHA-224 Wrap=AES-128 KA=ECDH cofactor KDF=SHA-224 Wrap=AES-128
30 17 06 06 2b 81 04 01 0E 00 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0E 00 30 0b 06 09 60 86 48 01 65 03 04
01 05 05 00 01 05
KA=ECDH cofactor KDF=SHA-256 Wrap=AES-128 KA=ECDH cofactor KDF=SHA-256 Wrap=AES-128
30 17 06 06 2b 81 04 01 0E 01 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0E 01 30 0b 06 09 60 86 48 01 65 03 04
01 05 05 00 01 05
KA=ECDH cofactor KDF=SHA-384 Wrap=AES-128 KA=ECDH cofactor KDF=SHA-384 Wrap=AES-128
30 17 06 06 2b 81 04 01 0E 02 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0E 02 30 0b 06 09 60 86 48 01 65 03 04
01 05 05 00 01 05
KA=ECDH cofactor KDF=SHA-512 Wrap=AES-128 KA=ECDH cofactor KDF=SHA-512 Wrap=AES-128
30 17 06 06 2b 81 04 01 0E 03 30 0d 06 09 60 86 48 01 65 03 04 30 17 06 06 2b 81 04 01 0E 03 30 0b 06 09 60 86 48 01 65 03 04
01 05 05 00 01 05
KA=ECDH cofactor KDF=SHA-1 Wrap=AES-192 KA=ECDH cofactor KDF=SHA-1 Wrap=AES-192
30 1a 06 09 2b 81 05 10 86 48 3f 00 03 30 0d 06 09 60 86 48 01 30 18 06 09 2b 81 05 10 86 48 3f 00 03 30 0b 06 09 60 86 48 01
65 03 04 01 19 05 00 65 03 04 01 19
KA=ECDH cofactor KDF=SHA-224 Wrap=AES-192 KA=ECDH cofactor KDF=SHA-224 Wrap=AES-192
30 17 06 06 2b 81 04 01 0E 00 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0E 00 30 0b 06 09 60 86 48 01 65 03 04
01 19 05 00 01 19
KA=ECDH cofactor KDF=SHA-256 Wrap=AES-192 KA=ECDH cofactor KDF=SHA-256 Wrap=AES-192
30 17 06 06 2b 81 04 01 0E 01 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0E 01 30 0b 06 09 60 86 48 01 65 03 04
01 19 05 00 01 19
KA=ECDH cofactor KDF=SHA-384 Wrap=AES-192 KA=ECDH cofactor KDF=SHA-384 Wrap=AES-192
30 17 06 06 2b 81 04 01 0E 02 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0E 02 30 0b 06 09 60 86 48 01 65 03 04
01 19 05 00 01 19
KA=ECDH cofactor KDF=SHA-512 Wrap=AES-192 KA=ECDH cofactor KDF=SHA-512 Wrap=AES-192
30 17 06 06 2b 81 04 01 0E 03 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0E 03 30 0b 06 09 60 86 48 01 65 03 04
01 19 05 00 01 19
KA=ECDH cofactor KDF=SHA-1 Wrap=AES-256 KA=ECDH cofactor KDF=SHA-1 Wrap=AES-256
30 1a 06 09 2b 81 05 10 86 48 3f 00 03 30 0d 06 09 60 86 48 01 30 15 06 09 2b 81 05 10 86 48 3f 00 03 30 0b 06 09 60 86 48 01
65 03 04 01 2D 05 00 65 03 04 01 2D
KA=ECDH cofactor KDF=SHA-224 Wrap=AES-256 KA=ECDH cofactor KDF=SHA-224 Wrap=AES-256
30 17 06 06 2b 81 04 01 0E 00 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0E 00 30 0b 06 09 60 86 48 01 65 03 04
01 2D 05 00 01 2D
KA=ECDH cofactor KDF=SHA-256 Wrap=AES-256 KA=ECDH cofactor KDF=SHA-256 Wrap=AES-256
30 17 06 06 2b 81 04 01 0E 01 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0E 01 30 0b 06 09 60 86 48 01 65 03 04
01 2D 05 00 01 2D
KA=ECDH cofactor KDF=SHA-384 Wrap=AES-256 KA=ECDH cofactor KDF=SHA-384 Wrap=AES-256
30 17 06 06 2b 81 04 01 0E 02 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0E 02 30 0b 06 09 60 86 48 01 65 03 04
01 2D 05 00 01 2D
KA=ECDH cofactor KDF=SHA-512 Wrap=AES-256 KA=ECDH cofactor KDF=SHA-512 Wrap=AES-256
30 17 06 06 2b 81 04 01 0E 03 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0E 03 30 0b 06 09 60 86 48 01 65 03 04
01 2D 05 00 01 2D
KA=ECMQV 1-Pass KDF=SHA-1 Wrap=Triple-DES KA=ECMQV 1-Pass KDF=SHA-1 Wrap=Triple-DES
30 1c 06 09 2b 81 05 10 86 48 3f 00 10 30 0f 06 0b 2a 86 48 86 30 1c 06 09 2b 81 05 10 86 48 3f 00 10 30 0f 06 0b 2a 86 48 86
f7 0d 01 09 10 03 06 05 00 f7 0d 01 09 10 03 06 05 00
KA=ECMQV 1-Pass KDF=SHA-224 Wrap=Triple-DES KA=ECMQV 1-Pass KDF=SHA-224 Wrap=Triple-DES
30 19 06 06 2b 81 04 01 0F 00 30 0f 06 0b 2a 86 48 86 f7 0d 01 30 19 06 06 2b 81 04 01 0F 00 30 0f 06 0b 2a 86 48 86 f7 0d 01
09 10 03 06 05 00 09 10 03 06 05 00
KA=ECMQV 1-Pass KDF=SHA-256 Wrap=Triple-DES KA=ECMQV 1-Pass KDF=SHA-256 Wrap=Triple-DES
30 19 06 06 2b 81 04 01 0F 01 30 0f 06 0b 2a 86 48 86 f7 0d 01 30 19 06 06 2b 81 04 01 0F 01 30 0f 06 0b 2a 86 48 86 f7 0d 01
09 10 03 06 05 00 09 10 03 06 05 00
skipping to change at page 18, line 41 skipping to change at page 19, line 26
30 19 06 06 2b 81 04 01 0F 02 30 0f 06 0b 2a 86 48 86 f7 0d 01 30 19 06 06 2b 81 04 01 0F 02 30 0f 06 0b 2a 86 48 86 f7 0d 01
09 10 03 06 05 00 09 10 03 06 05 00
KA=ECMQV 1-Pass KDF=SHA-512 Wrap=Triple-DES KA=ECMQV 1-Pass KDF=SHA-512 Wrap=Triple-DES
30 19 06 06 2b 81 04 01 0F 03 30 0f 06 0b 2a 86 48 86 f7 0d 01 30 19 06 06 2b 81 04 01 0F 03 30 0f 06 0b 2a 86 48 86 f7 0d 01
09 10 03 06 05 00 09 10 03 06 05 00
KA=ECMQV 1-Pass KDF=SHA-1 Wrap=AES-128 KA=ECMQV 1-Pass KDF=SHA-1 Wrap=AES-128
30 1a 06 09 2b 81 05 10 86 48 3f 00 10 30 0d 06 09 60 86 48 01 30 18 06 09 2b 81 05 10 86 48 3f 00 10 30 0b 06 09 60 86 48 01
65 03 04 01 05 05 00 65 03 04 01 05
KA=ECMQV 1-Pass KDF=SHA-224 Wrap=AES-128 KA=ECMQV 1-Pass KDF=SHA-224 Wrap=AES-128
30 17 06 06 2b 81 04 01 0F 00 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0F 00 30 0b 06 09 60 86 48 01 65 03 04
01 05 05 00 01 05
KA=ECMQV 1-Pass KDF=SHA-256 Wrap=AES-128 KA=ECMQV 1-Pass KDF=SHA-256 Wrap=AES-128
30 17 06 06 2b 81 04 01 0F 01 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0F 01 30 0b 06 09 60 86 48 01 65 03 04
01 05 05 00 01 05
KA=ECMQV 1-Pass KDF=SHA-384 Wrap=AES-128 KA=ECMQV 1-Pass KDF=SHA-384 Wrap=AES-128
30 17 06 06 2b 81 04 01 0F 02 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0F 02 30 0b 06 09 60 86 48 01 65 03 04
01 05 05 00 01 05 05 00
KA=ECMQV 1-Pass KDF=SHA-512 Wrap=AES-128 KA=ECMQV 1-Pass KDF=SHA-512 Wrap=AES-128
30 17 06 06 2b 81 04 01 0F 03 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0F 03 30 0d 06 09 60 86 48 01 65 03 04
01 05 05 00 01 05 05 00
KA=ECMQV 1-Pass KDF=SHA-1 Wrap=AES-192 KA=ECMQV 1-Pass KDF=SHA-1 Wrap=AES-192
30 1a 06 09 2b 81 05 10 86 48 3f 00 10 30 0d 06 09 60 86 48 01 30 18 06 09 2b 81 05 10 86 48 3f 00 10 30 0b 06 09 60 86 48 01
65 03 04 01 2D 05 00 65 03 04 01 19
KA=ECMQV 1-Pass KDF=SHA-224 Wrap=AES-192 KA=ECMQV 1-Pass KDF=SHA-224 Wrap=AES-192
30 17 06 06 2b 81 04 01 0F 00 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0F 00 30 0b 06 09 60 86 48 01 65 03 04
01 19 05 00 01 19
KA=ECMQV 1-Pass KDF=SHA-256 Wrap=AES-192 KA=ECMQV 1-Pass KDF=SHA-256 Wrap=AES-192
30 17 06 06 2b 81 04 01 0F 01 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0F 01 30 0b 06 09 60 86 48 01 65 03 04
01 19 05 00 01 19
KA=ECMQV 1-Pass KDF=SHA-384 Wrap=AES-192 KA=ECMQV 1-Pass KDF=SHA-384 Wrap=AES-192
30 17 06 06 2b 81 04 01 0F 02 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0F 02 30 0b 06 09 60 86 48 01 65 03 04
01 19 05 00 01 19
KA=ECMQV 1-Pass KDF=SHA-512 Wrap=AES-192 KA=ECMQV 1-Pass KDF=SHA-512 Wrap=AES-192
30 17 06 06 2b 81 04 01 0F 03 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0F 03 30 0b 06 09 60 86 48 01 65 03 04
01 19 05 00 01 19
KA=ECMQV 1-Pass KDF=SHA-1 Wrap=AES-256 KA=ECMQV 1-Pass KDF=SHA-1 Wrap=AES-256
30 1a 06 09 2b 81 05 10 86 48 3f 00 10 30 0d 06 09 60 86 48 01 30 18 06 09 2b 81 05 10 86 48 3f 00 10 30 0b 06 09 60 86 48 01
65 03 04 01 2D 05 00 65 03 04 01 2D
KA=ECMQV 1-Pass KDF=SHA-224 Wrap=AES-256 KA=ECMQV 1-Pass KDF=SHA-224 Wrap=AES-256
30 17 06 06 2b 81 04 01 0F 00 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0F 00 30 0b 06 09 60 86 48 01 65 03 04
01 2D 05 00 01 2D
KA=ECMQV 1-Pass KDF=SHA-256 Wrap=AES-256 KA=ECMQV 1-Pass KDF=SHA-256 Wrap=AES-256
30 17 06 06 2b 81 04 01 0F 01 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0F 01 30 0b 06 09 60 86 48 01 65 03 04
01 2D 05 00 01 2D
KA=ECMQV 1-Pass KDF=SHA-384 Wrap=AES-256 KA=ECMQV 1-Pass KDF=SHA-384 Wrap=AES-256
30 17 06 06 2b 81 04 01 0F 02 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0F 02 30 0b 06 09 60 86 48 01 65 03 04
01 2D 05 00 01 2D
KA=ECMQV 1-Pass KDF=SHA-512 Wrap=AES-256 KA=ECMQV 1-Pass KDF=SHA-512 Wrap=AES-256
30 17 06 06 2b 81 04 01 0F 03 30 0d 06 09 60 86 48 01 65 03 04 30 15 06 06 2b 81 04 01 0F 03 30 0b 06 09 60 86 48 01 65 03 04
01 2D 05 00 01 2D
NOTE: The S/MIME Capabilities indicate that parameters for the key NOTE: The S/MIME Capabilities indicate that parameters for the key
wrap algorithm AES-* (where * is 128, 192, or 256) are NULL; however, wrap algorithm AES-* (where * is 128, 192, or 256) are NULL; however,
the parameters are absent when used to encrypt/decrypt a content the parameters are absent when used to encrypt/decrypt a content
encryption key. encryption key.
NOTE: The S/MIME Capabilities for the supported AES content NOTE: The S/MIME Capabilities for the supported AES content
encryption key sizes are defined in [CMS-AES]. encryption key sizes are defined in [CMS-AES].
NOTE: The S/MIME Capabilities for the supported MAC algorithms are NOTE: The S/MIME Capabilities for the supported MAC algorithms are
skipping to change at page 24, line 12 skipping to change at page 24, line 29
The object identifiers and parameters associated with these The object identifiers and parameters associated with these
algorithms are found in [CMS-AESCG]. algorithms are found in [CMS-AESCG].
7.1.7. Message Authentication Code Algorithms 7.1.7. Message Authentication Code Algorithms
Message authentication code algorithms are used in AuthenticatedData Message authentication code algorithms are used in AuthenticatedData
in the macAlgorithm field. The message authentication code in the macAlgorithm field. The message authentication code
algorithms used in this document are HMAC with SHA-1, HMAC with SHA- algorithms used in this document are HMAC with SHA-1, HMAC with SHA-
224, HMAC with SHA-256, HMAC with SHA-384, and HMAC with SHA-512. 224, HMAC with SHA-256, HMAC with SHA-384, and HMAC with SHA-512.
The object identifiers and parameters associated with these The object identifiers and parameters associated with these
algorithms are found in [HMAC-SHA1] and [HMAC-SHA2]. algorithms are found in [CMS-ALG] and [HMAC-SHA2].
7.1.8. Key Derivation Algorithm 7.1.8. Key Derivation Algorithm
The KDF used in this document is as specified in 3.6.1 of [SEC1]. The KDF used in this document is as specified in 3.6.1 of [SEC1].
The hash algorithm is identified in key agreement algorithm. For The hash algorithm is identified in key agreement algorithm. For
example, dhSinglePass-stdDH-sha256kdf-scheme uses the KDF from [SEC1] example, dhSinglePass-stdDH-sha256kdf-scheme uses the KDF from [SEC1]
but uses SHA-256 instead of SHA-1. but uses SHA-256 instead of SHA-1.
7.2. Other Syntax 7.2. Other Syntax
skipping to change at page 27, line 46 skipping to change at page 28, line 17
Implementations that support AuthEnvelopedData with 1-Pass ECMQV: Implementations that support AuthEnvelopedData with 1-Pass ECMQV:
- MUST support the mqvSinglePass-sha256kdf-scheme key agreement, - MUST support the mqvSinglePass-sha256kdf-scheme key agreement,
the id-aes128-wrap key wrap, and the id-aes128-ccm the id-aes128-wrap key wrap, and the id-aes128-ccm
authenticated-content encryption; and, authenticated-content encryption; and,
- MAY support the mqvSinglePass-sha1kdf-scheme, mqvSinglePass- - MAY support the mqvSinglePass-sha1kdf-scheme, mqvSinglePass-
sha224kdf-scheme, mqvSinglePass-sha384kdf-scheme, and sha224kdf-scheme, mqvSinglePass-sha384kdf-scheme, and
mqvSinglePass-sha512kdf-scheme key agreement algorithms, the id- mqvSinglePass-sha512kdf-scheme key agreement algorithms, the id-
alg-CMS3DESwrap, id-aes192-wrap, and id-aes256-wrap key wrap alg-CMS3DESwrap, id-aes192-wrap, and id-aes256-wrap key wrap
algorithms, the id-aes192-ccm and id-aes256-ccm authenticated- algorithms, the id-aes192-ccm, id-aes256-ccm, id-aes128-gcm, id-
content encryption algorithms; other algorithms MAY also be aes192-gcm, and id-aes256-ccm authenticated-content encryption
supported. algorithms; other algorithms MAY also be supported.
9. Security Considerations 9. Security Considerations
Cryptographic algorithms will be broken or weakened over time. Cryptographic algorithms will be broken or weakened over time.
Implementers and users need to check that the cryptographic Implementers and users need to check that the cryptographic
algorithms listed in this document continue to provide the expected algorithms listed in this document continue to provide the expected
level of security. The IETF from time to time may issue documents level of security. The IETF from time to time may issue documents
dealing with the current state of the art. dealing with the current state of the art.
Cryptographic algorithms rely on random numbers. See [RANDOM] for Cryptographic algorithms rely on random numbers. See [RANDOM] for
skipping to change at page 28, line 35 skipping to change at page 29, line 4
sort of cryptographic resource management system to prevent such sort of cryptographic resource management system to prevent such
attacks. attacks.
Using secret keys of an appropriate size is crucial to the security Using secret keys of an appropriate size is crucial to the security
of a Diffie-Hellman exchange. For elliptic curve groups, the size of of a Diffie-Hellman exchange. For elliptic curve groups, the size of
the secret key must be equal to the size of n (the order of the group the secret key must be equal to the size of n (the order of the group
generated by the point g). Using larger secret keys provides generated by the point g). Using larger secret keys provides
absolutely no additional security, and using smaller secret keys is absolutely no additional security, and using smaller secret keys is
likely to result in dramatically less security. (See [SP800-56A] for likely to result in dramatically less security. (See [SP800-56A] for
more information on selecting secret keys.) more information on selecting secret keys.)
This specification is based on [CMS], [CMS-AES], [CMS-AESCG], [CMS- This specification is based on [CMS], [CMS-AES], [CMS-AESCG], [CMS-
ALG], [CMS-AUTHENV], [CMS-DH], [CMS-SHA2], [FIPS180-3], [FIPS186-3], ALG], [CMS-AUTHENV], [CMS-DH], [CMS-SHA2], [FIPS180-3], [FIPS186-3],
[HMAC-SHA1], and [HMAC-SHA2], and the appropriate security and [HMAC-SHA2], and the appropriate security considerations of those
considerations of those documents apply. documents apply.
In addition, implementers of AuthenticatedData and AuthEnvelopedData In addition, implementers of AuthenticatedData and AuthEnvelopedData
should be aware of the concerns expressed in [BON] when using should be aware of the concerns expressed in [BON] when using
AuthenticatedData and AuthEnvelopedData to send messages to more than AuthenticatedData and AuthEnvelopedData to send messages to more than
one recipient. Also, users of MQV should be aware of the one recipient. Also, users of MQV should be aware of the
vulnerability described in [K]. vulnerability described in [K].
When implementing EnvelopedData, AuthenticatedData, and When implementing EnvelopedData, AuthenticatedData, and
AuthEnvelopedData, there are five algorithm related choices that need AuthEnvelopedData, there are five algorithm related choices that need
to be made: to be made:
1) What is the public key size? 1) What is the public key size?
2) What is the KDF? 2) What is the KDF?
3) What is the key wrap algorithm? 3) What is the key wrap algorithm?
4) What is the content encryption algorithm? 4) What is the content encryption algorithm?
5) What is the curve? 5) What is the curve?
Consideration must be given to strength of the security provided by Consideration must be given to the strength of the security provided
each of these choices. Security is measured in bits, where a strong by each of these choices. Security is measured in bits, where a
symmetric cipher with a key of X bits is said to provide X bits of strong symmetric cipher with a key of X bits is said to provide X
security. It is recommended that the bits of security provided by bits of security. It is recommended that the bits of security
each are roughly equivalent. The following table provides comparable provided by each are roughly equivalent. The following table provides
minimum bits of security [SP800-57] for the ECDH/ECMQV key sizes, comparable minimum bits of security [SP800-57] for the ECDH/ECMQV key
KDFs, key wrapping algorithms, and content encryption algorithms. It sizes, KDFs, key wrapping algorithms, and content encryption
also lists curves [PKI-ALG] for the key sizes. algorithms. It also lists curves [PKI-ALG] for the key sizes.
Minimum | ECDH or | Key | Key | Content | Curves Minimum | ECDH or | Key | Key | Content | Curves
Bits of | ECQMV | Derivation | Wrap | Encryption | Bits of | ECQMV | Derivation | Wrap | Encryption |
Security | Key Size | Function | Alg. | Alg. | Security | Key Size | Function | Alg. | Alg. |
---------+----------+------------+----------+-------------+---------- ---------+----------+------------+----------+-------------+----------
80 | 160-223 | SHA-1 | 3DES | 3DES CBC | sect163k1 80 | 160-223 | SHA-1 | 3DES | 3DES CBC | sect163k1
| | SHA-224 | AES-128 | AES-128 CBC | secp163r2 | | SHA-224 | AES-128 | AES-128 CBC | secp163r2
| | SHA-256 | AES-192 | AES-192 CBC | secp192r1 | | SHA-256 | AES-192 | AES-192 CBC | secp192r1
| | SHA-384 | AES-256 | AES-256 CBC | | | SHA-384 | AES-256 | AES-256 CBC |
| | SHA-512 | | | | | SHA-512 | | |
skipping to change at page 34, line 9 skipping to change at page 34, line 9
progress. progress.
[FIPS180-3] National Institute of Standards and Technology [FIPS180-3] National Institute of Standards and Technology
(NIST), FIPS Publication 180-3: Secure Hash Standard, (NIST), FIPS Publication 180-3: Secure Hash Standard,
October 2008. October 2008.
[FIPS186-3] National Institute of Standards and Technology [FIPS186-3] National Institute of Standards and Technology
(NIST), FIPS Publication 186-3: Digital Signature (NIST), FIPS Publication 186-3: Digital Signature
Standard, (draft) November 2008. Standard, (draft) November 2008.
[HMAC-SHA1] Krawczyk, M., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[HMAC-SHA2] Nystrom, M., "Identifiers and Test Vectors for HMAC- [HMAC-SHA2] Nystrom, M., "Identifiers and Test Vectors for HMAC-
SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA- SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-
512", RFC 4231, December 2005. 512", RFC 4231, December 2005.
[MUST] Bradner, S., "Key Words for Use in RFCs to Indicate [MUST] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[MSG] Ramsdell, B., and S. Turner, "S/MIME Version 3.2 [MSG] Ramsdell, B., and S. Turner, "S/MIME Version 3.2
Message Specification", draft-ietf-smime-3851bis, Message Specification", draft-ietf-smime-3851bis,
work-in-progress. work-in-progress.
[PKI] Cooper, D., Santesson, S., Farrell, S., Boeyen, S. [PKI] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 5280, May 2008. List (CRL) Profile", RFC 5280, May 2008.
[PKI-ALG] Turner, S., Brown, D., Yiu, K., Housley, R., and W. [PKI-ALG] Turner, S., Brown, D., Yiu, K., Housley, R., and W.
Polk, "Elliptic Curve Cryptography Subject Public Key Polk, "Elliptic Curve Cryptography Subject Public Key
Information", draft-ietf-pkix-ecc-subpubkeyinfo, Information", RFC 5480, March 2009.
work-in-progress.
[RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller, [RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller,
"Randomness Recommendations for Security", RFC 4086, "Randomness Recommendations for Security", RFC 4086,
June 2005. June 2005.
[RSAOAEP] Schaad, J., Kaliski, B., and R. Housley, "Additional [RSAOAEP] Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for Algorithms and Identifiers for RSA Cryptography for
use in the Internet X.509 Public Key Infrastructure use in the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Certificate and Certificate Revocation List (CRL)
Profile", RFC 4055, June 2005. Profile", RFC 4055, June 2005.
skipping to change at page 37, line 4 skipping to change at page 36, line 43
IMPORTS IMPORTS
-- From [PKI] -- From [PKI]
AlgorithmIdentifier AlgorithmIdentifier
FROM PKIX1Explicit88 FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6) { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) mod(0) internet(1) security(5) mechanisms(5) pkix(7) mod(0)
pkix1-explicit(18) } pkix1-explicit(18) }
-- From [RSAOAEP] -- From [RSAOAEP]
id-sha224, id-sha256, id-sha384, id-sha512 id-sha224, id-sha256, id-sha384, id-sha512
FROM PKIX1-PSS-OAEP-Algorithms FROM PKIX1-PSS-OAEP-Algorithms
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-rsa-pkalgs(33) } id-mod-pkix1-rsa-pkalgs(33) }
-- From [PKI-ALG] -- From [PKI-ALG]
id-sha1, ecdsa-with-SHA1, ecdsa-with-SHA224, id-sha1, ecdsa-with-SHA1, ecdsa-with-SHA224,
ecdsa-with-SHA256, ecdsa-with-SHA384, ecdsa-with-SHA512, ecdsa-with-SHA256, ecdsa-with-SHA384, ecdsa-with-SHA512,
id-ecPublicKey, ECDSA-Sig-Value, ECPoint, ECParameters id-ecPublicKey, ECDSA-Sig-Value, ECPoint, ECParameters
FROM PKIXAlgIDs-2008 FROM PKIXAlgIDs-2008
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) TBA2 } security(5) mechanisms(5) pkix(7) id-mod(0) TBA1 }
-- From [CMS] -- From [CMS]
OriginatorPublicKey, UserKeyingMaterial OriginatorPublicKey, UserKeyingMaterial
FROM CryptographicMessageSyntax2004 FROM CryptographicMessageSyntax2004
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms-2004(24) } smime(16) modules(0) cms-2004(24) }
-- From [CMS-ALG] -- From [CMS-ALG]
hMAC-SHA1, id-hmacWithSHA224, id-hmacWithSHA256, id-hmacWithSHA384, hMAC-SHA1, id-hmacWithSHA224, id-hmacWithSHA256, id-hmacWithSHA384,
id-hmacWithSHA512, des-ede3-cbc, id-alg-CMS3DESwrap, CBCParameter id-hmacWithSHA512, des-ede3-cbc, id-alg-CMS3DESwrap, CBCParameter
FROM CryptographicMessageSyntaxAlgorithms FROM CryptographicMessageSyntaxAlgorithms
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cmsalg-2008(TBA3) } smime(16) modules(0) cmsalg-2008(TBD) }
-- From [CMS-AES] -- From [CMS-AES]
id-aes128-CBC, id-aes192-CBC, id-aes256-CBC, AES-IV, id-aes128-CBC, id-aes192-CBC, id-aes256-CBC, AES-IV,
id-aes128-wrap, id-aes192-wrap, id-aes256-wrap id-aes128-wrap, id-aes192-wrap, id-aes256-wrap
FROM CMSAesRsaesOaep FROM CMSAesRsaesOaep
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cms-aes(19) } smime(16) modules(0) id-mod-cms-aes(19) }
-- From [CMS-AESCG] -- From [CMS-AESCG]
id-aes128-CCM, id-aes192-CCM, id-aes256-CCM, CCMParameters id-aes128-CCM, id-aes192-CCM, id-aes256-CCM, CCMParameters
id-aes128-GCM, id-aes192-GCM, id-aes256-GCM, GCMParameters id-aes128-GCM, id-aes192-GCM, id-aes256-GCM, GCMParameters
FROM CMS-AES-CCM-and-AES-GCM FROM CMS-AES-CCM-and-AES-GCM
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cms-aes(32) } smime(16) modules(0) id-mod-cms-aes(32) }
;
;
-- --
-- Message Digest Algorithms -- Message Digest Algorithms
-- --
-- id-sha1 Parameters are preferred absent -- id-sha1 Parameters are preferred absent
-- id-sha224 Parameters are preferred absent -- id-sha224 Parameters are preferred absent
-- id-sha256 Parameters are preferred absent -- id-sha256 Parameters are preferred absent
-- id-sha384 Parameters are preferred absent -- id-sha384 Parameters are preferred absent
-- id-sha512 Parameters are preferred absent -- id-sha512 Parameters are preferred absent
skipping to change at page 43, line 20 skipping to change at page 43, line 20
-- mqvSinglePass-sha256kdf Type is the KeyWrapAlgorithm -- mqvSinglePass-sha256kdf Type is the KeyWrapAlgorithm
-- mqvSinglePass-sha384kdf Type is the KeyWrapAlgorithm -- mqvSinglePass-sha384kdf Type is the KeyWrapAlgorithm
-- mqvSinglePass-sha512kdf Type is the KeyWrapAlgorithm -- mqvSinglePass-sha512kdf Type is the KeyWrapAlgorithm
END END
Appendix A.2 2004 ASN.1 Module Appendix A.2 2004 ASN.1 Module
SMIMEECCAlgs-2008 SMIMEECCAlgs-2008
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) TBA4 } smime(16) modules(0) TBA2 }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS ALL -- EXPORTS ALL
IMPORTS IMPORTS
-- From [PKI-ALG] -- From [PKI-ALG]
mda-sha1, sa-ecdsaWithSHA1, sa-ecdsaWithSHA224, sa-ecdsaWithSHA256, mda-sha1, sa-ecdsaWithSHA1, sa-ecdsaWithSHA224, sa-ecdsaWithSHA256,
sa-ecdsaWithSHA384, sa-ecdsaWithSHA512, id-ecPublicKey, sa-ecdsaWithSHA384, sa-ecdsaWithSHA512, id-ecPublicKey,
ECDSA-Sig-Value, ECPoint, ECParameters ECDSA-Sig-Value, ECPoint, ECParameters
FROM PKIXAlgIDs-2008 FROM PKIXAlgIDs-2008
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) TBA5 } security(5) mechanisms(5) pkix(7) id-mod(0) TBA2 }
-- FROM [PKI-ASN] -- FROM [PKI-ASN]
KEY-WRAP, SIGNATURE-ALGORITHM, DIGEST-ALGORITHM, ALGORITHM, KEY-WRAP, SIGNATURE-ALGORITHM, DIGEST-ALGORITHM, ALGORITHM,
PUBLIC-KEY, MAC-ALGORITHM, CONTENT-ENCRYPTION, KEY-AGREE PUBLIC-KEY, MAC-ALGORITHM, CONTENT-ENCRYPTION, KEY-AGREE
FROM AlgorithmInformation FROM AlgorithmInformation
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation(TBA6) } id-mod-algorithmInformation(TBA5) }
-- From [PKI-ASN] -- From [PKI-ASN]
mda-sha224, mda-sha256, mda-sha384, mda-sha512 mda-sha224, mda-sha256, mda-sha384, mda-sha512
FROM PKIX1-PSS-OAEP-Algorithms FROM PKIX1-PSS-OAEP-Algorithms
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) TBA7 } security(5) mechanisms(5) pkix(7) id-mod(0) TBA7 }
-- From [CMS] -- From [CMS]
OriginatorPublicKey, UserKeyingMaterial OriginatorPublicKey, UserKeyingMaterial
skipping to change at page 48, line 13 skipping to change at page 48, line 13
secg-scheme 11 3 } secg-scheme 11 3 }
-- --
-- Diffie-Hellman Single Pass, Cofactor, with KDFs -- Diffie-Hellman Single Pass, Cofactor, with KDFs
-- --
kaa-dhSinglePass-cofactorDH-sha1kdf-scheme KEY-AGREE ::= { kaa-dhSinglePass-cofactorDH-sha1kdf-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-cofactorDH-sha1kdf-scheme IDENTIFIER dhSinglePass-cofactorDH-sha1kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required PARAMS TYPE KeyWrapAlgorithm ARE required
UKM TYPE -- unencoded data -- IS preferredPresent UKM TYPE -- unencoded data -- IS preferredPresent
SMIME CAPS { TYPE KeyWrapAlgorithm SMIME CAPS { TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-cofactorDH-sha1kdf-scheme } IDENTIFIED BY
dhSinglePass-cofactorDH-sha1kdf-scheme }
} }
dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 3 } x9-63-scheme 3 }
kaa-dhSinglePass-cofactorDH-sha224kdf-scheme KEY-AGREE ::= { kaa-dhSinglePass-cofactorDH-sha224kdf-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-cofactorDH-sha224kdf-scheme IDENTIFIER dhSinglePass-cofactorDH-sha224kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required PARAMS TYPE KeyWrapAlgorithm ARE required
UKM TYPE -- unencoded data -- IS preferredPresent UKM TYPE -- unencoded data -- IS preferredPresent
SMIME CAPS { TYPE KeyWrapAlgorithm SMIME CAPS { TYPE KeyWrapAlgorithm
skipping to change at page 56, line 20 skipping to change at page 56, line 20
de Rooij for his patient assistance. The technical comments of de Rooij for his patient assistance. The technical comments of
Francois Rousseau were valuable contributions. Francois Rousseau were valuable contributions.
Many thanks go out to the other authors of RFC 3278: Simon Blake- Many thanks go out to the other authors of RFC 3278: Simon Blake-
Wilson and Paul Lambert. Without RFC 3278 this version wouldn't Wilson and Paul Lambert. Without RFC 3278 this version wouldn't
exist. exist.
The authors also wish to thank Alfred Hoenes, Paul Hoffman, Russ The authors also wish to thank Alfred Hoenes, Paul Hoffman, Russ
Housley, and Jim Schaad for their valuable input. Housley, and Jim Schaad for their valuable input.
Author's Addresses Authors' Addresses
Sean Turner Sean Turner
IECA, Inc. IECA, Inc.
3057 Nutley Street, Suite 106 3057 Nutley Street, Suite 106
Fairfax, VA 22031 Fairfax, VA 22031
USA USA
Email: turners@ieca.com Email: turners@ieca.com
 End of changes. 85 change blocks. 
166 lines changed or deleted 178 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/