draft-ietf-smime-3278bis-04.txt   draft-ietf-smime-3278bis-05.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 December 11, 2008 Intended Status: Informational January 5, 2009
Obsoletes: 3278 (once approved) Obsoletes: 3278 (once approved)
Expires: June 11, 2009 Expires: July 5, 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-04.txt draft-ietf-smime-3278bis-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 11, 2008. This Internet-Draft will expire on June 5, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
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 23 skipping to change at page 2, line 30
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..................................3
2. SignedData using ECC...........................................3 2. SignedData using ECC...........................................3
2.1. SignedData using ECDSA....................................3 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..........................7
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.....................10
4.2. AuthEnvelopedData using 1-pass ECMQV.....................11 4.2. AuthEnvelopedData using 1-pass ECMQV.....................11
5. Certificates using ECC........................................12 5. Certificates using ECC........................................12
6. SMIMECapabilities Attribute and ECC...........................12 6. SMIMECapabilities Attribute and ECC...........................12
7. ASN.1 Syntax..................................................20 7. ASN.1 Syntax..................................................20
7.1. Algorithm Identifiers....................................20 7.1. Algorithm Identifiers....................................20
skipping to change at page 5, line 26 skipping to change at page 5, line 34
static-static DH, which is specified in [CMS-ALG]. Ephemeral-static static-static DH, which is specified in [CMS-ALG]. Ephemeral-static
ECDH and 1-Pass ECMQV were specified because they provide better ECDH and 1-Pass ECMQV were specified because they provide better
security due to the originator's ephemeral contribution to the key security due to the originator's ephemeral contribution to the key
agreement scheme. agreement scheme.
3.1. EnvelopedData using (ephemeral-static) ECDH 3.1. EnvelopedData using (ephemeral-static) ECDH
This section describes how to use the ephemeral-static Elliptic Curve This section describes how to use the ephemeral-static Elliptic Curve
Diffie-Hellman (ECDH) key agreement algorithm with EnvelopedData, Diffie-Hellman (ECDH) key agreement algorithm with EnvelopedData,
method C(1, 1, ECC CDH) from [SP800-56A] and ECDH with the standard method C(1, 1, ECC CDH) from [SP800-56A] and ECDH with the standard
primitive from Section 3.3.1 [SEC1]. Ephemeral-static ECDH is the primitive from Section 3.3.1 of [SEC1]. Ephemeral-static ECDH is the
elliptic curve analog of the ephemeral-static Diffie-Hellman key elliptic curve analog of the ephemeral-static Diffie-Hellman key
agreement algorithm specified jointly in the documents [CMS-ALG] and agreement algorithm specified jointly in the documents [CMS-ALG] and
[CMS-DH]. [CMS-DH].
If an implementation uses ECDH with CMS EnvelopedData, then the If an implementation uses ECDH with CMS EnvelopedData, then the
following techniques and formats MUST be used. following techniques and formats MUST be used.
The fields of EnvelopedData are as in [CMS], as ECDH is a key The fields of EnvelopedData are as in [CMS]; as ECDH is a key
agreement algorithm the RecipientInfo kari choice is used. agreement algorithm, the RecipientInfo kari choice is used.
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.3). The parameters
associated with id-ecPublicKey MUST be absent or ECParameters. associated with id-ecPublicKey MUST be absent or ECParameters.
NOTE: The previous version of this document required NULL to be NOTE: The previous version of this document required NULL to be
present, support for this legacy form is OPTIONAL. The present; support for this legacy form is OPTIONAL. The
originatorKey publicKey field MUST contain the value of the originatorKey publicKey field MUST contain the value of the
ASN.1 type ECPoint (see Section 7.2), which represents the ASN.1 type ECPoint (see Section 7.2), which represents the
sending agent's ephemeral EC public key. The ECPoint in sending agent's ephemeral EC public key. The ECPoint in
uncompressed form MUST be supported. 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
derivation function (see Section 7.2). derivation function (see Section 7.2).
- keyEncryptionAlgorithm MUST contain the key encryption algorithm, - keyEncryptionAlgorithm MUST contain the object identifier of the
which in this case is a key agreement algorithm, object key encryption algorithm, which in this case is a key agreement
identifier (see Section 7.1.4). The parameters field contains algorithm (see Section 7.1.4). The parameters field contains
KeyWrapAlgorithm. The KeyWrapAlgorithm is the algorithm KeyWrapAlgorithm. The KeyWrapAlgorithm is the algorithm
identifier that indicates the symmetric encryption algorithm identifier that indicates the symmetric encryption algorithm
used to encrypt the content-encryption key (CEK) with the key- used to encrypt the content-encryption key (CEK) with the key-
encryption key (KEK) and any associated parameters (see Section encryption key (KEK) and any associated parameters (see Section
7.1.5). Algorithm requirements are found in Section 8. 7.1.5). Algorithm requirements are found in Section 8.
- recipientEncryptedKeys contains an identifier and an encrypted - recipientEncryptedKeys contains an identifier and an encrypted
key for each recipient. The RecipientEncryptedKey key for each recipient. The RecipientEncryptedKey
KeyAgreeRecipientIdentifier MUST contain either the KeyAgreeRecipientIdentifier MUST contain either the
issuerAndSerialNumber identifying the recipient's certificate or issuerAndSerialNumber identifying the recipient's certificate or
skipping to change at page 6, line 50 skipping to change at page 7, line 11
When using ephemeral-static ECDH with EnvelopedData, the sending When using ephemeral-static ECDH with EnvelopedData, the sending
agent first obtains the recipient's EC public key and domain agent first obtains the recipient's EC public key and domain
parameters (e.g. from the recipient's certificate). The sending parameters (e.g. from the recipient's certificate). The sending
agent then determines an integer "keydatalen", which is the agent then determines an integer "keydatalen", which is the
KeyWrapAlgorithm symmetric key-size in bits, and also a bit string KeyWrapAlgorithm symmetric key-size in bits, and also a bit string
"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 has 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 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].
skipping to change at page 8, line 5 skipping to change at page 8, line 13
agent. Using an algorithm with the sender static key pair allows for agent. Using an algorithm with the sender static key pair allows for
knowledge of the message creator, this means that authentication can, knowledge of the message creator, this means that authentication can,
in some circumstances, be obtained for AuthEnvelopedData and in some circumstances, be obtained for AuthEnvelopedData and
AuthenticatedData. This means that 1-Pass ECMQV can be a common AuthenticatedData. This means that 1-Pass ECMQV can be a common
algorithm for EnvelopedData, AuthenticatedData and AuthEnvelopedData, algorithm for EnvelopedData, AuthenticatedData and AuthEnvelopedData,
while ECDH can only be used in EnvelopedData. while ECDH can only be used in EnvelopedData.
If an implementation uses 1-Pass ECMQV with CMS EnvelopedData, then If an implementation uses 1-Pass ECMQV with CMS EnvelopedData, then
the following techniques and formats MUST be used. the following techniques and formats MUST be used.
The fields of EnvelopedData are as in [CMS], as 1-Pass ECMQV is a key The fields of EnvelopedData are as in [CMS]; as 1-Pass ECMQV is a key
agreement algorithm the RecipientInfo kari choice is used. When agreement algorithm, the RecipientInfo kari choice is used. When
using 1-Pass ECMQV, the EnvelopedData originatorInfo field MAY using 1-Pass ECMQV, the EnvelopedData originatorInfo field MAY
include the certificate(s) for the EC public key(s) used in the include the certificate(s) for the EC public key(s) used in the
formation of the pairwise key. ECC certificates are discussed in formation of the pairwise key. ECC certificates are discussed in
Section 5. Section 5.
3.2.1. Fields of KeyAgreeRecipientInfo 3.2.1. Fields of KeyAgreeRecipientInfo
When using 1-Pass ECMQV with EnvelopedData, the fields of When using 1-Pass ECMQV with EnvelopedData, the fields of
KeyAgreeRecipientInfo are: KeyAgreeRecipientInfo are:
skipping to change at page 8, line 30 skipping to change at page 8, line 38
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.3). The parameters associated with
id-ecPublicKey MUST be absent or ECParameters. NOTE: The id-ecPublicKey MUST be absent or ECParameters. NOTE: The
previous version of this document required NULL to be present, previous version of this document required NULL to be present;
support for this legacy form is OPTIONAL. The support for this legacy form is OPTIONAL. The
MQVuserKeyingMaterial ephemeralPublicKey publicKey field MUST MQVuserKeyingMaterial ephemeralPublicKey publicKey field MUST
contain the DER-encoding of the ASN.1 type ECPoint (see Section contain the DER-encoding of the ASN.1 type ECPoint (see Section
7.2) representing the sending agent's ephemeral EC public key. 7.2) representing the sending agent's ephemeral EC public key.
The MQVuserKeyingMaterial addedukm field, if present, contains 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 key encryption algorithm, - keyEncryptionAlgorithm MUST contain the object identifier of the
which in this case is a key agreement algorithm, object key encryption algorithm, which in this case is a key agreement
identifier (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.
- recipientEncryptedKeys contains an identifier and an encrypted - recipientEncryptedKeys contains an identifier and an encrypted
key for each recipient. The RecipientEncryptedKey key for each recipient. The RecipientEncryptedKey
KeyAgreeRecipientIdentifier MUST contain either the KeyAgreeRecipientIdentifier MUST contain either the
issuerAndSerialNumber identifying the recipient's certificate or issuerAndSerialNumber identifying the recipient's certificate or
skipping to change at page 10, line 4 skipping to change at page 10, line 12
determines the bit string "SharedInfo", which is the DER encoding of determines the bit string "SharedInfo", which is the DER encoding of
ECC-CMS-SharedInfo (see Section 7.2), and the integer "keydatalen" ECC-CMS-SharedInfo (see Section 7.2), and the integer "keydatalen"
from the key-size, in bits, of the KeyWrapAlgorithm. The receiving from the key-size, in bits, of the KeyWrapAlgorithm. The receiving
agent then retrieves the static and ephemeral EC public keys of the agent then retrieves the static and ephemeral EC public keys of the
originator, from the originator and ukm fields as described in originator, from the originator and ukm fields as described in
Section 3.2.1, and its static EC public key identified in the rid Section 3.2.1, and its static EC public key identified in the rid
field and checks that the originator's domain parameters are the same field and checks that the originator's domain parameters are the same
as the recipient's domain parameters. The receiving agent then as the recipient's domain parameters. The receiving agent then
performs the key agreement operation of the Elliptic Curve MQV Scheme performs the key agreement operation of the Elliptic Curve MQV Scheme
[SP800-56A], but uses the KDF defined in Section 3.6.1 of [SEC1]. As [SP800-56A], but uses the KDF defined in Section 3.6.1 of [SEC1]. As
a result, the receiving agent obtains a shared secret bit string "K" a result, the receiving agent obtains a shared secret bit string "K",
which is used as the pairwise key-encryption key to unwrap the CEK. which is used as the pairwise key-encryption key to unwrap the CEK.
4. AuthenticatedData and AuthEnvelopedData using ECC 4. AuthenticatedData and AuthEnvelopedData using ECC
This section describes how to use ECC algorithms with the CMS This section describes how to use ECC algorithms with the CMS
AuthenticatedData format. AuthenticatedData lacks non-repudiation, AuthenticatedData format. AuthenticatedData lacks non-repudiation,
and so in some instances is preferable to SignedData. (For example, and so in some instances is preferable to SignedData. (For example,
the sending agent might not want the message to be authenticated when the sending agent might not want the message to be authenticated when
forwarded.) forwarded.)
skipping to change at page 13, line 8 skipping to change at page 13, line 4
6. SMIMECapabilities Attribute and ECC 6. SMIMECapabilities Attribute and ECC
A sending agent MAY announce to receiving agents that it supports one A sending agent MAY announce to receiving agents that it supports one
or more of the ECC algorithms specified in this document by using the or more of the ECC algorithms specified in this document by using the
SMIMECapabilities signed attribute [MSG] in either a signed message SMIMECapabilities signed attribute [MSG] in either a signed message
or a certificate [CERTCAP]. or a certificate [CERTCAP].
The SMIMECapabilities attribute value indicates support for one of The SMIMECapabilities attribute value indicates support for one of
the ECDSA signature algorithms in a SEQUENCE with the capabilityID the ECDSA signature algorithms in a SEQUENCE with the capabilityID
field containing the object identifier ecdsa-with-SHA1 with NULL field containing the object identifier ecdsa-with-SHA1 with NULL
parameters and ecdsa-with-SHA1* (where * is 224, 256, 384, or 512) parameters and ecdsa-with-SHA* (where * is 224, 256, 384, or 512)
with absent parameters. The DER encodings are: with absent parameters. The DER encodings are:
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 S/MIMECapabilities 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
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,
skipping to change at page 21, line 9 skipping to change at page 21, line 9
Digest algorithm object identifiers are used in the SignedData Digest algorithm object identifiers are used in the SignedData
digestAlgorithms and digestAlgorithm fields and the AuthenticatedData digestAlgorithms and digestAlgorithm fields and the AuthenticatedData
digestAlgorithm field. The digest algorithms used in this document digestAlgorithm field. The digest algorithms used in this document
are: SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. The object are: SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. The object
identifiers and parameters associated with these algorithms are found identifiers and parameters associated with these algorithms are found
in [CMS-ALG] and [CMS-SHA2]. in [CMS-ALG] and [CMS-SHA2].
7.1.2. Originator Public Key 7.1.2. Originator Public Key
The KeyAgreeRecipientInfo originator field use the following object The KeyAgreeRecipientInfo originator field uses the following object
identifier to indicate an elliptic curve public key: identifier to indicate an elliptic curve public key:
id-ecPublicKey OBJECT IDENTIFIER ::= { id-ecPublicKey OBJECT IDENTIFIER ::= {
ansi-x9-62 keyType(2) 1 } ansi-x9-62 keyType(2) 1 }
where where
ansi-x9-62 OBJECT IDENTIFIER ::= { ansi-x9-62 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) 10045 } iso(1) member-body(2) us(840) 10045 }
skipping to change at page 21, line 40 skipping to change at page 21, line 40
7.1.3. Signature Algorithms 7.1.3. Signature Algorithms
Signature algorithm identifiers are used in the SignedData Signature algorithm identifiers are used in the SignedData
signatureAlgorithm and signature fields. The signature algorithms signatureAlgorithm and signature fields. The signature algorithms
used in this document are ECDSA with SHA-1, ECDSA with SHA-224, ECDSA used in this document are ECDSA with SHA-1, ECDSA with SHA-224, ECDSA
with SHA-256, ECDSA with SHA-384, and ECDSA with SHA-512. The object with SHA-256, ECDSA with SHA-384, and ECDSA with SHA-512. The object
identifiers and parameters associated with these algorithms are found identifiers and parameters associated with these algorithms are found
in [PKI-ALG]. in [PKI-ALG].
NOTE: [CMS-ECC] indicated the parameters were NULL. Support for NULL NOTE: [CMS-ECC] indicated the parameters were NULL. Support for this
parameters is OPTIONAL. legacy form is OPTIONAL.
7.1.4. Key Agreement Algorithms 7.1.4. Key Agreement Algorithms
Key agreement algorithms are used in EnvelopedData, Key agreement algorithms are used in EnvelopedData,
AuthenticatedData, and AuthEnvelopedData in the KeyAgreeRecipientInfo AuthenticatedData, and AuthEnvelopedData in the KeyAgreeRecipientInfo
keyEncryptionAlgorithm field. The following object identifiers keyEncryptionAlgorithm field. The following object identifiers
indicate the key agreement algorithms used in this document: indicate the key agreement algorithms used in this document:
dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 2 } x9-63-scheme 2 }
skipping to change at page 25, line 5 skipping to change at page 25, line 5
ECPoint ::= OCTET STRING ECPoint ::= OCTET STRING
When using ECMQV with EnvelopedData, AuthenticatedData, and When using ECMQV with EnvelopedData, AuthenticatedData, and
AuthEnvelopedData, the sending agent's ephemeral public key and AuthEnvelopedData, the sending agent's ephemeral public key and
additional keying material are encoded using the type: additional keying material are encoded using the type:
MQVuserKeyingMaterial ::= SEQUENCE { MQVuserKeyingMaterial ::= SEQUENCE {
ephemeralPublicKey OriginatorPublicKey, ephemeralPublicKey OriginatorPublicKey,
addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL } addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }
The ECPoint syntax is used to represent the ephemeral public key and The ECPoint syntax is used to represent the ephemeral public key and
is placed in the ephemeralPublicKey.publicKey field. The additional is placed in the ephemeralPublicKey publicKey field. The additional
user keying material is placed in the addedukm field. Then the user keying material is placed in the addedukm field. Then the
MQVuserKeyingMaterial value is DER-encoded and placed within the ukm MQVuserKeyingMaterial value is DER-encoded and placed within the ukm
field of EnvelopedData, AuthenticatedData, or AuthEnvelopedData. field of EnvelopedData, AuthenticatedData, or AuthEnvelopedData.
When using ECDH or ECMQV with EnvelopedData, AuthenticatedData, or When using ECDH or ECMQV with EnvelopedData, AuthenticatedData, or
AuthEnvelopedData, the key-encryption keys are derived by using the AuthEnvelopedData, the key-encryption keys are derived by using the
type: type:
ECC-CMS-SharedInfo ::= SEQUENCE { ECC-CMS-SharedInfo ::= SEQUENCE {
keyInfo AlgorithmIdentifier, keyInfo AlgorithmIdentifier,
skipping to change at page 28, line 45 skipping to change at page 28, line 45
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 [HMAC-SHA1], and [HMAC-SHA2], and the appropriate security
considerations of those documents apply. considerations of those 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 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?
skipping to change at page 36, line 18 skipping to change at page 36, line 18
structures described in this specification using ASN.1 as defined in structures described in this specification using ASN.1 as defined in
[X.680] for compilers that support the 1988 ASN.1. [X.680] for compilers that support the 1988 ASN.1.
Appendix A.2 provides an informative ASN.1 definitions for the Appendix A.2 provides an informative ASN.1 definitions for the
structures described in this specification using ASN.1 as defined in structures described in this specification using ASN.1 as defined in
[X.680], [X.681], [X.682], and [X.683] for compilers that support the [X.680], [X.681], [X.682], and [X.683] for compilers that support the
2002 ASN.1. This appendix contains the same information as Appendix 2002 ASN.1. This appendix contains the same information as Appendix
A.1 in a more recent (and precise) ASN.1 notation, however Appendix A.1 in a more recent (and precise) ASN.1 notation, however Appendix
A.1 takes precedence in case of conflict. A.1 takes precedence in case of conflict.
NOTE: The values for the TBAs will be included during AUTH48.
//** RFC Editor: Remove this note prior to publication **//
Appendix A.1 1988 ASN.1 Module Appendix A.1 1988 ASN.1 Module
SMIMEECCAlgs-1988 SMIMEECCAlgs-1988
{ 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) TBA1 } smime(16) modules(0) TBA1 }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
skipping to change at page 36, line 39 skipping to change at page 37, line 4
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) TBA1 } security(5) mechanisms(5) pkix(7) id-mod(0) TBA2 }
-- 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(TBD) } smime(16) modules(0) cmsalg-2008(TBA3) }
-- 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]
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) TBA2 } smime(16) modules(0) TBA4 }
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) TBA2 } security(5) mechanisms(5) pkix(7) id-mod(0) TBA5 }
-- 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(TBA5) } id-mod-algorithmInformation(TBA6) }
-- 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 46, line 39 skipping to change at page 46, line 39
-- --
-- Diffie-Hellman Single Pass, Standard, with KDFs -- Diffie-Hellman Single Pass, Standard, with KDFs
-- --
-- Parameters are always present and indicate the Key Wrap Algorithm -- Parameters are always present and indicate the Key Wrap Algorithm
kaa-dhSinglePass-stdDH-sha1kdf-scheme KEY-AGREE ::= { kaa-dhSinglePass-stdDH-sha1kdf-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-stdDH-sha1kdf-scheme IDENTIFIER dhSinglePass-stdDH-sha1kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required PARAMS TYPE KeyWrapAlgorithm ARE required
UKM TYPE -- unecndoded data -- IS preferredPresent UKM TYPE -- unencoded data -- IS preferredPresent
SMIME CAPS { TYPE KeyWrapAlgorithm SMIME CAPS { TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-stdDH-sha1kdf-scheme } IDENTIFIED BY dhSinglePass-stdDH-sha1kdf-scheme }
} }
dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 2 } x9-63-scheme 2 }
kaa-dhSinglePass-stdDH-sha224kdf-scheme KEY-AGREE ::= { kaa-dhSinglePass-stdDH-sha224kdf-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-stdDH-sha224kdf-scheme IDENTIFIER dhSinglePass-stdDH-sha224kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required PARAMS TYPE KeyWrapAlgorithm ARE required
UKM TYPE -- unecndoded data -- IS preferredPresent UKM TYPE -- unencoded data -- IS preferredPresent
SMIME CAPS { TYPE KeyWrapAlgorithm SMIME CAPS { TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-stdDH-sha224kdf-scheme } IDENTIFIED BY dhSinglePass-stdDH-sha224kdf-scheme }
} }
dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 0 } secg-scheme 11 0 }
kaa-dhSinglePass-stdDH-sha256kdf-scheme KEY-AGREE ::= { kaa-dhSinglePass-stdDH-sha256kdf-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-stdDH-sha256kdf-scheme IDENTIFIER dhSinglePass-stdDH-sha256kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required PARAMS TYPE KeyWrapAlgorithm ARE required
UKM TYPE -- unecndoded data -- IS preferredPresent UKM TYPE -- unencoded data -- IS preferredPresent
SMIME CAPS { TYPE KeyWrapAlgorithm SMIME CAPS { TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-stdDH-sha256kdf-scheme } IDENTIFIED BY dhSinglePass-stdDH-sha256kdf-scheme }
} }
dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 1 } secg-scheme 11 1 }
kaa-dhSinglePass-stdDH-sha384kdf-scheme KEY-AGREE ::= { kaa-dhSinglePass-stdDH-sha384kdf-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-stdDH-sha384kdf-scheme IDENTIFIER dhSinglePass-stdDH-sha384kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required PARAMS TYPE KeyWrapAlgorithm ARE required
UKM TYPE -- unecndoded data -- IS preferredPresent UKM TYPE -- unencoded data -- IS preferredPresent
SMIME CAPS { TYPE KeyWrapAlgorithm SMIME CAPS { TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-stdDH-sha384kdf-scheme } IDENTIFIED BY dhSinglePass-stdDH-sha384kdf-scheme }
} }
dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 2 } secg-scheme 11 2 }
kaa-dhSinglePass-stdDH-sha512kdf-scheme KEY-AGREE ::= { kaa-dhSinglePass-stdDH-sha512kdf-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-stdDH-sha512kdf-scheme IDENTIFIER dhSinglePass-stdDH-sha512kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required PARAMS TYPE KeyWrapAlgorithm ARE required
UKM TYPE -- unecndoded data -- IS preferredPresent UKM TYPE -- unencoded data -- IS preferredPresent
SMIME CAPS { TYPE KeyWrapAlgorithm SMIME CAPS { TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-stdDH-sha512kdf-scheme } IDENTIFIED BY dhSinglePass-stdDH-sha512kdf-scheme }
} }
dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {
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 -- unecndoded 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 -- unecndoded data -- IS preferredPresent UKM TYPE -- unencoded data -- IS preferredPresent
SMIME CAPS { TYPE KeyWrapAlgorithm SMIME CAPS { TYPE KeyWrapAlgorithm
IDENTIFIED BY IDENTIFIED BY
dhSinglePass-cofactorDH-sha224kdf-scheme } dhSinglePass-cofactorDH-sha224kdf-scheme }
} }
dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 14 0 } secg-scheme 14 0 }
kaa-dhSinglePass-cofactorDH-sha256kdf-scheme KEY-AGREE ::= { kaa-dhSinglePass-cofactorDH-sha256kdf-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-cofactorDH-sha256kdf-scheme IDENTIFIER dhSinglePass-cofactorDH-sha256kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required PARAMS TYPE KeyWrapAlgorithm ARE required
UKM TYPE -- unecndoded data -- IS preferredPresent UKM TYPE -- unencoded data -- IS preferredPresent
SMIME CAPS { TYPE KeyWrapAlgorithm SMIME CAPS { TYPE KeyWrapAlgorithm
IDENTIFIED BY IDENTIFIED BY
dhSinglePass-cofactorDH-sha256kdf-scheme } dhSinglePass-cofactorDH-sha256kdf-scheme }
} }
dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 14 1 } secg-scheme 14 1 }
kaa-dhSinglePass-cofactorDH-sha384kdf-scheme KEY-AGREE ::= { kaa-dhSinglePass-cofactorDH-sha384kdf-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-cofactorDH-sha384kdf-scheme IDENTIFIER dhSinglePass-cofactorDH-sha384kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required PARAMS TYPE KeyWrapAlgorithm ARE required
UKM TYPE -- unecndoded data -- IS preferredPresent UKM TYPE -- unencoded data -- IS preferredPresent
SMIME CAPS { TYPE KeyWrapAlgorithm SMIME CAPS { TYPE KeyWrapAlgorithm
IDENTIFIED BY IDENTIFIED BY
dhSinglePass-cofactorDH-sha384kdf-scheme } dhSinglePass-cofactorDH-sha384kdf-scheme }
} }
dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 14 2 } secg-scheme 14 2 }
kaa-dhSinglePass-cofactorDH-sha512kdf-scheme KEY-AGREE ::= { kaa-dhSinglePass-cofactorDH-sha512kdf-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-cofactorDH-sha512kdf-scheme IDENTIFIER dhSinglePass-cofactorDH-sha512kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required PARAMS TYPE KeyWrapAlgorithm ARE required
UKM TYPE -- unecndoded data -- IS preferredPresent UKM TYPE -- unencoded data -- IS preferredPresent
SMIME CAPS { TYPE KeyWrapAlgorithm SMIME CAPS { TYPE KeyWrapAlgorithm
IDENTIFIED BY IDENTIFIED BY
dhSinglePass-cofactorDH-sha512kdf-scheme } dhSinglePass-cofactorDH-sha512kdf-scheme }
} }
dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 14 3 } secg-scheme 14 3 }
-- --
-- MQV Single Pass, Cofactor, with KDFs -- MQV Single Pass, Cofactor, with KDFs
-- --
kaa-mqvSinglePass-sha1kdf-scheme KEY-AGREE ::= { kaa-mqvSinglePass-sha1kdf-scheme KEY-AGREE ::= {
IDENTIFIER mqvSinglePass-sha1kdf-scheme IDENTIFIER mqvSinglePass-sha1kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required PARAMS TYPE KeyWrapAlgorithm ARE required
UKM TYPE -- unecndoded data -- IS preferredPresent UKM TYPE -- unencoded data -- IS preferredPresent
SMIME CAPS { TYPE KeyWrapAlgorithm SMIME CAPS { TYPE KeyWrapAlgorithm
IDENTIFIED BY mqvSinglePass-sha1kdf-scheme } IDENTIFIED BY mqvSinglePass-sha1kdf-scheme }
} }
mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= { mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 16 } x9-63-scheme 16 }
kaa-mqvSinglePass-sha224kdf-scheme KEY-AGREE ::= { kaa-mqvSinglePass-sha224kdf-scheme KEY-AGREE ::= {
IDENTIFIER mqvSinglePass-sha224kdf-scheme IDENTIFIER mqvSinglePass-sha224kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required PARAMS TYPE KeyWrapAlgorithm ARE required
UKM TYPE -- unecndoded data -- IS preferredPresent UKM TYPE -- unencoded data -- IS preferredPresent
SMIME CAPS { TYPE KeyWrapAlgorithm SMIME CAPS { TYPE KeyWrapAlgorithm
IDENTIFIED BY mqvSinglePass-sha224kdf-scheme } IDENTIFIED BY mqvSinglePass-sha224kdf-scheme }
} }
mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= { mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 15 0 } secg-scheme 15 0 }
kaa-mqvSinglePass-sha256kdf-scheme KEY-AGREE ::= { kaa-mqvSinglePass-sha256kdf-scheme KEY-AGREE ::= {
IDENTIFIER mqvSinglePass-sha256kdf-scheme IDENTIFIER mqvSinglePass-sha256kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required PARAMS TYPE KeyWrapAlgorithm ARE required
UKM TYPE -- unecndoded data -- IS preferredPresent UKM TYPE -- unencoded data -- IS preferredPresent
SMIME CAPS { TYPE KeyWrapAlgorithm SMIME CAPS { TYPE KeyWrapAlgorithm
IDENTIFIED BY mqvSinglePass-sha256kdf-scheme } IDENTIFIED BY mqvSinglePass-sha256kdf-scheme }
} }
mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= { mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 15 1 } secg-scheme 15 1 }
kaa-mqvSinglePass-sha384kdf-scheme KEY-AGREE ::= { kaa-mqvSinglePass-sha384kdf-scheme KEY-AGREE ::= {
IDENTIFIER mqvSinglePass-sha384kdf-scheme IDENTIFIER mqvSinglePass-sha384kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required PARAMS TYPE KeyWrapAlgorithm ARE required
UKM TYPE -- unecndoded data -- IS preferredPresent UKM TYPE -- unencoded data -- IS preferredPresent
SMIME CAPS { TYPE KeyWrapAlgorithm SMIME CAPS { TYPE KeyWrapAlgorithm
IDENTIFIED BY mqvSinglePass-sha384kdf-scheme } IDENTIFIED BY mqvSinglePass-sha384kdf-scheme }
} }
mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= { mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 15 2 } secg-scheme 15 2 }
kaa-mqvSinglePass-sha512kdf-scheme KEY-AGREE ::= { kaa-mqvSinglePass-sha512kdf-scheme KEY-AGREE ::= {
IDENTIFIER mqvSinglePass-sha512kdf-scheme IDENTIFIER mqvSinglePass-sha512kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required PARAMS TYPE KeyWrapAlgorithm ARE required
UKM TYPE -- unecndoded data -- IS preferredPresent UKM TYPE -- unencoded data -- IS preferredPresent
SMIME CAPS { TYPE KeyWrapAlgorithm SMIME CAPS { TYPE KeyWrapAlgorithm
IDENTIFIED BY mqvSinglePass-sha512kdf-scheme } IDENTIFIED BY mqvSinglePass-sha512kdf-scheme }
} }
mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= { mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 15 3 } secg-scheme 15 3 }
-- --
-- Key Wrap Algorithms -- Key Wrap Algorithms
-- --
skipping to change at page 51, line 41 skipping to change at page 51, line 41
-- --
-- Message Authentication Code Algorithms -- Message Authentication Code Algorithms
-- --
-- Constrains the AuthenticatedData -- Constrains the AuthenticatedData
-- MessageAuthenticationCodeAlgorithm field -- MessageAuthenticationCodeAlgorithm field
-- --
-- MessageAuthenticationCodeAlgorithms MAC-ALGORITHM ::= { -- MessageAuthenticationCodeAlgorithms MAC-ALGORITHM ::= {
-- maca-sha1 | -- maca-hMAC-SHA1 |
-- maca-sha224 | -- maca-hMAC-SHA224 |
-- maca-sha256 | -- maca-hMAC-SHA256 |
-- maca-sha384 | -- maca-hMAC-SHA384 |
-- maca-sha512, -- maca-hMAC-SHA512,
-- ... -- Extensible -- ... -- Extensible
-- } -- }
-- --
-- Originator Public Key Algorithms -- Originator Public Key Algorithms
-- --
-- Constraints on KeyAgreeRecipientInfo OriginatorIdentifierOrKey -- Constraints on KeyAgreeRecipientInfo OriginatorIdentifierOrKey
-- OriginatorPublicKey algorithm field -- OriginatorPublicKey algorithm field
-- PARAMS are NULL -- PARAMS are NULL
skipping to change at page 53, line 21 skipping to change at page 53, line 21
} }
END END
Appendix B Changes since RFC 3278 Appendix B Changes since RFC 3278
The following summarizes the changes: The following summarizes the changes:
- Abstract: The basis of the document was changed to refer to NIST - Abstract: The basis of the document was changed to refer to NIST
FIPS 186-3 and SP800-56A. However, to maintain backwards FIPS 186-3 and SP800-56A. However, to maintain backwards
capability the Key Derivation Function from ANSI/SEC1 is compatibility the Key Derivation Function from ANSI/SEC1 is
retained. retained.
- Section 1: A bullet was added to address AuthEnvelopedData. - Section 1: A bullet was added to address AuthEnvelopedData.
- Section 2.1: A sentence was added to indicate FIPS180-3 is used - Section 2.1: A sentence was added to indicate FIPS180-3 is used
with ECDSA. Replaced reference to ANSI X9.62 with FIPS186-3. with ECDSA. Replaced reference to ANSI X9.62 with FIPS186-3.
- Section 2.1.1: The permitted digest algorithms were expanded from - Section 2.1.1: The permitted digest algorithms were expanded from
SHA-1 to SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. SHA-1 to SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512.
- Section 2.1.2 and 2.1.3: The bullet addressing integer "e" was - Section 2.1.2 and 2.1.3: The bullet addressing integer "e" was
deleted. deleted.
- Section 3: Added explanation of why static-static ECDH is not - Section 3: Added explanation of why static-static ECDH is not
included. included.
- Section 3.1: The reference for DH was changed from CMS to CMS- - Section 3.1: The reference for DH was changed from RFC 3852 to
ALG. Provided text to indicate fields of EnvelopedData are as RFC 3370. Provided text to indicate fields of EnvelopedData are
in CMS. as in CMS.
- Section 3.1.1: The text was updated to include description of all - Section 3.1.1: The text was updated to include description of all
KeyAgreeRecipientInfo fields. Parameters for id-ecPublicKey KeyAgreeRecipientInfo fields. Parameters for id-ecPublicKey
field changed from NULL to absent or ECParameter. Additional field changed from NULL to absent or ECParameter. Additional
information about ukm was added. information about ukm was added.
- Section 3.2: The sentence describing the advantages of 1-Pass - Section 3.2: The sentence describing the advantages of 1-Pass
ECMQV was rewritten. ECMQV was rewritten.
- Section 3.2.1: The text was updated to include description of all - Section 3.2.1: The text was updated to include description of all
skipping to change at page 54, line 46 skipping to change at page 54, line 46
224, SHA-256, SHA-384, and SHA-512 algorithms as the KDF. 224, SHA-256, SHA-384, and SHA-512 algorithms as the KDF.
- Section 7.1 (formerly 8.1): Added sub-sections for digest, - Section 7.1 (formerly 8.1): Added sub-sections for digest,
signature, originator public key, key agreement, content signature, originator public key, key agreement, content
encryption, key wrap, and message authentication code encryption, key wrap, and message authentication code
algorithms. Pointed to algorithms and parameters in appropriate algorithms. Pointed to algorithms and parameters in appropriate
documents for: SHA-224, SHA-256, SHA-384, and SHA-512 as well as documents for: SHA-224, SHA-256, SHA-384, and SHA-512 as well as
SHA-224, SHA-256, SHA-384, and SHA-512 with ECDSA. Also added SHA-224, SHA-256, SHA-384, and SHA-512 with ECDSA. Also added
algorithm identifiers for ECDH std, ECDH cofactor, and ECMQV algorithm identifiers for ECDH std, ECDH cofactor, and ECMQV
with SHA-224, SHA-256, SHA-384, and SHA-512 algorithms as the with SHA-224, SHA-256, SHA-384, and SHA-512 algorithms as the
KDF. Changed id-ecPublicKey parameters to be absent, NULL, and KDF. Changed id-ecPublicKey parameters to be absent, NULL, or
ECParameters and if present the originator's ECParameters must ECParameters, and if present the originator's ECParameters must
match the recipient's ECParameters. match the recipient's ECParameters.
- Section 7.2 (formerly 8.2): Updated to include AuthEnvelopedData. - Section 7.2 (formerly 8.2): Updated to include AuthEnvelopedData.
Also, added text to address support requirement for compressed, Also, added text to address support requirement for compressed,
uncompressed, and hybrid keys, changed pointers from ANSI X9.61 uncompressed, and hybrid keys, changed pointers from ANSI X9.61
to PKIX (where ECDSA-Sig-Value is imported), changed pointers to PKIX (where ECDSA-Sig-Value is imported), changed pointers
from SECG to NIST specs, and updated example of suppPubInfo to from SECG to NIST specs, and updated example of suppPubInfo to
be AES-256. keyInfo's parameters changed from NULL to any be AES-256. keyInfo's parameters changed from NULL to any
associated parameters (AES wraps have absent parameters). associated parameters (AES wraps have absent parameters).
skipping to change at page 57, line 4 skipping to change at line 2403
Email: turners@ieca.com Email: turners@ieca.com
Daniel R. L. Brown Daniel R. L. Brown
Certicom Corp Certicom Corp
5520 Explorer Drive #400 5520 Explorer Drive #400
Mississauga, ON L4W 5L1 Mississauga, ON L4W 5L1
CANADA CANADA
Email: dbrown@certicom.com Email: dbrown@certicom.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 50 change blocks. 
64 lines changed or deleted 74 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/