draft-ietf-smime-ecc-03.txt   draft-ietf-smime-ecc-04.txt 
INTERNET-DRAFT Simon Blake-Wilson, Certicom Corp INTERNET-DRAFT Simon Blake-Wilson, Certicom Corp
draft-ietf-smime-ecc-03.txt Daniel R. L. Brown, Certicom Corp draft-ietf-smime-ecc-04.txt Daniel R. L. Brown, Certicom Corp
Paul Lambert, Cosine Communications Paul Lambert, Cosine Communications
2 March, 2001 Expires: 2 September, 2001 12 March, 2001 Expires: 12 September, 2001
Use of ECC Algorithms in CMS Use of ECC Algorithms in CMS
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are all provisions of Section 10 of RFC2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may also its areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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 ......................... 3
2.1.1 Fields of the SignedData ................ 3 2.1.1 Fields of the SignedData ................ 3
2.1.2 Actions of the sending agent ............ 4 2.1.2 Actions of the sending agent ............ 4
2.1.3 Actions of the receiving agent .......... 4 2.1.3 Actions of the receiving agent .......... 4
3 EnvelopedData using ECC ............................. 5 3 EnvelopedData using ECC ............................. 5
3.1 EnvelopedData using ECDH ....................... 5 3.1 EnvelopedData using ECDH ....................... 5
3.1.1 Fields of KeyAgreeRecipientInfo ......... 5 3.1.1 Fields of KeyAgreeRecipientInfo ......... 5
3.1.2 Actions of the sending agent ............ 5 3.1.2 Actions of the sending agent ............ 6
3.1.3 Actions of the receiving agent .......... 6 3.1.3 Actions of the receiving agent .......... 6
3.2 EnvelopedData using 1-Pass ECMQV ............... 6 3.2 EnvelopedData using 1-Pass ECMQV ............... 6
3.2.1 Fields of KeyAgreeRecipientInfo ......... 6 3.2.1 Fields of KeyAgreeRecipientInfo ......... 7
3.2.2 Actions of the sending agent ............ 7 3.2.2 Actions of the sending agent ............ 7
3.2.3 Actions of the receiving agent .......... 8 3.2.3 Actions of the receiving agent .......... 8
4 AuthenticatedData using ECC ............ ............ 8 4 AuthenticatedData using ECC ............ ............ 8
4.1 AuthenticatedData using 1-pass ECMQV ........... 8 4.1 AuthenticatedData using 1-pass ECMQV ........... 8
4.1.1 Fields of KeyAgreeRecipientInfo ......... 8 4.1.1 Fields of KeyAgreeRecipientInfo ......... 8
4.1.2 Actions of the sending agent ............ 8 4.1.2 Actions of the sending agent ............ 8
4.1.3 Actions of the receiving agent .......... 9 4.1.3 Actions of the receiving agent .......... 9
5 Recommended Algorithms and Elliptic Curves .......... 9 5 Recommended Algorithms and Elliptic Curves .......... 9
6 Certificates using ECC .............................. 9 6 Certificates using ECC .............................. 9
7 SMIMECapabilities Attribute and ECC ................. 9 7 SMIMECapabilities Attribute and ECC ................. 9
8 ASN.1 Syntax ........................................ 9 8 ASN.1 Syntax ........................................ 10
8.1 Algorithm identifiers .......................... 10 8.1 Algorithm identifiers .......................... 10
8.2 Other syntax ................................... 11 8.2 Other syntax ................................... 11
9 Summary ............................................. 12 9 Summary ............................................. 13
References ............................................. 12 References ............................................. 13
Security Considerations ................................ 14 Security Considerations ................................ 14
Intellectual Property Rights ........................... 14 Intellectual Property Rights ........................... 14
Acknowledgments ........................................ 14 Acknowledgments ........................................ 15
Authors' Address ....................................... 14 Authors' Addresses ..................................... 15
Full Copyright Statement ............................... 15 Full Copyright Statement ............................... 16
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 standard profile for the independent. This specification defines a standard profile for the
use of Elliptic Curve Cryptography (ECC) public key algorithms in use of Elliptic Curve Cryptography (ECC) public key algorithms in
the CMS. The ECC algorithms are incorporated into the following the CMS. The ECC algorithms are incorporated into the following
CMS content types: CMS content types:
- 'SignedData' to support ECC-based digital signature methods - 'SignedData' to support ECC-based digital signature methods
(ECDSA) to sign content (ECDSA) to sign content
- 'EnvelopedData' to support ECC-based public-key agreement - 'EnvelopedData' to support ECC-based public-key agreement
methods (ECDH and ECMQV) to generate pairwise key-encryption methods (ECDH and ECMQV) to generate pairwise key-encryption
keys to encrypt content-encryption keys used for content keys to encrypt content-encryption keys used for content
encryption encryption
- 'AuthenticatedData' to support ECC-based public-key agreement - 'AuthenticatedData' to support ECC-based public-key agreement
methods (ECMQV) to generate pairwise key-encryption keys to methods (ECMQV) to generate pairwise key-encryption keys to
encrypt MAC keys used for content authentication encrypt MAC keys used for content authentication and integrity
Certification of EC public keys is also described to provide Certification of EC public keys is also described to provide
public-key distribution in support of the specified techniques. public-key distribution in support of the specified techniques.
1.1 Requirements terminology 1.1 Requirements terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 this document are to be interpreted as described in RFC 2119
[MUST]. [MUST].
skipping to change at page 3, line 47 skipping to change at page 3, line 47
This section describes how to use ECC algorithms with the CMS This section describes how to use ECC algorithms with the CMS
SignedData format to sign data. SignedData format to sign data.
2.1 SignedData using ECDSA 2.1 SignedData using ECDSA
This section describes how to use the Elliptic Curve Digital This section describes how to use the Elliptic Curve Digital
Signature Algorithm (ECDSA) with SignedData. ECDSA is specified in Signature Algorithm (ECDSA) with SignedData. ECDSA is specified in
[X9.62]. The method is the elliptic curve analog of the [X9.62]. The method is the elliptic curve analog of the
Digital Signature Algorithm (DSA) [FIPS 186-2]. Digital Signature Algorithm (DSA) [FIPS 186-2].
In an implementation that uses ECDSA with CMS SignedData, the
following techniques and formats MUST be used.
2.1.1 Fields of the SignedData 2.1.1 Fields of the SignedData
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 contains the algorithm identifier sha-1 (see digestAlgorithm MUST contain the algorithm identifier sha-1 (see
Section 8.1) which identifies the SHA-1 hash algorithm. Section 8.1) which identifies the SHA-1 hash algorithm.
signatureAlgorithm contains the algorithm identifier signatureAlgorithm contains the algorithm identifier
ecdsa-with-SHA1 (see Section 8.1) which identifies the ECDSA ecdsa-with-SHA1 (see Section 8.1) which identifies the ECDSA
signature algorithm. signature algorithm.
signature contains the DER encoding (as an octet string) of a signature MUST contain the DER encoding (as an octet string) of
value of the ASN.1 type ECDSA-Sig-Value (see Section a value of the ASN.1 type ECDSA-Sig-Value (see Section 8.2).
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 certificate(s) for the EC public key(s) used in the generation of
the ECDSA signatures in SignedData. ECC certificates are discussed the ECDSA signatures in SignedData. ECC certificates are discussed
in Section 6. in Section 6.
2.1.2 Actions of the sending agent 2.1.2 Actions of the sending agent
When using ECDSA with SignedData, the sending agent uses the When using ECDSA with SignedData, the sending agent uses the
message digest calculation process and signature generation process message digest calculation process and signature generation process
for SignedData that are specified in [CMS]. To sign data, the for SignedData that are specified in [CMS]. To sign data, the
sending agent uses the signature method specified in [X9.62, sending agent uses the signature method specified in [X9.62,
Section 5.3] with the following exceptions: Section 5.3] with the following exceptions:
- In [X9.62, Section 5.3.1], the integer "e" shall instead be - In [X9.62, Section 5.3.1], the integer "e" is instead
determined by converting the octet string resulting from [CMS, determined by converting the message digest generated
Section 5.4] to an integer using the data conversion method in according to [CMS, Section 5.4] to an integer using the data
[X9.62, Section 4.3.2]. conversion method in [X9.62, Section 4.3.2].
The sending agent encodes the resulting signature using the The sending agent encodes the resulting signature using the
ECDSA-sig-value syntax and places it in the SignerInfo signature ECDSA-Sig-Value syntax (see Section 8.2) and places it in the
field. SignerInfo signature field.
2.1.3 Actions of the receiving agent 2.1.3 Actions of the receiving agent
When using ECDSA with SignedData, the receiving agent uses the When using ECDSA with SignedData, the receiving agent uses the
message digest calculation process and signature verification message digest calculation process and signature verification
process for SignedData that are specified in [CMS]. To verify process for SignedData that are specified in [CMS]. To verify
SignedData, the receiving agent uses the signature verification SignedData, the receiving agent uses the signature verification
method specified in [X9.62, Section 5.4] with the following method specified in [X9.62, Section 5.4] with the following
exceptions: exceptions:
- In [X9.62, Section 5.4.1] the integer "e" shall instead be - In [X9.62, Section 5.4.1] the integer "e'" is instead
determined by converting the octet string resulting from [CMS, determined by converting the message digest generated
Section 5.4] to an integer using the data conversion method in according to [CMS, Section 5.4] to an integer using the data
[X9.62, Section 4.3.2]. conversion method in [X9.62, Section 4.3.2].
In order to verify the signature, the receiving agent retrieves the In order to verify the signature, the receiving agent retrieves the
integers r and s from the SignerInfo signature field of the integers r and s from the SignerInfo signature field of the
received message. received message.
3 EnvelopedData using ECC Algorithms 3 EnvelopedData using ECC Algorithms
This section describes how to use ECC algorithms with the CMS This section describes how to use ECC algorithms with the CMS
EnvelopedData format. EnvelopedData format.
3.1 EnvelopedData using (ephemeral-static) ECDH 3.1 EnvelopedData using (ephemeral-static) ECDH
This section describes how to use ephemeral-static Elliptic Curve This section describes how to use ephemeral-static Elliptic Curve
Diffie-Hellman (ECDH) key agreement algorithm with EnvelopedData. Diffie-Hellman (ECDH) key agreement algorithm with EnvelopedData.
Ephemeral-static ECDH is specified in [X9.63]. Ephemeral-static Ephemeral-static ECDH is specified in [X9.63]. Ephemeral-static
ECDH is the the elliptic curve analog of the ephemeral-static ECDH is the elliptic curve analog of the ephemeral-static
Diffie-Hellman key agreement algorithm specified jointly in the Diffie-Hellman key agreement algorithm specified jointly in the
documents [CMS, Section 12.3.1.1] and [CMS-DH]. documents [CMS, Section 12.3.1.1] and [CMS-DH].
In an implementation that uses ECDH with CMS EnvelopedData with key
agreement, the following techniques and formats MUST be 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 in [CMS], but with the following KeyAgreeRecipientInfo are as in [CMS], but with the following
restrictions: restrictions:
originator is the alternative originatorKey. The originatorKey originator MUST be the alternative originatorKey. The
algorithm field contains the id-ecPublicKey object identifier originatorKey algorithm field MUST contain the id-ecPublicKey
(see Section 8.1) with NULL parameters. The originatorKey object identifier (see Section 8.1) with NULL parameters. The
publicKey field contains the DER-encoding of a value of the originatorKey publicKey field MUST contain the DER-encoding of a
ASN.1 type ECPoint (see Section 8.2). value of the ASN.1 type ECPoint (see Section 8.2), which
represents the sending agent's ephemeral EC public key.
keyEncryptionAlgorithm contains the keyEncryptionAlgorithm MUST contain the
dhSinglePass-stdDH-sha1kdf-scheme object identifier (see Section dhSinglePass-stdDH-sha1kdf-scheme object identifier (see Section
7.1) if standard ECDH primitive is used, or the 8.1) if standard ECDH primitive is used, or the
dhSinglePass-cofactorDH-sha1kdf-scheme object identifier (see dhSinglePass-cofactorDH-sha1kdf-scheme object identifier (see
Section 8.1) if the cofactor ECDH primitive is used. The Section 8.1) if the cofactor ECDH primitive is used. The
parameter field contains KeyWrapAlgorithm. The KeyWrapAlgorithm parameters field contains KeyWrapAlgorithm. The
is the algorithm identifier that indicates the symmetric KeyWrapAlgorithm is the algorithm identifier that indicates the
encryption algorithm used to encrypt the CEK with the KEK. symmetric encryption algorithm used to encrypt the CEK with the
KEK.
3.1.2 Actions of the sending agent 3.1.2 Actions of the sending agent
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
"SharedData", which is the DER encoding of ECC-CMS-SharedInfo (see "SharedData", which is the DER encoding of ECC-CMS-SharedInfo (see
Section 8.2). The sending agent then performs the initiator Section 8.2). The sending agent then performs the initiator
skipping to change at page 6, line 16 skipping to change at page 6, line 28
the type ECPoint (see Section 8.2), encapsulated in a bit the type ECPoint (see Section 8.2), encapsulated in a bit
string and placed in the KeyAgreeRecipientInfo originator string and placed in the KeyAgreeRecipientInfo originator
field, and field, and
- a shared secret bit string "KeyData" which is used as the - a shared secret bit string "KeyData" which is used as the
pairwise key-encryption key for that recipient. pairwise key-encryption key for that recipient.
3.1.3 Actions of the receiving agent 3.1.3 Actions of the receiving agent
When using ephemeral-static ECDH with EnvelopedData, the receiving When using ephemeral-static ECDH with EnvelopedData, the receiving
agent determines the bit string "SharedData" (see Section 8.2) and agent determines the bit string "SharedData", which is the DER
the integer "keydatalen" from the key-size, in bits, of the encoding of ECC-CMS-SharedInfo (see Section 8.2), and the integer
KeyWrapAlgorithm. The receiving agent retrieves the ephemeral EC "keydatalen" from the key-size, in bits, of the KeyWrapAlgorithm.
public key from the bit string KeyAgreeRecipientInfo originator, The receiving agent retrieves the ephemeral EC public key from the
which an value of the type ECPoint (see Section 8.2) encapsulated bit string KeyAgreeRecipientInfo originator, which an value of the
as a bit string. The receiving agent completes the responder type ECPoint (see Section 8.2) encapsulated as a bit string. The
transformation of the 1-Pass Diffie-Hellman scheme [X9.63, Section receiving agent completes the responder transformation of the
6.2.2]. As a result the receiving agent obtains a shared secret 1-Pass Diffie-Hellman scheme [X9.63, Section 6.2.2]. As a result
bit string "KeyData" which is used as the pairwise key-encryption the receiving agent obtains a shared secret bit string "KeyData"
key to unwrap the CEK. which is used as the pairwise key-encryption key to unwrap the CEK.
3.2 EnvelopedData using 1-Pass ECMQV 3.2 EnvelopedData 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 EnvelopedData. 1-Pass ECMQV (ECMQV) key agreement algorithm with EnvelopedData. 1-Pass ECMQV
is specified in [X9.63]. Like the KEA algorithm [CMS-KEA], 1-Pass is specified in [X9.63]. Like the KEA algorithm [CMS-KEA], 1-Pass
ECMQV uses three key pairs: an ephemeral key pair, a static key ECMQV uses three key pairs: an ephemeral key pair, a static key
pair of the sending agent, and a static key pair of the receiving pair of the sending agent, and a static key pair of the receiving
agent. An advantage of using 1-Pass ECMQV is that it may be used agent. An advantage of using 1-Pass ECMQV is that it can be used
with both EnvelopedData and AuthenticatedData. with both EnvelopedData and AuthenticatedData.
In an implementation that uses 1-Pass ECMQV with CMS EnvelopedData
with key agreement, the following techniques and formats MUST be
used.
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:
version is 3
originator identifies the static EC public key of the sender. originator identifies the static EC public key of the sender.
It should be the one of the alternatives issuerAndSerialNumber It SHOULD be the one of the alternatives issuerAndSerialNumber
or subjectKeyIdentifier and point to one of the sending agent's or subjectKeyIdentifier and point to one of the sending agent's
certificates supplied in the EnvelopedData originatorInfo field. certificates.
ukm is present. The ukm field contains an octet string which is ukm MUST be present. The ukm field MUST contain an octet string
the DER encoding of the type MQVuserKeyingMaterial (see Section which is the DER encoding of the type MQVuserKeyingMaterial (see
8.2). The MQVuserKeyingMaterial ephemeralPublicKey algorithm Section 8.2). The MQVuserKeyingMaterial ephemeralPublicKey
field contains the id-ecPublicKey object identifier (see Section algorithm field MUST contain the id-ecPublicKey object
8.1) with NULL parameters field. The MQVuserKeyingMaterial identifier (see Section 8.1) with NULL parameters field. The
ephemeralPublicKey publicKey field contains the DER-encoding of MQVuserKeyingMaterial ephemeralPublicKey publicKey field MUST
the ASN.1 type ECPoint representing sending agent's ephemeral EC contain the DER-encoding of the ASN.1 type ECPoint (see Section
public key. The MQVuserKeyingMaterial addedukm field, if 8.2) representing sending agent's ephemeral EC public key. The
present, contains an octet string of additional user keying MQVuserKeyingMaterial addedukm field, if present, SHOULD contain
material of the sending agent. an octet string of additional user keying material of the
sending agent.
keyEncryptionAlgorithm is the mqvSinglePass-sha1kdf-scheme keyEncryptionAlgorithm MUST be the mqvSinglePass-sha1kdf-scheme
algorithm identifier (see Section 8.1), with parameter field algorithm identifier (see Section 8.1), with parameters field
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. generated using the 1-Pass ECMQV algorithm.
3.2.2 Actions of the sending agent 3.2.2 Actions of the sending agent
When using 1-Pass ECMQV with EnvelopedData, the sending agent first When using 1-Pass ECMQV with EnvelopedData, the sending agent first
obtains the recipient's EC public key and domain parameters, obtains the recipient's EC public key and domain parameters,
(e.g. from the recipient's certificate) and checks that the domain (e.g. from the recipient's certificate) and checks that the domain
parameters are the same. The sending agent then determines an parameters are the same. The sending agent then determines an
skipping to change at page 7, line 42 skipping to change at page 7, line 53
ECMQV scheme specified in [X9.63, Section 6.9.1]. As a result the ECMQV scheme specified in [X9.63, Section 6.9.1]. As a result the
sending agent obtains sending agent obtains
- an ephemeral public key, which is represented as a value of - an ephemeral public key, which is represented as a value of
type ECPoint (see Section 8.2), encapsulated in a bit string, type ECPoint (see Section 8.2), encapsulated in a bit string,
placed in an MQVuserKeyingMaterial ephemeralPublicKey placed in an MQVuserKeyingMaterial ephemeralPublicKey
publicKey field (see Section 8.2), and publicKey field (see Section 8.2), and
- a shared secret bit string "KeyData" which is used as the - a shared secret bit string "KeyData" which is used as the
pairwise key-encryption key for that recipient. Parity bits pairwise key-encryption key for that recipient. Parity bits
are adjust according to the key wrap algorithm. are adjusted according to the key wrap algorithm.
The ephemeral public key may be re-used with an AuthenticatedData The ephemeral public key can be re-used with an AuthenticatedData
for greater efficiency. for greater efficiency.
3.2.3 Actions of the receiving agent 3.2.3 Actions of the receiving agent
When using 1-Pass ECMQV with EnvelopedData, the receiving agent When using 1-Pass ECMQV with EnvelopedData, the receiving agent
determines the bit string "SharedData" (see Section 8.2) and the determines the bit string "SharedData", which is the DER encoding
of ECC-CMS-SharedInfo (see Section 8.2), and the
integer "keydatalen" from the key-size, in bits, of the integer "keydatalen" from the key-size, in bits, of the
KeyWrapAlgorithm. The receiving agent then retrieves the static KeyWrapAlgorithm. The receiving agent then retrieves the static
and ephemeral EC public keys of the originator, from the originator and ephemeral EC public keys of the originator, from the originator
and ukm fields as described in Section 3.2.1, and its static EC and ukm fields as described in Section 3.2.1, and its static EC
public key identified in the rid field and checks that the domain public key identified in the rid field and checks that the domain
parameters are the same. The receiving agent then performs the parameters are the same. The receiving agent then performs the
responder transformation of the 1-Pass ECMQV scheme [X9.63, Section responder transformation of the 1-Pass ECMQV scheme [X9.63, Section
6.9.2]. As a result the receiving agent obtains a shared secret 6.9.2]. As a result the receiving agent obtains a shared secret
bit string "KeyData" which is used as the pairwise key-encryption bit string "KeyData" which is used as the pairwise key-encryption
key to unwrap the CEK. key to unwrap the CEK.
4 AuthenticatedData using ECC 4 AuthenticatedData 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 preferrable SignedData. (For example, and so in some instances is preferable to SignedData. (For
the sending agent may not want the message to be authenticated when example, the sending agent might not want the message to be
forwarded.) authenticated when forwarded.)
4.1 AuthenticatedData using 1-pass ECMQV 4.1 AuthenticatedData 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 AuthenticatedData. 1-Pass (ECMQV) key agreement algorithm with AuthenticatedData. 1-Pass
ECMQV is specified in [X9.63]. An advantage of using 1-Pass ECMQV ECMQV is specified in [X9.63]. An advantage of using 1-Pass ECMQV
is that it may be used with both EnvelopedData and is that it can be used with both EnvelopedData and
AuthenticatedData. AuthenticatedData.
4.1.1 Fields of the KeyAgreeRecipientInfo 4.1.1 Fields of the KeyAgreeRecipientInfo
The AuthenticatedData KeyAgreeRecipientInfo fields are used in the The AuthenticatedData KeyAgreeRecipientInfo fields are used in the
same manner as the fields for the corresponding EnvelopedData same manner as the fields for the corresponding EnvelopedData
KeyAgreeRecipientInfo fields of Section 3.2.1 of this document. KeyAgreeRecipientInfo fields of Section 3.2.1 of this document.
4.1.2 Actions of the sending agent 4.1.2 Actions of the sending agent
The sending agent uses the same actions as for EnvelopedData The sending agent uses the same actions as for EnvelopedData
with 1-Pass ECMQV, as specified in Section 3.2.2 of this document. with 1-Pass ECMQV, as specified in Section 3.2.2 of this document.
The ephemeral public key may be re-used with an EnvelopedData for The ephemeral public key can be re-used with an EnvelopedData for
greater efficiency. greater efficiency.
Note: if there are multiple recipients then an attack is possible Note: if there are multiple recipients then an attack is possible
where one recipient modifies the content without other recipients where one recipient modifies the content without other recipients
noticing [BON]. A sending agent who is concerned with such an noticing [BON]. A sending agent who is concerned with such an
attack should use a separate AuthenticatedData for each recipient. attack SHOULD use a separate AuthenticatedData for each recipient.
4.1.3 Actions of the receiving agent 4.1.3 Actions of the receiving agent
The receiving agent uses the same actions as for EnvelopedData The receiving agent uses the same actions as for EnvelopedData
with 1-Pass ECMQV, as specified in Section 3.2.3 of this document. with 1-Pass ECMQV, as specified in Section 3.2.3 of this document.
Note: see Note in Section 4.1.2. Note: see Note in Section 4.1.2.
5 Recommended Algorithms and Elliptic Curves 5 Recommended Algorithms and Elliptic Curves
Implementations of this specification SHOULD implement SignedData Implementations of this specification MUST implement either
with ECDSA and EnvelopedData with ECDH. Implementations MAY SignedData with ECDSA or EnvelopedData with ephemeral-static ECDH.
implement the other techniques specified. Implementations of this specification SHOULD implement both
SignedData with ECDSA and EnvelopedData with ephemeral-static ECDH.
Implementations MAY implement the other techniques specified, such
as AuthenticatedData and 1-Pass ECMQV.
Furthermore, in order to encourage interoperability, Furthermore, in order to encourage interoperability,
implementations SHOULD use the elliptic curve domain parameters implementations SHOULD use the elliptic curve domain parameters
recommended by ANSI [X9.62, X9.63], NIST [FIPS186-2] and SECG [SEC3]. specified by ANSI [X9.62, X9.63], NIST [FIPS-186-2] and SECG
[SEC2].
6 Certificates using ECC 6 Certificates using ECC
Internet X.509 certificates [PKI] may be used in conjunction with Internet X.509 certificates [PKI] can be used in conjunction with
this specification to distribute agents' public keys. The use of this specification to distribute agents' public keys. The use of
ECC algorithms and keys within X.509 certificates is specified in ECC algorithms and keys within X.509 certificates is specified in
[PKI-ALG]. More details can be found in [SEC3]. [PKI-ALG]. More details can be found in [SEC3].
7 SMIMECapabilities Attribute and ECC 7 SMIMECapabilities Attribute and ECC
A sending agent may choose to announce to receiving agents that it A sending agent MAY announce to receiving agents that it supports
supports one or more of the ECC algorithms in this document by one or more of the ECC algorithms in this document by using the
using the SMIMECapabilities signed attribute [MSG, Section 2.5.2]. SMIMECapabilities signed attribute [MSG, Section 2.5.2].
The SMIMECapability value to indicate support for the ECDSA The SMIMECapability value to indicate support for the ECDSA
signature algorithm is the SEQUENCE with the capabilityID field signature algorithm is the SEQUENCE with the capabilityID field
containing the object identifier ecdsa-with-SHA1 with NULL containing the object identifier ecdsa-with-SHA1 with NULL
parameters. parameters. The DER encoding is:
30 0b 06 07 2a 86 48 ce 3d 04 01 05 00
The SMIMECapability capabilityID object identifiers for the The SMIMECapability capabilityID object identifiers for the
supported key agreement algorithms in this document are supported key agreement algorithms in this document are
dhSinglePass-stdDH-sha1kdf-scheme, dhSinglePass-stdDH-sha1kdf-scheme,
dhSinglePass-cofactorDH-sha1kdf-scheme, and dhSinglePass-cofactorDH-sha1kdf-scheme, and
mqvSinglePass-sha1kdf-scheme. For each of these SMIMECapability mqvSinglePass-sha1kdf-scheme. For each of these SMIMECapability
SEQUENCEs the parameters field is present and indicates the SEQUENCEs the parameters field is present and indicates the
supported key-encryption algorithm with the KeyWrapAlgorithm supported key-encryption algorithm with the KeyWrapAlgorithm
algorithm identifier. algorithm identifier. The DER encodings that indicate capability
of the three key agreement algorithms with CMS Triple-DES key wrap
are:
30 1c 06 09 2b 81 05 10 86 48 3f 00 02 30 0f 06
0b 2a 86 48 86 f7 0d 01 09 10 03 06 05 00
for ephemeral-static ECDH,
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
for ephemeral-static ECDH with cofactor method, and
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
for ECMQV.
8 ASN.1 Syntax 8 ASN.1 Syntax
The ASN.1 syntax that is used in this document is gathered together The ASN.1 syntax that is used in this document is gathered together
in this section for reference purposes. in this section for reference purposes.
8.1 Algorithm identifiers 8.1 Algorithm identifiers
The algorithm identifiers used in this document are taken from The algorithm identifiers used in this document are taken from
[X9.62] and [X9.63]. [X9.62] and [X9.63].
skipping to change at page 11, line 33 skipping to change at page 12, line 14
ECDSA-Sig-Value is specified in [X9.62]. Within CMS, ECDSA-Sig-Value is specified in [X9.62]. Within CMS,
ECDSA-Sig-Value is DER-encoded and placed within a signature field ECDSA-Sig-Value is DER-encoded and placed within a signature field
of SignedData. of SignedData.
When using ECDH and ECMQV with EnvelopedData and AuthenticatedData, When using ECDH and ECMQV with EnvelopedData and AuthenticatedData,
ephemeral and static public keys are encoded using the type ephemeral and static public keys are encoded using the type
ECPoint. ECPoint.
ECPoint ::= OCTET STRING ECPoint ::= OCTET STRING
When using ECQMV with EnvelopedData and AuthenticatedData, the When using ECMQV with EnvelopedData and AuthenticatedData, the
sending agent's ephemeral public key and additional keying material sending agent's ephemeral public key and additional keying material
are encoded using the type: 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 in used to represent the ephemeral public key The ECPoint syntax in used to represent the ephemeral public key
and placed in the ephemeralPublicKey field. The additional user and placed in the ephemeralPublicKey field. The additional user
keying material is place in the addedukm field. Then the keying material is place in the addedukm field. Then the
skipping to change at page 12, line 18 skipping to change at page 13, line 4
entityUInfo optionally contains additional keying material entityUInfo optionally contains additional keying material
supplied by the sending agent. When used with ECDH and CMS, the supplied by the sending agent. When used with ECDH and CMS, the
entityUInfo field contains the octet string ukm. When used with entityUInfo field contains the octet string ukm. When used with
ECMQV and CMS, the entityUInfo contains the octet string ECMQV and CMS, the entityUInfo contains the octet string
addedukm (encoded in MQVuserKeyingMaterial). addedukm (encoded in MQVuserKeyingMaterial).
suppPubInfo contains the length of the generated KEK, in bits, suppPubInfo contains the length of the generated KEK, in bits,
represented as a 32 bit number, as in [CMS-DH]. (E.g. for 3DES represented as a 32 bit number, as in [CMS-DH]. (E.g. for 3DES
it would be 00 00 00 c0.) it would be 00 00 00 c0.)
Within CMS, ECC-CMS-SharedInfo is DER-encoded and used as input to Within CMS, ECC-CMS-SharedInfo is DER-encoded and used as input to
the key derivation function, as specified in [X9.63]. Note that the key derivation function, as specified in [X9.63, Section
ECC-CMS-SharedInfo differs from the OtherInfo specified in 5.6.3]. Note that ECC-CMS-SharedInfo differs from the OtherInfo
[CMS-DH]. Here a counter value is not included in the keyInfo specified in [CMS-DH]. Here a counter value is not included in the
field because the key derivation function specified in [X9.63] keyInfo field because the key derivation function specified in
ensures that sufficient keying data is provided. [X9.63, Section 5.6.3] ensures that sufficient keying data is
provided.
9 Summary 9 Summary
This document specifies how to use ECC algorithms with the S/MIME This document specifies how to use ECC algorithms with the S/MIME
CMS. Use of ECC algorithm within CMS can result in reduced CMS. Use of ECC algorithm within CMS can result in reduced
processing requirements for S/MIME agents, and reduced bandwidth processing requirements for S/MIME agents, and reduced bandwidth
for CMS messages. for CMS messages.
References References
[X9.42] ANSI X9.42-xxxx, "Agreement Of Symmetric Keys Using [X9.42] ANSI X9.42-2001, "Agreement Of Symmetric Keys Using
Diffie-Hellman and MQV Algorithms", American National Diffie-Hellman and MQV Algorithms", American National
Standards Institute, 2001, Working draft. Standards Institute, 2001, Approved draft.
[X9.62] ANSI X9.62-1999, "Public Key Cryptography For The [X9.62] ANSI X9.62-1998, "Public Key Cryptography For The
Financial Services Industry: The Elliptic Curve Financial Services Industry: The Elliptic Curve
Digital Signature Algorithm (ECDSA)", Americal Digital Signature Algorithm (ECDSA)", American
National Standards Institute, 1999. National Standards Institute, 1999.
[X9.63] ANSI X9.63-xxxx, "Public Key Cryptography For The [X9.63] ANSI X9.63-xxxx, "Public Key Cryptography For The
Financial Services Industry: Key Agreement and Key Financial Services Industry: Key Agreement and Key
Transport Using Elliptic Curve Cryptography", American Transport Using Elliptic Curve Cryptography", American
National Standards Institute, 2000, Working draft. National Standards Institute, 2000, Working draft.
[PKI-ALG] L. Bassham, R. Housley and W. Polk, "Algorithms and [PKI-ALG] L. Bassham, R. Housley and W. Polk, "Algorithms and
Identifiers for the Internet X.509 Public Key Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and CRL profile", PKIX Infrastructure Certificate and CRL profile", PKIX
skipping to change at page 14, line 9 skipping to change at page 14, line 38
[CMS-DH] E. Rescorla, "Diffie-Hellman Key Agreement Method", [CMS-DH] E. Rescorla, "Diffie-Hellman Key Agreement Method",
RFC 2631, June 1999. RFC 2631, June 1999.
[SEC1] SECG, "Elliptic Curve Cryptography", Standards for [SEC1] SECG, "Elliptic Curve Cryptography", Standards for
Efficient Cryptography Group, 2000. Efficient Cryptography Group, 2000.
[SEC2] SECG, "Recommended Elliptic Curve Domain Parameters", [SEC2] SECG, "Recommended Elliptic Curve Domain Parameters",
Standards for Efficient Cryptography Group, 2000. Standards for Efficient Cryptography Group, 2000.
[SEC3] SECG, "ECC in X.509", Standards for Efficient [SEC3] SECG, "ECC in X.509", Standards for Efficient
Cryptography Group, 2000. Cryptography Group, Working Draft, 2000.
Security Considerations Security Considerations
This specification is based on [CMS], [X9.62] and [X9.63] and the This specification is based on [CMS], [X9.62] and [X9.63] and the
appropriate security considerations of those documents apply. appropriate security considerations of those documents apply.
In addition, implementors of AuthenticatedData should be aware of In addition, implementors of AuthenticatedData should be aware of
the concerns expressed in [BON] when using AuthenticatedData to the concerns expressed in [BON] when using AuthenticatedData to
send messages to more than one recipient. send messages to more than one recipient.
skipping to change at page 14, line 46 skipping to change at page 15, line 24
of licenses to be made available, or the result of an attempt made 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 to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat. can be obtained from the IETF Secretariat.
Acknowledgments Acknowledgments
The methods described in this document are based on work done by The methods described in this document are based on work done by
the ANSI X9F1 working group. The authors wish to extend their the ANSI X9F1 working group. The authors wish to extend their
thanks to ANSI X9F1 for their assistance. The authors also wish to thanks to ANSI X9F1 for their assistance. The authors also wish to
thank Peter de Rooij for his patient assistance. thank Peter de Rooij for his patient assistance. The technical
comments of Francois Rousseau were valuable contributions.
Authors' Address Authors' Addresses
Simon Blake-Wilson Simon Blake-Wilson
Certicom Corp Certicom Corp
5520 Explorer Drive #400 5520 Explorer Drive #400
Mississauga, ON L4W 5L1 Mississauga, ON L4W 5L1
e-mail: sblakewi@certicom.com e-mail: sblakewi@certicom.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
e-mail: dbrown@certicom.com e-mail: dbrown@certicom.com
Paul Lambert Paul Lambert
Director of Security Applications Director of Security Applications
CoSine Communications CoSine Communications
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/