draft-ietf-smime-ecc-01.txt   draft-ietf-smime-ecc-02.txt 
INTERNET-DRAFT Daniel R. L. Brown INTERNET-DRAFT Simon Blake-Wilson, Certicom Corp
draft-ietf-smime-ecc-01.txt Certicom Corp draft-ietf-smime-ecc-02.txt Daniel R. L. Brown, Certicom Corp
14 July, 2000 Expires: 14 January 2001 7 September, 2000 Expires: 7 March, 2001
Use of ECC Algorithms in S/MIME 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.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
skipping to change at page 1, line 30 skipping to change at page 1, line 30
progress." 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.
Abstract Abstract
This document is the second draft of a profile for the This document describes how to use Elliptic Curve Cryptography
incorporation of Elliptic Curve Cryptography (ECC) public key (ECC) public-key algorithms in the Cryptographic Message Syntax
algorithms in the Cryptographic Message Syntax (CMS). The ECC (CMS). The ECC algorithms support the creation of digital
algorithms support the creation of digital signatures and the signatures and the exchange of keys to encrypt or authenticate
exchange of keys to encrypt or authenticate message content. The content. The definition of the algorithm processing is based on
definition of the algorithm processing is based on the ANSI X9.62 the ANSI X9.62 standard and the ANSI X9.63 draft, developed by the
standard and the ANSI X9.63 draft, developed by the ANSI X9F1 ANSI X9F1 working group.
working group.
Table of Contents Table of Contents
1 Introduction ........................................ 3 1 Introduction ........................................ 3
1.1 Requirement terminology ........................ 3 1.1 Requirement terminology ........................ 3
2 EnvelopedData using ECC ............................. 3 2 SignedData using ECC ................................ 3
2.1 EnvelopedData using X9.63 ECDH ................. 3 2.1 SignedData using ECDSA ......................... 3
2.1.1 Fields of KeyAgreeRecipientInfo type .... 4 2.1.1 Fields of the SignedData ................ 3
2.1.2 Actions of the sending agent ............ 5 2.1.2 Actions of the sending agent ............ 4
2.1.3 Actions of the receiving agent .......... 5 2.1.3 Actions of the receiving agent .......... 4
2.2 EnvelopedData using X9.63 modified ECDH ........ 5 3 EnvelopedData using ECC ............................. 5
2.2.1 Fields of KeyAgreeRecipientInfo type .... 6 3.1 EnvelopedData using ECDH ....................... 5
2.2.2 Actions of the sending agent ............ 6 3.1.1 Fields of KeyAgreeRecipientInfo ......... 5
2.2.3 Actions of the receiving agent .......... 6 3.1.2 Actions of the sending agent ............ 5
2.3 EnvelopedData using X9.63 1-Pass MQV ........... 7 3.1.3 Actions of the receiving agent .......... 6
2.3.1 Fields of KeyAgreeRecipientInfo type .... 7 3.2 EnvelopedData using 1-Pass ECMQV ............... 6
2.3.2 Actions of the sending agent ............ 9 3.2.1 Fields of KeyAgreeRecipientInfo ......... 6
2.3.3 Actions of the receiving agent .......... 9 3.2.2 Actions of the sending agent ............ 7
2.3.4 Originator certificates ................. 9 3.2.3 Actions of the receiving agent .......... 8
3 AuthenticatedData using X9.63 1-Pass MQV ............ 10 4 AuthenticatedData using ECC ............ ............ 8
3.1 AuthenticatedData using X9.63 1-pass MQV ....... 11 4.1 AuthenticatedData using 1-pass ECMQV ........... 8
3.1.1 Fields of KeyAgreeRecipientInfo type .... 11 4.1.1 Fields of KeyAgreeRecipientInfo ......... 8
3.1.2 Actions of the sending agent ............ 11 4.1.2 Actions of the sending agent ............ 8
3.1.3 Actions of the receiving agent .......... 11 4.1.3 Actions of the receiving agent .......... 9
3.1.4 Originator certificates ................. 11 5 Recommended Elliptic Curves ......................... 9
3.1.5 Re-using a KEK with 1-Pass MQV .......... 11 6 Certificates using ECC .............................. 9
4 SignedData using ECC ................................ 12 7 SMIMECapabilities Attribute and ECC ................. 9
4.1 SignedData using X9.62 ECDSA ................... 12 8 ASN.1 Syntax ........................................ 9
4.1.1 Fields of the SignedData type ........... 13 8.1 Algorithm identifiers .......................... 9
4.1.2 Actions of the sending agent ............ 14 8.2 Other syntax ................................... 11
4.1.3 Actions of the receiving agent .......... 14 9 Summary ............................................. 12
5 Certificates using ECC .............................. 15 References ............................................. 12
6 SMIMECapabilites Attribute and ECC .................. 15 Security Considerations ................................ 14
7 ASN.1 Types and Identifiers ......................... 15 Intellectual Property Rights ........................... 14
7.1 Object identifiers ............................. 15 Acknowledgments ........................................ 14
7.2 Type definitions ............................... 17 Authors' Address ....................................... 14
8 Summary ............................................. 17 Full Copyright Statement ............................... 15
References ............................................. 18
Security Considerations ................................ 19
Intellectual Property Rights ........................... 19
Acknowledgments ........................................ 20
Author's Address ....................................... 20
Full Copyright Statement ............................... 20
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 following CMS the CMS. The ECC algorithms are incorporated into the following
content types: CMS content types:
- 'EnvelopedData' to support ECC public key agreement methods - 'SignedData' to support ECC-based digital signature methods
(ECDH and MQV) to generate pairwise key-encryption keys to (ECDSA) to sign content
encrypt content-encryption keys used for content encryption
- 'AuthenticatedData' to support ECC based public key agreement - 'EnvelopedData' to support ECC-based public-key agreement
methods (MQV) to generate pairwise key-encryption keys to methods (ECDH and ECMQV) to generate pairwise key-encryption
encrypt MAC keys used for content authentication keys to encrypt content-encryption keys used for content
encryption
- 'SignedData' to support ECC based digital signature methods - 'AuthenticatedData' to support ECC-based public-key agreement
(ECDSA) to sign content methods (ECMQV) to generate pairwise key-encryption keys to
encrypt MAC keys used for content authentication
Certificates based on ECC digital signatures (ECDSA) are also Certification of EC public keys is also described to provide
supported. 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].
2 EnvelopedData using X9.63 ECC methods 2 SignedData using ECC
Elliptic curve cryptography (ECC) methods for key agreement are
specified in [X9.63]. This specification refers to [X9.63] for the
cryptographic operations.
Note: all the key agreement methods here use the key derivation
method specified in [X9.63, Section 5.6.3].
2.1 EnvelopedData using X9.63 (standard) ephemeral-static ECDH
Ephemeral-static Elliptic Curve Diffie-Hellman (ECDH) key agreement
algorithm is the elliptic curve analog of the Diffie-Hellman key
agreement algorithm specified jointly in the documents [CMS,
Section 12.3.1.1] and [DH-X9.42]. The key agreement method is
adapted to use the elliptic curve methods from [X9.63, Section
6.2], the "1-Pass Diffie-Hellman scheme" using the standard
Diffie-Hellman primitive [X9.63, Section 5.4.1].
2.1.1 Fields of KeyAgreeRecipientInfo type
When using ephemeral-static ECDH, the EnvelopedData RecipientInfos
KeyAgreementInfo fields must be used as follows:
version is 3, as in [CMS, section 12.3.1.1]. This section describes how to use ECC algorithms with the CMS
SignedData format to sign data.
originator is the alternative originatorKey, as in [CMS, Section 2.1 SignedData using ECDSA
12.3.1.1]. The originatorKey algorithm fields contains the
id-ecPublicKey object identifer with absent parameters. The
id-ecPublicKey object identifier is:
id-ecPublicKey OBJECT IDENTIFIER ::= { iso(1) member-body(2) This section describes how to use the Elliptic Curve Digital
ansi-x9-62(10045) keyType(2) 1 } Signature Algorithm (ECDSA) with SignedData. ECDSA is specified in
[X9.62]. The method is the elliptic curve analog of the
Digital Signature Algorithm (DSA) [FIPS 186-2].
The originatorKey publicKey field contains the sender's 2.1.1 Fields of the SignedData
ephemeral EC public key as determined below (by methods of
[X9.63]).
ukm may be absent, as in [CMS, Section 12.3.1.1], and has the When using ECDSA with SignedData the fields of SignerInfo are as in
same meaning as in [CMS]. [CMS], but with the following restrictions:
keyEncryptionAlgorithm is the dhSinglePass-stdDH-sha1kdf-scheme digestAlgorithm contains the algorithm identifier sha-1 (see
algorithm identifier, with parameter field KeyWrapAlgorithm Section 8.1) which identifies the SHA-1 hash algorithm.
present, with the follow value and syntax:
dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { signatureAlgorithm contains the algorithm identifier
iso(1) identified-organization(3) tc68(133) country(16) ecdsa-with-SHA1 (see Section 8.1) which identifies the ECDSA
x9(840) x9-63(63) schemes(0) 2} signature algorithm.
KeyWrapAlgorithm ::= AlgorithmIdentifier signature contains the DER encoding (as an octet string) of a
value of the ASN.1 type ECDSA-Sig-Value (see Section
7.2).
The KeyWrapAlgorithm indicates the symmetric encryption When using ECDSA, the SignedData certificates field may include the
algorithm used to encrypt the CEK with the KEK. certificate(s) for the EC public key(s) used in the generation of
the ECDSA signatures in SignedData. ECC certificates are discussed
in Section 6.
recipientEncryptedKeys contains an encrypted (wrapped) 2.1.2 Actions of the sending agent
content-encryption key and an identifier for each recipient, as
in [CMS, section 12.3.1.1].
The next two sections specify actions of sending and receiving When using ECDSA with SignedData, the sending agent uses the
agents to handle ephemeral-static ECDH in keyAgreeRecipientInfo message digest calculation process and signature generation process
fields of EnvelopedData. for SignedData that are specified in [CMS]. To sign data, the
sending agent uses the signature method specified in [X9.62,
Section 5.3] with the following exceptions:
2.1.2 Actions of the sending agent - In [X9.62, Section 5.3.1], the integer "e" shall instead be
determined by converting the octet string resulting from [CMS,
Section 5.4] to an integer using the data conversion method in
[X9.62, Section 4.3.2].
When using ephemeral-static ECDH to generate EnvelopedData The sending agent encodes the resulting signature using the
KeyAgreeRecipientInfo fields, the sending agent selects groups of ECDSA-sig-value syntax and places it in the SignerInfo signature
recipients with common EC domain parameters. For each group, the field.
sending agent selects an ephemeral EC public key pair, as per the
1-Pass Diffie-Hellman scheme initiator transformation, specified in
[X9.63, Section 6.2.1]. The sending agent determines an integer
"keydatalen" from key-size of the KeyWrapAlgorithm and a bit string
"SharedData" from the ukm field if present. For each recipient in
the group, the sending agent completes the X9.63 1-Pass
Diffie-Hellman initiator transformation using the selected
ephemeral EC public key and the recipient's static EC public key
(i.e. from a certificate) to obtain a bit string "KeyData". The
"KeyData" bit string becomes the pairwise key-encryption key for
the recipient.
2.1.3 Actions of the receiving agent 2.1.3 Actions of the receiving agent
The receiving agent uses the following process on an EnvelopedData When using ECDSA with SignedData, the receiving agent uses the
to detect if ephemeral-static Diffie-Hellman is used to transfer message digest calculation process and signature verification
the CEK to the receiving agent, and if so to compute the process for SignedData that are specified in [CMS]. To verify
key-encryption key used to unwrap the CEK. SignedData, the receiving agent uses the signature verification
method specified in [X9.62, Section 5.4] with the following
The receiving agent determines the bit string "SharedData" from the exceptions:
ukm field if present, and the integer "keydatalen" from the
key-size of the KeyWrapAlgorithm and completes the X9.63 1-Pass
Diffie-Hellman responder transformation [X9.63, Section 6.2.2],
using the ephemeral EC public key and the identified receiving
agent's static EC public key, to obtain a bit string "KeyData".
The "KeyData" bit string becomes the pairwise key-encryption key
for the receiving agent.
2.2 EnvelopedData using X9.63 modified ephemeral-static ECDH - In [X9.62, Section 5.4.1] the integer "e" shall instead be
determined by converting the octet string resulting from [CMS,
Section 5.4] to an integer using the data conversion method in
[X9.62, Section 4.3.2].
Modified ephemeral-static Elliptic Curve Diffie-Hellman (ECDH) key In order to verify the signature, the receiving agent retrieves the
agreement algorithm is identical to standard ECDH except that a integers r and s from the SignerInfo signature field of the
modified version of the Diffie-Hellman primitive [X9.63, Section received message.
5.4.2] is used. The modification involves multiplication by a
cofactor. A purpose of the modification is to prevent the
small-subgroup attack [SSG]. To indicate that the modified
Diffie-Hellman primitive is used, a different algorithm identifider
for this key agreement algorithm is provided, as specified below.
2.2.1 Fields of KeyAgreeRecipientInfo type 3 EnvelopedData using ECC Algorithms
When using modified ephemeral-static ECDH, the EnvelopedData This section describes how to use ECC algorithms with the CMS
RecipientInfos KeyAgreementInfo fields are the same as in those EnvelopedData format.
specified in Section 2.1.1 of this document, except:
keyEncryptionAlgorithm is the 3.1 EnvelopedData using (ephemeral-static) ECDH
dhSinglePass-cofactorDH-sha1kdf-scheme algorithm identifier,
with parameter KeyWrapAlgorithm present, and the following value
and syntax:
dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= This section describes how to use ephemeral-static Elliptic Curve
{ iso(1) identified-organization(3) tc68(133) country(16) Diffie-Hellman (ECDH) key agreement algorithm with EnvelopedData.
x9(840) x9-63(63) schemes(0) 3} Ephemeral-static ECDH is specified in [X9.63]. Ephemeral-static
ECDH is the the elliptic curve analog of the ephemeral-static
Diffie-Hellman key agreement algorithm specified jointly in the
documents [CMS, Section 12.3.1.1] and [CMS-DH].
KeyWrapAlgorithm ::= AlgorithmIdentifier 3.1.1 Fields of KeyAgreeRecipientInfo
2.2.2 Actions of the sending agent When using ephemeral-static ECDH with EnvelopedData, the fields of
KeyAgreeRecipientInfo are as in [CMS], but with the following
restrictions:
The actions of the sending agent are identical to the actions of originator is the alternative originatorKey. The originatorKey
sending agent using standard ephemeral-static ECDH specified above algorithm field contains the id-ecPublicKey object identifier
in Section 2.1.2, except that: (see Section 8.1) with NULL parameters. The originatorKey
publicKey field contains the DER-encoding of a value of the
ASN.1 type ECPoint (see Section 8.2).
- The sending agent uses the modified Diffie-Hellman primitive keyEncryptionAlgorithm contains the
of [X9.63, Section 5.4.2] rather than the standard dhSinglePass-stdDH-sha1kdf-scheme object identifier (see Section
Diffie-Hellman primitive [X9.63, Section 5.4.1]. 7.1) if standard ECDH primitive is used, or the
dhSinglePass-cofactorDH-sha1kdf-scheme object identifier (see
Section 8.1) if the cofactor ECDH primitive is used. The
parameter field contains KeyWrapAlgorithm. The KeyWrapAlgorithm
is the algorithm identifier that indicates the symmetric
encryption algorithm used to encrypt the CEK with the KEK.
Note: modified and standard ephemeral-static ECDH can only be used 3.1.2 Actions of the sending agent
within separate KeyAgreeRecipientInfo fields.
2.2.3 Actions of the receiving agent When using ephemeral-static ECDH with EnvelopedData, the sending
agent first obtains the recipient's EC public key and domain
parameters (e.g. from the recipient's certificate). The sending
agent then determines an integer "keydatalen" which is the
key-size, in bits, of the KeyWrapAlgorithm and a bit string
"SharedData". The "SharedData" bit string is the DER encoding of
ASN.1 type X9-63-CMS-SharedInfo (see Section 8.2). The sending
agent then performs the initiator transformation of the 1-Pass
Diffie-Hellman scheme specified in [X9.63, Section 6.2.1]. As a
result the sending agent obtains:
The actions of the receiving agent are identical to the actions of - an ephemeral public key, which is represented as a value of
receiving agent using standard ephemeral-static ECDH specified the type ECPoint (see Section 8.2), encapsulated in a bit
above in Section 2.1.2, except that: string and placed in the KeyAgreeRecipientInfo originator
field, and
- The receiving agent uses the modified Diffie-Hellman primitive - a shared secret bit string "KeyData" which is used as the
of [X9.63, Section 5.4.2] rather than the standard pairwise key-encryption key for that recipient.
Diffie-Hellman primitive [X9.63, Section 5.4.1].
2.3 EnvelopedData using X9.63 1-Pass MQV 3.1.3 Actions of the receiving agent
In [X9.63, Appendix H.4.5], 1-Pass MQV is suggested for When using ephemeral-static ECDH with EnvelopedData, the receiving
store-and-forward applications such as e-mail. agent determines the bit string "SharedData" (see Section 8.2) and
the integer "keydatalen" from the key-size, in bits, of the
KeyWrapAlgorithm. The receiving agent retrieves the ephemeral EC
public key from the bit string KeyAgreeRecipientInfo originator,
which an value of the type ECPoint (see Section 8.2) encapsulated
as a bit string. The receiving agent completes the responder
transformation of the 1-Pass Diffie-Hellman scheme [X9.63, Section
6.2.2]. As a result the receiving agent obtains a shared secret
bit string "KeyData" which is used as the pairwise key-encryption
key to unwrap the CEK.
The 1-Pass MQV key agreement method, specified in [X9.63, Section 3.2 EnvelopedData using 1-Pass ECMQV
6.9], uses three EC public keys to generate keying data
(i.e. pairwise key-encryption key). The three keys are: a static
recipient key, a static originator key, and an ephemeral originator
key.
The originator's static EC public key is identified in the This section describes how to use the 1-Pass elliptic curve MQV
originator field, usually by reference to a certificate. The (ECMQV) key agreement algorithm with EnvelopedData. 1-Pass ECMQV
originator's ephemeral EC public is specified within the ukm field. is specified in [X9.63]. Like the KEA algorithm [CMS-KEA], 1-Pass
The recipient's static EC public key is identified according to ECMQV uses three key pairs: an ephemeral key pair, a static key
[CMS], within a rid field. 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
with both EnvelopedData and AuthenticatedData.
2.3.1 Fields of KeyAgreeRecipientInfo type 3.2.1 Fields of KeyAgreeRecipientInfo
When using 1-Pass MQV, the EnvelopedData RecipientInfos When using 1-Pass ECMQV with EnvelopedData the fields of
KeyAgreementInfo fields are used as follows: KeyAgreeRecipientInfo are:
version is 3, as in [CMS, section 12.3.1.1]. 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 sender's or subjectKeyIdentifier and point to one of the sending agent's
certificates supplied in the EnvelopedData originatorInfo field. certificates supplied in the EnvelopedData originatorInfo field.
(If necessary, it may be the alternative originatorKey, as in
[CMS, Section 12.3.1.1], and if so, the originatorKey algorithm
field contains the id-ecPublicKey object identifer with absent
parameters. The id-ecPublicKey object identifier is:
id-ecPublicKey OBJECT IDENTIFIER ::= { iso(1) member-body(2)
ansi-x9-62(10045) keyType(2) 1 }
The originatorKey publicKey field contains the sender's static ukm is present. The ukm field contains an octet string which is
EC public key.) the DER encoding of the type MQVuserKeyingMaterial (see Section
ukm is present. It identifies the ephemeral EC public key of 8.2). The MQVuserKeyingMaterial ephemeralPublicKey algorithm
the sender. It may also identify some additional information field contains the id-ecPublicKey object identifier (see Section
for purposes similar to those specified in [CMS, Section 8.1) with NULL parameters field. The MQVuserKeyingMaterial
12.3.1.1]. The ukm field contains an octet string which is the ephemeralPublicKey publicKey field contains the DER-encoding of
DER encoding of the following ASN.1 type the ASN.1 type ECPoint representing sending agent's ephemeral EC
public key. The MQVuserKeyingMaterial addedukm field, if
MQVuserKeyingMaterial ::= SEQUENCE { present, contains an octet string of additional user keying
ephemeralPublicKey OriginatorPublicKey, material of the sending agent.
addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }
The MQVuserKeyingMaterial ephemeralPublicKey algorithm field
contains the id-ecPublicKey object identifer with absent
parameters. The id-ecPublicKey object identifier is:
id-ecPublicKey OBJECT IDENTIFIER ::= { iso(1)
member-body(2) ansi-x9-62(10045) keyType(2) 1 }
The MQVuserKeyingMaterial ephemeralPublicKey publicKey field
contains the sender's ephemeral EC public key as determined
below (by methods of [X9.63]). The MQVuserKeyingMaterial
addedukm field, if present, contains an octet string, whose
meaning is similar to meaning of the ukm field in [CMS,
Section 12.3.1.1].
keyEncryptionAlgorithm is the mqvSinglePass-sha1kdf-scheme keyEncryptionAlgorithm is the mqvSinglePass-sha1kdf-scheme
algorithm identifier, with parameter field KeyWrapAlgorithm algorithm identifier (see Section 8.1), with parameter field
present, with the following values and syntax: KeyWrapAlgorithm. The KeyWrapAlgorithm indicates the symmetric
encryption algorithm used to encrypt the CEK with the KEK
mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= { iso(1) generated using the 1-Pass ECMQV algorithm.
identified-organization(3) tc68(133) country(16) x9(840)
x9-63(63) schemes(0) 16}
KeyWrapAlgorithm ::= AlgorithmIdentifier
The KeyWrapAlgorithm indicates the symmetric encryption
algorithm used to encrypt the CEK with the KEK generated using
the 1-Pass MQV algorithm.
recipientEncryptedKeys contains an encrypted (wrapped)
content-encryption key and an identifier for each recipient, as
in [CMS, section 12.3.1.1].
2.3.2 Actions of the sending agent
When using 1-Pass MQV to generate EnvelopedData
KeyAgreeRecipientInfo fields, the sending agent selects groups of
recipients with common EC domain parameters. For each group, the
sending agent selects an ephemeral EC public key pair, as per the
1-Pass MQV scheme initiator transformation, specified in [X9.63,
Section 6.9.1]. The sending agent specifies the ephemeral EC
public key in the KeyAgreeRecipientInfo ukm field, ASN.1 encoded
within in the MQVuserKeyingMaterial ephemeralPublickey publicKey
field. The sending agent determines an integer "keydatalen" from
key-size of the KeyWrapAlgorithm and a bit string "SharedData" from
the MQVuserKeyingMaterial addedukm field (if present) ASN.1 encoded
in the ukm field. For each recipient in the group, the sending
agent completes the 1-Pass MQV initiator transformation using the
selected ephemeral EC public key pair, the static EC public keys
(i.e. from certificates) of the originator and the recipient, and
the bit string "SharedData" if present, to obtain a bit string
"KeyData". The bit string "KeyData" becomes the pairwise
key-encryption key (KEK) for the recipient.
2.3.3 Actions of the receiving agent
The receiving agent uses the following process on an EnvelopedData
to detect if 1-Pass MQV is used to agree on the pairwise KEK for
the receiving agent, and if so to compute the pairwise KEK.
The receiving agent determines the bit string "SharedData" from the
ukm field if present, and the integer "keydatalen" from the
key-size of the KeyWrapAlgorithm and completes the 1-Pass MQV
responder transformation [X9.63, Section 6.9.2], using the
ephemeral EC public key, the identified static EC public keys of
the recipient and originator, and the bit string "SharedData" if
present, to obtain a bit string "KeyData". The bit string
"KeyData" becomes the the pairwise key-encryption key (KEK) for the
receiving agent.
2.3.4 Originator's certificates
If some recipients do not have other means to obtain the 3.2.2 Actions of the sending agent
originator's certificate for a static EC public key used in 1-Pass
MQV, then the originator's certificate containing the originator
static EC public key should be included in the EnvelopedData
originatorInfo field.
3 AuthenticatedData using ECC When using 1-Pass ECMQV with EnvelopedData, the sending agent first
obtains the recipient's EC public key and domain parameters,
(e.g. from the recipient's certificate) and checks that the domain
parameters are the same. The sending agent then determines an
integer "keydatalen" which is the key-size, in bits, of the
KeyWrapAlgorithm and a bit string "SharedData" (see Section 8.2).
The sending agent then performs the initiator transformation of the
1-Pass ECMQV scheme specified in [X9.63, Section 6.9.1]. As a
result the sending agent obtains
The 1-Pass MQV scheme of [X9.63] has been selected in this document - an ephemeral public key, which is represented as a value of
for AuthenticatedData using ECC because it has security attributes type ECPoint (see Section 8.2), encapsulated in a bit string,
that are appropriate for the AuthenticatedData CMS type. placed in an MQVuserKeyingMaterial ephemeralPublicKey
publicKey field (see Section 8.2), and
Note: in general, pure 'ephemeral-static' key agreement methods are - a shared secret bit string "KeyData" which is used as the
not suitable for AuthenticatedData because the originator's key is pairwise key-encryption key for that recipient. Parity bits
ephemeral and therefore not authenticated. are adjust according to the key wrap algorithm.
Note: both SignedData and AuthenticatedData provide assurance to The ephemeral public key may be re-used with an AuthenticatedData
the receiving agent that the content data originated from the for greater efficiency.
purported originator and the content was in no way modified.
However, SignedData and AuthenticatedData differ in some important
respects:
1. In AuthenticatedData the assurance of the content origin and 3.2.3 Actions of the receiving agent
integrity is only provided to the specific recipients of the
AuthenticatedData. In SignedData, the assurance of content
origin and integrity is provided to potentially everyone.
2. In AuthenticatedData, the sending agent and receiving agent When using 1-Pass ECMQV with EnvelopedData, the receiving agent
are equally capable producing any given AuthenticatedData. In determines the bit string "SharedData" (see Section 8.2) and the
SignedData, only the sending agent is capable of producing the integer "keydatalen" from the key-size, in bits, of the
SignedData. KeyWrapAlgorithm. The receiving agent then retrieves the static
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
public key identified in the rid field and checks that the domain
parameters are the same. The receiving agent then performs the
responder transformation of the 1-Pass ECMQV scheme [X9.63, Section
6.9.2]. As a result the receiving agent obtains a shared secret
bit string "KeyData" which is used as the pairwise key-encryption
key to unwrap the CEK.
Careful consideration should be applied to the choice of using 4 AuthenticatedData using ECC
AuthenticatedData or SignedData because of the these differences.
In particular, in AuthenticatedData the originator has less
'commitment' to the content than SignedData because
AuthenticatedData does not have the non-repudiative feature of
SignedData.
3.1 AuthenticatedData using 1-pass MQV This section describes how to use ECC algorithms with the CMS
AuthenticatedData format. AuthenticatedData lacks non-repudiation,
and so in some instances is preferrable SignedData. (For example,
the sending agent may not want the message to be authenticated when
forwarded.)
In general, using 1-Pass MQV in AuthenticatedData is similar to 4.1 AuthenticatedData using 1-pass ECMQV
using 1-Pass MQV in EnvelopedData (see Section 2.3 of this
document). Further details are provided in Sections 3.1.1 to
3.1.4.
However, 1-Pass MQV, AuthenticatedData and EnvelopedData can be use This section describes how to use the 1-Pass elliptic curve MQV
together more efficiently by the re-using pairwise key-encryption (ECMQV) key agreement algorithm with AuthenticatedData. 1-Pass
keys. A method to do this is specified in Section 3.1.5. ECMQV is specified in [X9.63]. An advantage of using 1-Pass ECMQV
is that it may be used with both EnvelopedData and
AuthenticatedData.
3.1.1 Fields of the KeyAgreementInfo type 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
KeyAgreeRecipeintInfo fields of Section 2.3.1 of this document. KeyAgreeRecipientInfo fields of Section 3.2.1 of this document.
Note: the originator field should be one of the alternatives 4.1.2 Actions of the sending agent
issuerAndSerialNumber or subjectKeyIdentifier. If it is necessary
to use the originatorKey alternative, the recipients should have
other means (i.e. without certificates) to authenticate the
originator's static key.
3.1.2 Actions of the sending agent The sending agent uses the same actions as for EnvelopedData
with 1-Pass ECMQV, as specified in Section 3.2.2 of this document.
The sending agent may use the same actions as for EnvelopedData The ephemeral public key may be re-used with an EnvelopedData for
with 1-Pass MQV, as specified in Section 2.3.2 of this document. greater efficiency.
3.1.3 Actions of the receiving agent Note: if there are multiple recipients then an attack is possible
where one recipient modifies the content without other recipients
noticing [BON]. A sending agent who is concerned with such an
attack should use a separate AuthenticatedData for each recipient.
The receiving agent may use the same actions as for EnvelopedData 4.1.3 Actions of the receiving agent
with 1-Pass MQV, as specified in Section 2.3.3 of this document.
3.1.4 Originator certificates The receiving agent uses the same actions as for EnvelopedData
with 1-Pass ECMQV, as specified in Section 3.2.3 of this document.
If some recipients do not have other means to obtain the Note: see Note in Section 4.1.2.
originator's certificate for a static EC public key used in 1-Pass
MQV, then the originator's certificate certifying the originator
static EC public key should be included in the AuthenticatedData
originatorInfo field.
For recipients that do not have other measn to obtain all the issue 5 Recommended Elliptic Curves
certificates necessary to authenticate the originator's static EC
public key, then the necessary certificates (i.e. CA
cross-certifcates) may be included in the AuthenticatedData
originatorInfo field.
3.1.5 Re-using a KEK with 1-Pass MQV It is strongly recommended that agents use the elliptic curve
domain parameters recommended by ANSI [X9.62, X9.63], NIST [REC-EC]
and SECG [SEC3].
When using 1-Pass MQV for an AuthenticatedData whose content is an 6 Certificates using ECC
EnvelopedData, or for an AuthenticatedData which is the content is
an EnvelopedData, the KEKRecipientInfo type of [CMS] is an
efficient way to re-use a 1-Pass MQV generated pairwise KEK from
the EnvelopedData. Re-use of the EnvelopedData KEK helps to reduce
the total length of the ASN.1 encoding of the AuthenticatedData and
the total number of public key cryptographic operations performed
by both sending agents and receiving agents.
The KEKRecipientInfo encryptedKey field contains the wrapped "MAC" Internet X.509 certificates [PKI] may be used in conjunction with
key, encrypted with the previously generated KEK using 1-Pass MQV. this specification to distribute agents' public keys. The use of
Generally, the pairwise KEK will have been generated within an ECC algorithms and keys within X.509 certificates is specified in
EnvelopedData. The KEKRecipientInfo KEKIdentifier keyIdentifier [PKI-ALG]. More details can be found in [SEC3].
field may be used to identify the re-used secret pairwise KEK
by providing an octet encoding of the originator's ephemeral EC
public key used in a 1-Pass MQV to to generate the KEK.
The KEKIdentifier other field may be absent, if it is certain that 7 SMIMECapabilities Attribute and ECC
the KEK is unambiguously identified. If the KEKIdentifier
keyIdentifier field alone is insufficient to identify the KEK
(perhaps because the receiving agent supports other methods that
use KEKReicipientInfo) then the KEKIdentifier other keyAttrId
field may be object identifier mqvSinglePass-sha1kdf-scheme (see
Section 2.3.1 of this document).
Note: if the content of the AuthenticatedData is an EnvelopedData, A sending agent may choose to announce to receiving agents that it
then the KeyAgreeRecipientInfo fields of the EnvelopedData are in supports one or more of the ECC algorithms in this document by
plaintext and therefore, the KEK can be computed before the using the SMIMECapabilities signed attribute [MSG, Section 2.5.2].
EnvelopedData is decrypted or encrypted. If the content of an
EnvelopedData is an AuthenticatedData the KEK will be computed
before the AuthenticatedData is encrypted or decrypted. In the
either case, both the sending agent and receiving agent are able to
determine the necessary KEK from the EnvelopedData.
4 SignedData using ECC The SMIMECapability value to indicate support for the ECDSA
signature algorithm is the SEQUENCE with the capabilityID field
containing the object identifier ecdsa-with-SHA1 with NULL
parameters.
An elliptic curve cryptography (ECC) method for signing is The SMIMECapability capabilityID object identifiers for the
specified in [X9.62]. In a single SignedData type [CMS] many supported key agreement algorithms in this document are
signing algorithms may be used but within each SignerInfo field dhSinglePass-stdDH-sha1kdf-scheme,
only one signing algorithm can be used. dhSinglePass-cofactorDH-sha1kdf-scheme, and
mqvSinglePass-sha1kdf-scheme. For each of these SMIMECapability
SEQUENCEs the parameters field is present and indicates the
supported key-encryption algorithm with the KeyWrapAlgorithm
algorithm identifier.
4.1 SignedData using X9.62 ECDSA 8 ASN.1 Syntax
The Elliptic Curve Digital Signature Algorithm (ECDSA) is specified The ASN.1 syntax that is used in this document is gathered together
in [X9.62]. The method is the elliptic curve analog of the [X9.30] in this section for reference purposes.
Digital Signature Algorithm (DSA). In [CMS] the meanings of the
fields of SignedData are specified, the actions of the sending
agent to generate SignedData are specified and the actions of the
receiving agent to process SignedData are specified. In [CMS], the
specificiations are algorithm independent. The following
subsections provide additional details about the SignedData fields
and actions of S/MIME agents when [X9.62] ECDSA is being used with
SignedData.
4.1.1 Fields of the SignedData type 8.1 Algorithm identifiers
When using [X9.62] ECDSA in an SignedData SignerInfo type the The algorithm identifiers used in this document are taken from
fields are as in [CMS], but with the following restrictions. [X9.62] and [X9.63].
digestAlgorithm is the following algorithm identifier for SHA-1: The following object identifier indicates the hash algorithm used
in this document:
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 26 } oiw(14) secsig(3) algorithm(2) 26 }
signatureAlgorithm is an algorithm identifer with parameters The following object identifier is used in this document to
field absent that identifies the ECDSA signature algorithm with indicate an elliptic curve public key:
the object identifier:
ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-ecPublicKey OBJECT IDENTIFIER ::= { ansi-x9-62 keyType(2) 1 }
us(840) 10045 signatures(4) 1 }
signature is the DER encoding (as an octet string) of a value of where
the [X9.62] ASN.1 type:
ECDSA-Sig-Value ::= SEQUENCE { ansi-x9-62 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
r INTEGER, 10045 }
s INTEGER }
where the integers r and s are caculated according to [X9.62, When the object identifier id-ecPublicKey is used here with an
Section 5.3] using the signer's private key except that the algorithm identifier, the associated parameters contain NULL.
integer "e" is the result of the SignedData message digest
specified in [CMS] converted from an octet string to an intger
(i.e. not the result of [X9.63, Section 5.3.1]).
When using [X9.62] ECDSA the SignedData certificates field may The following object identifier indicates the digital signature
include the certificates for the EC public keys used in generation algorithm used in this document:
of ECDSA signatures in the SignedData. If it is expected that
recipients have alternative means of obtaining the certain
certificates necessary to authenticate the EC public keys used for
signing, then such certificates may be omitted from the SignedData
certificates field. All certificates necessary for the
authentication of the EC public keys using for signing for which it
is not expected that the recipients have alternative means of
obtaining should be included in the SignedData certificates field.
4.1.2 Actions of the sending agent ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { ansi-x9-62 signatures(4)
1 }
The sending agent uses the message digest calculation process and When the object identifier ecdsa-with-SHA1 is used within an
signature generation process for SignedData that are specified in algorithm identifier, the associated parameters field contains
[CMS]. The sending agent follows the actions for ECDSA signature NULL.
generation specified in [X9.62, Section 5.3] with the following
exceptions:
- In [X9.62, Section 5.3.1], the integer "e" shall instead The following object identifiers indicate the key agreement
be determined by converting the octet string resulting from algorithms used in this document:
[CMS, Section 5.4] to an integer using the data conversion
method in [X9.62, Section 4.3.2].
The sending agent uses the encoding process specified [X9.62, dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
Section 6.5] to convert (encode) the ECDSA signature as an octet x9-63-scheme 2}
string. This octet string is the value of the SignerInfo
SignatureValue field. The sending agent uses DER encoding rules
and includes the entire encoding of the ASN.1 type ECDSA-Sig-Value
(see above and [X9.62]) including the tag and length octets in the
octet string SignerInfo SignatureValue.
4.1.3 Actions of the receiving agent dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 3}
The receiving agent uses the message digest calculation process mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= {
and signature verification process for SignedData that are x9-63-scheme 16}
specified in [CMS]. The receiving agent follows the actions
for ECDSA signature verification specified in [X9.62, Section 5.4]
with the following exceptions:
- In [X9.62, Section 5.4.1] the integer "e" shall instead be where
determined by converting the octet string resulting from [CMS,
Section 5.4] to an integer using the data conversion method in
[X9.62, Section 4.3.2].
The receiving agent uses the encoding process specified in [X9.62, x9-63-scheme OBJECT IDENTIFIER ::= { iso(1)
Section 6.5] to convert (decode) the octet string value of the identified-organization(3) tc68(133) country(16) x9(840)
SignerInfo SignatureValue field to the [X9.62] signature. The x9-63(63) schemes(0) }
receiving agent uses DER decoding rules.
5 Certificates using ECC When the object identifiers are used here within an algorithm
identifier, the associated parameters field contains the CMS
KeyWrapAlgorithm algorithm identifier.
The use of a certificates with ECC is specified in [EPKIX]. 8.2 Other syntax
Further information on the use ECC with certificates is given in
[SECG-WG-EC].
6 SMIMECapabilities Attribute and ECC The following additional syntax is used here.
A sending agent may choose to announce to receiving agents that it When using ECDSA with SignedData, ECDSA signatures are encoded
supports one or more of the ECC algorithms in this document by using the type:
using SMIMECapabilities signed attribute as specified in [MSG,
Section 2.5.2].
The SMIMECapability capabilityID object identifiers for the ECDSA-Sig-Value ::= SEQUENCE {
supported key agreement algorithms in this document are r INTEGER,
dhSinglePass-stdDH-sha1kdf-scheme, s INTEGER }
dhSinglePass-cofactorDH-sha1kdf-scheme, and
mqvSinglePass-sha1kdf-scheme. For each of these SMIMECapability
SEQUENCEs the parameters field is present and indicates the
supported key-encryption algorithm with the KeyWrapAlgorithm
algorithm identifier.
The SMIMECapability value to indicate support for the ECDSA ECDSA-Sig-Value is specified in [X9.62]. Within CMS,
signature algorithm is the SEQUENCE with the capabilityID field ECDSA-Sig-Value is DER-encoded and placed within a signature field
containing the object identifier ecdsa-with-SHA1 and the parameters of SignedData.
field absent.
7 ASN.1 Types and Identifiers When using ECDH and ECMQV with EnvelopedData and AuthenticatedData,
ephemeral and static public keys are encoded using the type
ECPoint.
The ASN.1 types and object identifiers that are used in this ECPoint ::= OCTET STRING
document are gathered together in this section for reference
purposes.
7.1 Object identifiers When using ECQMV with EnvelopedData and AuthenticatedData, the
sending agent's ephemeral public key and additional keying material
are encoded using the type:
The object identifiers used in this document are taken from [CMS], MQVuserKeyingMaterial ::= SEQUENCE {
[X9.63] and [X9.62]. ephemeralPublicKey OriginatorPublicKey,
addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }
The following object identifiers indicate the key agreement The ECPoint syntax in used to represent the ephemeral public key
algorithms used in this document: and placed in the ephemeralPublicKey field. The additional user
keying material is place in the addedukm field. Then the
MQVuserKeyingMaterial value is DER-encoded and placed within in a
ukm field of EnvelopedData or AuthenticatedData.
dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { iso(1) When using ECDH or ECMQV with EnvelopedData or AuthenticatedData,
identified-organization(3) tc68(133) country(16) x9(840) the key-encryption keys are derived by using the type:
x9-63(63) schemes(0) 2}
dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { ECC-CMS-SharedInfo ::= SEQUENCE {
iso(1) identified-organization(3) tc68(133) country(16) keyInfo AlgorithmIdentifier,
x9(840) x9-63(63) schemes(0) 3} entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
suppPubInfo [2] EXPLICIT OCTET STRING }
mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= { iso(1) The fields of ECC-63-CMS-SharedInfo are as follows:
identified-organization(3) tc68(133) country(16) x9(840)
x9-63(63) schemes(0) 16}
The following object identifier indicates the digital signature keyInfo contains the object identifier of the key-encryption
algorithm used in this document: algorithm (used to wrap the CEK) and NULL parameters.
ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) entityUInfo optionally contains additional keying material
us(840) 10045 signatures(4) 1 } supplied by the sending agent. When used with ECDH and CMS, the
entityUInfo field contains the octet string ukm. When used with
ECMQV and CMS, the entityUInfo contains the octet string
addedukm (encoded in MQVuserKeyingMaterial).
The following object identifier indicates the hash algorithm used suppPubInfo contains the length of the generated KEK, in bits,
in this document: represented as a 32 bit number, as in [CMS-DH]. (E.g. for 3DES
it would be 00 00 00 c0.)
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) Within CMS, ECC-CMS-SharedInfo is DER-encoded and used as input to
oiw(14) secsig(3) algorithm(2) 26 } the key derivation function, as specified in [X9.63]. Note that
ECC-CMS-SharedInfo differs from the OtherInfo specified in
[CMS-DH]. Here a counter value is not included in the keyInfo
field because the key derivation function specified in [X9.63]
ensures that sufficient keying data is provided.
The following object identifier is used in this document to 9 Summary
indicate an elliptic curve public key:
id-ecPublicKey OBJECT IDENTIFIER ::= { iso(1) member-body(2) This document specifies how to use ECC algorithms with the S/MIME
ansi-x9-62(10045) keyType(2) 1 } CMS. Use of ECC algorithm within CMS can result in reduced
processing requirements for S/MIME agents, and reduced bandwidth
for CMS messages.
7.2 Type definitions References
The following ASN.1 type defintions are used. [X9.42] ANSI X9.42-xxxx, "Agreement Of Symmetric Keys Using
Diffie-Hellman and MQV Algorithms", American National
Standards Institute, 2000, Working draft.
ECDSA-Sig-Value ::= SEQUENCE { [X9.62] ANSI X9.62-1999, "Public Key Cryptography For The
r INTEGER, Financial Services Industry: The Elliptic Curve
s INTEGER } Digital Signature Algorithm (ECDSA)", Americal
National Standards Institute, 1999.
MQVuserKeyingMaterial ::= SEQUENCE { [X9.63] ANSI X9.63-xzxx, "Public Key Cryptography For The
ephemeralPublicKey OriginatorPublicKey, Financial Services Industry: Key Agreement and Key
addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL } Transport Using Elliptic Curve Cryptography", American
National Standards Institute, 1999, Working draft.
The former is taken from [X9.62]. In this document, DER encodings [PKI-ALG] L. Bassham, R. Housley and W. Polk, "Internet X.509
as octet strings of values of the two above ASN.1 types Public Key Infrastructure Representation of Public
ECDSA-Sig-Value and MQVuserKeyingMaterial are used as values of Keys and Digital Signatures in Internet X.509 Public
octet string ASN.1 types from [CMS]. An encoding of Key Infrastructure Certificates", PKIX Working Group
ECDSA-Sig-Value is used as the value of a SignedData SignerInfo Internet-Draft, July 2000.
SignatureValue and an encoding of MQVuserKeyingMaterial is used as
the value of EnvelopedData KeyAgreeRecipeintInfo UserKeyingMaterial
or AuthenticatedData KeyAgreeRecipeintInfo UserKeyingMaterial.
8 Summary [BON] D. Boneh, "The Security of Multicast MAC",
Presentation at Selected Areas of Cryptography 2000,
Center for Applied Cryptographic Research, University
of Waterloo, 2000
This document specifies how to use ECC methods with S/MIME CMS [MUST] S. Bradner, "Key Words for Use in RFCs to Indicate
type. The most notable advantage of ECC methods over integer Requirement Levels", RFC 2119, March 1997.
arithmetic based methods (Diffie-Hellman, DSA and RSA) is the
shorter length of cryptographic overhead in signatures,
certificates, encrypted and authenticated messages..
This document specifies a cryptographic method to be used with the [FIPS-180] FIPS 180-1, "Secure Hash Standard", National Institute
[CMS] content type AuthenticatedData. The cryptographic method is of Standards and Technology, April 17, 1995.
X9.63 1-Pass MQV scheme. The AuthenticateData type achieves
authentication without 'non-repudiation'. For certain kinds of
data, AuthenticatedData may be preferrable to SignedData.
References [FIPS-186-2] FIPS 186-2, "Digital Signature Standard", National
Institute of Standards and Technology, 15 February
2000.
[PKI] W. Ford, R. Housley, W. Polk and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and CRL
Profile", PKIX Working Group Internet-Draft, July
2000.
[CMS] R. Housley, "Cryptographic Message Syntax", RFC 2630, [CMS] R. Housley, "Cryptographic Message Syntax", RFC 2630,
June 1999. June 1999.
[DH-X9.42] E. Rescorla, "Diffie-Hellman Key Agreement Method", RFC [IEEE1363] IEEE P1363, "Standard Specifications for Public Key
2631, June 1999. Cryptography", Institute of Electrical and Electronics
Engineers, 2000.
[EPKIX] L. Bassham and D. Johnson, "Internet X.509 Public Key
Infrastructure Representation of Elliptic Curve Digital
Signature Algorithm (ECDSA) Keys and Signatures in
Internet X.509 Public Key Infrastructure Certificates",
PKIX Working Group Internet-Draft, October, 1999.
[FIPS-180] Federal Information Processing Standards Publication
(FIPS PUB) 180-1, "Secure Hash Standard", 1995 April
17.
[FIPS-186] Federal Information Processing Standards Publication [LMQSV] L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone,
(FIPS PUB) 186, "Digital Signature Standard", 1994 May "An efficient protocol for authenticated key agreement",
19. Technical report CORR 98-05, University of Waterloo,
1998.
[GEC1] Certicom Research, "Guidelines for Efficinet [REC-EC] National Institute of Standards and Technology,
Cryptography", GEC1, February, 1999. "Recommended Elliptic Curves for Federal Government
Use", July, 1999. Available from:
<http://csrc.nist.gov/encryption/>.
[KEA] J. Pawling, "CMS KEA and SKIPJACK Conventions", S/MIME [CMS-KEA] J. Pawling, "CMS KEA and SKIPJACK Conventions", S/MIME
Working Group Internet-Draft, December, 1999. Working Group Internet-Draft, December, 1999.
[LAW98] L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone,
"An efficient protocol for authenticated key
agreement", Technical report CORR 98-05, University of
Waterloo, 1998.
[LL97] C.H. Lim and P.J. Lee, "A key recovery attack on
discrete log-based schemes using a prime order
subgroup", B.S. Kaliski, Jr., editor, Advances in
Cryptology - Crypto '97, Lecture Notes in Computer
Science, vol. 1295, 1997, Springer-Verlag, pp. 249-263.
[MSG] B. Ramsdell, "S/MIME Version 3 Message Specification", [MSG] B. Ramsdell, "S/MIME Version 3 Message Specification",
RFC 2633, June 1999. RFC 2633, June 1999.
[MUST] S. Bradner, "Key Words for Use in RFCs to Indicate [CMS-DH] E. Rescorla, "Diffie-Hellman Key Agreement Method",
Requirement Levels", RFC 2119, March 1997. RFC 2631, June 1999.
[NIST-ECC] National Institute for Standards and Technology,
"Recommended Elliptic Curves for Federal Government
Use", July 1999,
<http://csrc.nist.gov/encryption/NISTReCur.pdf>
[IEEE1363] IEEE, "Standard Specifications for Public Key
Cryptography", IEEE 1363-2000 Specification, 2000,
Annex D.
[SEC1] Certicom Research, "Elliptic Curve Cryptography", SEC1,
February, 1999.
[SEC-WG-EC] Certicom Research, "ECC in X.509", SEC X.509 Working
Group Draft, August, 1999.
[SSG] R. Zuccherato, "Methods for Avoiding the Small-Subgroup
Attacks on the Diffie-Hellman Key Agreement Method for
S/MIME", RFC 2785, March 2000.
[X9.30] ANSI X9.30-1995, Part 1, "Public key cryptography using
irreversible algorithms for the financial services
industry: The Digital Signature Algorithm (Revised)",
1995.
[X9.42] "Agreement Of Symmetric Keys Using Diffie-Hellman and [SEC1] SECG, "Elliptic Curve Cryptography", Standards for
MQV Algorithms", ANSI draft, May 1999. Efficient Cryptography Group, 2000.
[X9.62] ANSI X9.62-1999, "Public Key Cryptography For The [SEC2] SECG, "Recommended Elliptic Curve Domain Parameters",
Financial Services Industry: The Elliptic Curve Digital Standards for Efficient Cryptography Group, 2000.
Signature Algorithm (ECDSA)", 1999.
[X9.63] "Public Key Cryptography For The Financial Services [SEC3] SECG, "ECC in X.509", Standards for Efficient
Industry: Key Agreement and Key Transport Using Cryptography Group, 2000.
Elliptic Curve Cryptography", Draft ANSI X9F1, October
1999.
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.
Intellectual Property Rights Intellectual Property Rights
This specification is based on ANSI specification X9.62 and X9.63. The IETF has been notified of intellectual property rights claimed
A variety of patent statements in these working may apply to this in regard to the specification contained in this document. For
specification. A later draft will attempt to identify a reference more information, consult the online list of claimed rights
for the ANSI X9F1 related claims. (http://www.ietf.org/ipr.html).
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification
can be obtained from the IETF Secretariat.
Acknowledgments Acknowledgments
The key agreement methods described in this document is based on The methods described in this document are based on work done by
work done by the ANSI X9F1 working group. The author wishes to the ANSI X9F1 working group. The authors wish to extend their
extend his thanks for their assistance. thanks to ANSI X9F1 for their assistance.
The author also wishes to thank Paul Lambert, Simon Blake-Wilson, The authors also wish to thank Paul Lambert and Peter de Rooij for
and Peter de Rooij for their patient assistance. The basis of this their patient assistance.
work is derived from the ANSI X9F1 working group and their
specifications for ECDSA and EC key agreement techniques.
Author's Address Authors' Address
Simon Blake-Wilson
Certicom Corp
5520 Explorer Drive #400
Mississauga, ON L4W 5L1
EMail: 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
EMail: dbrown@certicom.com EMail: dbrown@certicom.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
 End of changes. 

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