draft-ietf-smime-ecc-00.txt   draft-ietf-smime-ecc-01.txt 
INTERNET-DRAFT Paul A. Lambert INTERNET-DRAFT Daniel R. L. Brown
draft-ietf-smime-ecc-00.txt Certicom, Inc. draft-ietf-smime-ecc-01.txt Certicom Corp
22 October, 1999 14 July, 2000 Expires: 14 January 2001
Expires: 22 April 2000
Elliptic Curve S/MIME Use of ECC Algorithms in S/MIME
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with
provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are
documents of the Internet Engineering Task Force (IETF), its areas, and working documents of the Internet Engineering Task Force (IETF),
its working groups. Note that other groups may also distribute working its areas, and its working groups. Note that other groups may also
documents as Internet-Drafts. distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other
time. It is inappropriate to use Internet-Drafts as reference material documents at any time. It is inappropriate to use Internet-Drafts
or to cite them other than as "work in progress." as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document is the first draft of a profile for the incorporation This document is the second draft of a profile for the
of Elliptic Curve (EC) public key algorithms in the Cryptographic incorporation of Elliptic Curve Cryptography (ECC) public key
Message Syntax (CMS). The EC algorithms support the creation of algorithms in the Cryptographic Message Syntax (CMS). The ECC
digital signatures and the distribution of keys to encrypt or authen- algorithms support the creation of digital signatures and the
ticate message content. The definition of the algorithm processing exchange of keys to encrypt or authenticate message content. The
is based on the ANSI X9.63 draft, developed by the ANSI X9F1 definition of the algorithm processing is based on the ANSI X9.62
standard and the ANSI X9.63 draft, developed by the ANSI X9F1
working group. working group.
Table of Contents Table of Contents
1. Introduction 1 Introduction ........................................ 3
2. Signed-data 1.1 Requirement terminology ........................ 3
2.1. ECDSA Algorithm Support 2 EnvelopedData using ECC ............................. 3
3. Enveloped-data 2.1 EnvelopedData using X9.63 ECDH ................. 3
3.1 ECDH Algorithm Support 2.1.1 Fields of KeyAgreeRecipientInfo type .... 4
4. Authenticated-data 2.1.2 Actions of the sending agent ............ 5
2.1.3 Actions of the receiving agent .......... 5
2.2 EnvelopedData using X9.63 modified ECDH ........ 5
2.2.1 Fields of KeyAgreeRecipientInfo type .... 6
2.2.2 Actions of the sending agent ............ 6
2.2.3 Actions of the receiving agent .......... 6
2.3 EnvelopedData using X9.63 1-Pass MQV ........... 7
2.3.1 Fields of KeyAgreeRecipientInfo type .... 7
2.3.2 Actions of the sending agent ............ 9
2.3.3 Actions of the receiving agent .......... 9
2.3.4 Originator certificates ................. 9
3 AuthenticatedData using X9.63 1-Pass MQV ............ 10
3.1 AuthenticatedData using X9.63 1-pass MQV ....... 11
3.1.1 Fields of KeyAgreeRecipientInfo type .... 11
3.1.2 Actions of the sending agent ............ 11
3.1.3 Actions of the receiving agent .......... 11
3.1.4 Originator certificates ................. 11
3.1.5 Re-using a KEK with 1-Pass MQV .......... 11
4 SignedData using ECC ................................ 12
4.1 SignedData using X9.62 ECDSA ................... 12
4.1.1 Fields of the SignedData type ........... 13
4.1.2 Actions of the sending agent ............ 14
4.1.3 Actions of the receiving agent .......... 14
5 Certificates using ECC .............................. 15
6 SMIMECapabilites Attribute and ECC .................. 15
7 ASN.1 Types and Identifiers ......................... 15
7.1 Object identifiers ............................. 15
7.2 Type definitions ............................... 17
8 Summary ............................................. 17
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 (EC) public key cryptography in the CMS. The use of Elliptic Curve Cryptography (ECC) public key algorithms in
EC algorithms are incorporated into following CMS content types: the CMS. The ECC algorithms are incorporated into following CMS
content types:
o 'SignedData' to support EC based digital signatures - 'EnvelopedData' to support ECC public key agreement methods
o 'EnvelopedData' to support EC public key agreement to (ECDH and MQV) to generate pairwise key-encryption keys to
create shared keys to encrypt information encrypt content-encryption keys used for content encryption
o 'AuthenticatedData' to support EC public key agreement
to authenticate information with a MAC
The signature algorithm is based on the elliptic curve analog of the - 'AuthenticatedData' to support ECC based public key agreement
DSA signature [FIPS-186]. The Elliptic Curve Digital Signature Algorithm methods (MQV) to generate pairwise key-encryption keys to
(ECDSA) is defined by ANSI [X9.62]. A profile for the use of ECDSA in encrypt MAC keys used for content authentication
X.509 certificates [EPKIX] describes the means to carry EC keys in
X.509 certificates.
The key agreement mechanism is based on the elliptic curve analog of - 'SignedData' to support ECC based digital signature methods
the Diffie-Hellman key agreement mechanism [RFC2631][ANSIX9.42]. A (ECDSA) to sign content
wide variety of EC key-agreement mechanisms are defined in the draft
ANSI X9.63 specification for Key Agreement and Key Transport Using
Elliptic Curve Cryptography [X9.63]. The 1-Pass EC Diffie-Hellman
scheme (ECDH) was selected from X9.63 and is specified herein. The
ECDH key agreement algorithm is used in a 'ephemeral-static' mode where
the originator generates a unique ephemeral key for every key agreement.
The recipient publishes a fixed EC public key.or certificate containing
a EC public key.
2. Signed-data Certificates based on ECC digital signatures (ECDSA) are also
supported.
EC signatures are identified in CMS syntax by the 'signatureAlgorithm' 1.1 Requirements terminology
field in the 'signerInfos' portion of the 'SignedData' content type.
The EC parameters should not be included in the object identifier.
All necessary EC parameters can be inferred from the signers public key.
The EC public key of the signer must be available to the recipient for The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
validation processing. This public key may be contained in the option "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
'certificates' field of 'SignedData'. The incorporation of EC public this document are to be interpreted as described in RFC 2119
keys in X.509 certificates is specified in [EPKIX]. [MUST].
The 'SignerInfo' in 'SignedData', uses the 'sid' field to identify a 2 EnvelopedData using X9.63 ECC methods
specific key or certificate for the validation processing. This
identifier is either a distinguished name and serial number or a
key identifier. EC keys are small and in some applications the EC
public key may be used as the opaque octet string 'SubjectKeyIdentifier'.
This draft only specifies the application of the ECDSA algorithm Elliptic curve cryptography (ECC) methods for key agreement are
for CMS signed data. specified in [X9.63]. This specification refers to [X9.63] for the
cryptographic operations.
2.1. ECDSA Algorithm Support Note: all the key agreement methods here use the key derivation
method specified in [X9.63, Section 5.6.3].
The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in 2.1 EnvelopedData using X9.63 (standard) ephemeral-static ECDH
the ANSI X9.62 standard [X9.62]. ECDSA should always be used with the
SHA-1 message digest algorithm. The algorithm identifier for ECDSA is:
ecdsa-with-SHA1 OBJECT IDENTIFIER ::= Ephemeral-static Elliptic Curve Diffie-Hellman (ECDH) key agreement
{ iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 1 } 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].
The algorithm parameters field must not be present. 2.1.1 Fields of KeyAgreeRecipientInfo type
3. Enveloped-data When using ephemeral-static ECDH, the EnvelopedData RecipientInfos
KeyAgreementInfo fields must be used as follows:
Information is encrypted by the 'EnvelopedData' content type in the CMS. version is 3, as in [CMS, section 12.3.1.1].
This structure contains a set of 'RecipientInfo' that allows each
authorized recipient to decrypt the 'EncryptedContent'. EC public key
algorithms can be used to distribute the keys to decrypt the content by
creating a one-way shared secret between the originator and each
recipient. The basic steps of this process are:
1) Generate a key, K, and use this key to encrypt the content. This originator is the alternative originatorKey, as in [CMS, Section
is typically a symmetric algorithm and key like Triple-DES. 12.3.1.1]. The originatorKey algorithm fields contains the
id-ecPublicKey object identifer with absent parameters. The
id-ecPublicKey object identifier is:
2) For each recipient: id-ecPublicKey OBJECT IDENTIFIER ::= { iso(1) member-body(2)
ansi-x9-62(10045) keyType(2) 1 }
a) Obtain the recipients public key (often in a certificate). The originatorKey publicKey field contains the sender's
This is a static public key. ephemeral EC public key as determined below (by methods of
This key is identified by the 'KeyAgreeRecipientIdentifier'. [X9.63]).
When carried as a 'SubjectKeyIdentifier' the identifier may
be a EC public key.
b) Use the recipients public key to determine the ukm may be absent, as in [CMS, Section 12.3.1.1], and has the
appropriate type of EC key and parameters for the same meaning as in [CMS].
key agreement process.
c) Generate a unique new public ephemeral key with the keyEncryptionAlgorithm is the dhSinglePass-stdDH-sha1kdf-scheme
same set of defining parameters as the recipient. algorithm identifier, with parameter field KeyWrapAlgorithm
This key should only be used once. present, with the follow value and syntax:
This key is carried in 'OriginatorPublicKey'.
The key is always identified with a 'id-ecPublicKey'
object identifier. The parameters of this key
should be absent.
c) Select an appropriate key aggrement scheme and create dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
a shared secret, ZZ, using the two public public keys iso(1) identified-organization(3) tc68(133) country(16)
(static recipient and ephemeral originator). x9(840) x9-63(63) schemes(0) 2}
This key agreement algorithm is identified in the CMS
by the 'KeyEncryptionAlgorithm' object identifier.
d) Use the appropriate Key Derivation Function (KDF) to KeyWrapAlgorithm ::= AlgorithmIdentifier
transform the secret ZZ into a key appropriate to encrypt
the data encryption key K. This is the Key Encryption
Key (KEK). The KDF is typically based on the SHA-1 [FIPS-180]
hash algorithm.
e) Use the KEK to encrypt K using the key wrap algorithm. The KeyWrapAlgorithm indicates the symmetric encryption
The key wrap algorithm is identified by the 'KeyWrapAlgorithm' algorithm used to encrypt the CEK with the KEK.
parameter within the 'KeyEncryptionAlgorithm' object.
Where EC public keys are described by object identifiers ( like recipientEncryptedKeys contains an encrypted (wrapped)
'OriginatorPublicKey') the following definition must be used: content-encryption key and an identifier for each recipient, as
in [CMS, section 12.3.1.1].
id-ecPublicKey OBJECT IDENTIFIER ::= The next two sections specify actions of sending and receiving
{ iso(1) member-body(2) us(840) ansi-X9-62(10045) agents to handle ephemeral-static ECDH in keyAgreeRecipientInfo
id-public-key-type(2) 1 } fields of EnvelopedData.
Editors note - need to investigate the encoding for the ECAES 2.1.2 Actions of the sending agent
algorithm that direcetly combnes the definition of the key agreement
and the key encryption.
3.1 ECDH Algorithm Support When using ephemeral-static ECDH 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 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.
The processing of the 1-Pass Diffie-Hellman scheme is defined in 2.1.3 Actions of the receiving agent
Section 6.2. of ANSI X9.63 [X9.63]. Two variations of this key agreement
are defined. The standards 1-Pass Diffie-Hellman key
agreement is identified by:
dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= The receiving agent uses the following process on an EnvelopedData
{ iso(1) member-body(2) us(840) ansi-x9-63(??) schemes(0) 2 } to detect if ephemeral-static Diffie-Hellman is used to transfer
the CEK to the receiving agent, and if so to compute the
key-encryption key used to unwrap the CEK.
When the cofactor Diffie-Hellman primitive is used the object identifier The receiving agent determines the bit string "SharedData" from the
is defined as: 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
Modified ephemeral-static Elliptic Curve Diffie-Hellman (ECDH) key
agreement algorithm is identical to standard ECDH except that a
modified version of the Diffie-Hellman primitive [X9.63, Section
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
When using modified ephemeral-static ECDH, the EnvelopedData
RecipientInfos KeyAgreementInfo fields are the same as in those
specified in Section 2.1.1 of this document, except:
keyEncryptionAlgorithm is the
dhSinglePass-cofactorDH-sha1kdf-scheme algorithm identifier,
with parameter KeyWrapAlgorithm present, and the following value
and syntax:
dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) ansi-x9-63(??) schemes(0) 3 } { iso(1) identified-organization(3) tc68(133) country(16)
x9(840) x9-63(63) schemes(0) 3}
Editor note - need to identify one as prefered/mandatory. KeyWrapAlgorithm ::= AlgorithmIdentifier
The processing definition in [X9.63] includes SHA-1 as the KDF. 2.2.2 Actions of the sending agent
When using ECDH the following constraints on the 'KeyAgreeRecipientInfo' The actions of the sending agent are identical to the actions of
must be enforced: sending agent using standard ephemeral-static ECDH specified above
in Section 2.1.2, except that:
o The 'version' must be 3. - The sending agent uses the modified Diffie-Hellman primitive
o The 'originatorKey' algorithm fields must contain the of [X9.63, Section 5.4.2] rather than the standard
'id-ecPublicKey' object identifier with absent parameters. Diffie-Hellman primitive [X9.63, Section 5.4.1].
o The 'originatorKey public key field must contain the
sender's ephemeral public key.
o The 'ukm' field must be absent.
o The algorithm identifier parameter field for
'dhSinglePass-stdDH-sha1kdf-scheme' or
'dhSinglePass-cofactorDH-sha1kdf-scheme' is 'KeyWrapAlgorihtm',
and this parameter must be present.
o The KeyWrapAlgorithm denotes the KEK algorithm.
4. Authenticated-data Note: modified and standard ephemeral-static ECDH can only be used
within separate KeyAgreeRecipientInfo fields.
CMS content can be authenticated using a message authentication code (MAC) 2.2.3 Actions of the receiving agent
carried in a 'AuthenticatedData' content type. A symmetric algorithm is
used to validate the source and integrity of the content.
The use of EC public key techniques in 'AuthenticatedData' is nearly The actions of the receiving agent are identical to the actions of
identical to the processing for 'EnvelopedData' described in Section 3. receiving agent using standard ephemeral-static ECDH specified
The only difference in the processing is that the generated key above in Section 2.1.2, except that:
(Section 3, step 1) is used for the MAC operation. The remainder of the
processing of the 'RecipientInfo' fields is identical to Section 3.
Security Considerations - The receiving agent uses the modified Diffie-Hellman primitive
of [X9.63, Section 5.4.2] rather than the standard
Diffie-Hellman primitive [X9.63, Section 5.4.1].
The techniques specified herein do not guarantee that a particular 2.3 EnvelopedData using X9.63 1-Pass MQV
implementation is secure. Implementators need to consider small
subgroup attacks, storage of private key, generation of random
numbers, source and verification of public keys, appropriate key
size, reuse of ephemeral keys, trusted path to use of key,
non-repudiation versus authentication, etc.
The security of EC algorithms requires the careful selection of the In [X9.63, Appendix H.4.5], 1-Pass MQV is suggested for
field and curves parameters. Selection guidelines for EC parameters store-and-forward applications such as e-mail.
are provided in [NIST-ECC],[GEC1], [X9.63]
The strength of cryptographic algorithms depend on the effective The 1-Pass MQV key agreement method, specified in [X9.63, Section
key size. Key size recommendations are provided in [NIST-ECC] 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.
Intellectual Property Rights The originator's static EC public key is identified in the
originator field, usually by reference to a certificate. The
originator's ephemeral EC public is specified within the ukm field.
The recipient's static EC public key is identified according to
[CMS], within a rid field.
This specification is based on ANSI specification X9.62 and X9.63. A 2.3.1 Fields of KeyAgreeRecipientInfo type
variety of patent statements in these working may apply to this
specification. A later draft will attempt to identify a reference
for the ANSI X9F1 related claims.
Acknowledgments When using 1-Pass MQV, the EnvelopedData RecipientInfos
KeyAgreementInfo fields are used as follows:
The Key Agreement method described in this document is based on work version is 3, as in [CMS, section 12.3.1.1].
done by the ANSI X9F1 working group. The author wishes to extend his
thanks for their assistance.
The author also wishes to thank Simon Blake-Wilson, and Peter de Roij originator identifies the static EC public key of the sender.
for their patient assistance. The basis of this work is derived from It should be the one of the alternatives issuerAndSerialNumber
the ANSI X9F1 working group and their specifications for ECDSA and EC or subjectKeyIdentifier and point to one of the sender's
key agreement techniques. 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
EC public key.)
ukm is present. It identifies the ephemeral EC public key of
the sender. It may also identify some additional information
for purposes similar to those specified in [CMS, Section
12.3.1.1]. The ukm field contains an octet string which is the
DER encoding of the following ASN.1 type
MQVuserKeyingMaterial ::= SEQUENCE {
ephemeralPublicKey OriginatorPublicKey,
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
algorithm identifier, with parameter field KeyWrapAlgorithm
present, with the following values and syntax:
mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
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
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
The 1-Pass MQV scheme of [X9.63] has been selected in this document
for AuthenticatedData using ECC because it has security attributes
that are appropriate for the AuthenticatedData CMS type.
Note: in general, pure 'ephemeral-static' key agreement methods are
not suitable for AuthenticatedData because the originator's key is
ephemeral and therefore not authenticated.
Note: both SignedData and AuthenticatedData provide assurance to
the receiving agent that the content data originated from the
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
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
are equally capable producing any given AuthenticatedData. In
SignedData, only the sending agent is capable of producing the
SignedData.
Careful consideration should be applied to the choice of using
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
In general, using 1-Pass MQV in AuthenticatedData is similar to
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
together more efficiently by the re-using pairwise key-encryption
keys. A method to do this is specified in Section 3.1.5.
3.1.1 Fields of the KeyAgreementInfo type
The AuthenticatedData KeyAgreeRecipientInfo fields are used in the
same manner as the fields for the corresponding EnvelopedData
KeyAgreeRecipeintInfo fields of Section 2.3.1 of this document.
Note: the originator field should be one of the alternatives
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 may use the same actions as for EnvelopedData
with 1-Pass MQV, as specified in Section 2.3.2 of this document.
3.1.3 Actions of the receiving agent
The receiving agent may use the same actions as for EnvelopedData
with 1-Pass MQV, as specified in Section 2.3.3 of this document.
3.1.4 Originator certificates
If some recipients do not have other means to obtain the
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
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
When using 1-Pass MQV for an AuthenticatedData whose content is an
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"
key, encrypted with the previously generated KEK using 1-Pass MQV.
Generally, the pairwise KEK will have been generated within an
EnvelopedData. The KEKRecipientInfo KEKIdentifier keyIdentifier
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
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,
then the KeyAgreeRecipientInfo fields of the EnvelopedData are in
plaintext and therefore, the KEK can be computed before the
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
An elliptic curve cryptography (ECC) method for signing is
specified in [X9.62]. In a single SignedData type [CMS] many
signing algorithms may be used but within each SignerInfo field
only one signing algorithm can be used.
4.1 SignedData using X9.62 ECDSA
The Elliptic Curve Digital Signature Algorithm (ECDSA) is specified
in [X9.62]. The method is the elliptic curve analog of the [X9.30]
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
When using [X9.62] ECDSA in an SignedData SignerInfo type the
fields are as in [CMS], but with the following restrictions.
digestAlgorithm is the following algorithm identifier for SHA-1:
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 26 }
signatureAlgorithm is an algorithm identifer with parameters
field absent that identifies the ECDSA signature algorithm with
the object identifier:
ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) 10045 signatures(4) 1 }
signature is the DER encoding (as an octet string) of a value of
the [X9.62] ASN.1 type:
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
where the integers r and s are caculated according to [X9.62,
Section 5.3] using the signer's private key except that the
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
include the certificates for the EC public keys used in generation
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
The sending agent uses the message digest calculation process and
signature generation process for SignedData that are specified in
[CMS]. The sending agent follows the actions for ECDSA signature
generation specified in [X9.62, Section 5.3] with the following
exceptions:
- 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].
The sending agent uses the encoding process specified [X9.62,
Section 6.5] to convert (encode) the ECDSA signature as an octet
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
The receiving agent uses the message digest calculation process
and signature verification process for SignedData that are
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
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,
Section 6.5] to convert (decode) the octet string value of the
SignerInfo SignatureValue field to the [X9.62] signature. The
receiving agent uses DER decoding rules.
5 Certificates using ECC
The use of a certificates with ECC is specified in [EPKIX].
Further information on the use ECC with certificates is given in
[SECG-WG-EC].
6 SMIMECapabilities Attribute and ECC
A sending agent may choose to announce to receiving agents that it
supports one or more of the ECC algorithms in this document by
using SMIMECapabilities signed attribute as specified in [MSG,
Section 2.5.2].
The SMIMECapability capabilityID object identifiers for the
supported key agreement algorithms in this document are
dhSinglePass-stdDH-sha1kdf-scheme,
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
signature algorithm is the SEQUENCE with the capabilityID field
containing the object identifier ecdsa-with-SHA1 and the parameters
field absent.
7 ASN.1 Types and Identifiers
The ASN.1 types and object identifiers that are used in this
document are gathered together in this section for reference
purposes.
7.1 Object identifiers
The object identifiers used in this document are taken from [CMS],
[X9.63] and [X9.62].
The following object identifiers indicate the key agreement
algorithms used in this document:
dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) tc68(133) country(16) x9(840)
x9-63(63) schemes(0) 2}
dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) tc68(133) country(16)
x9(840) x9-63(63) schemes(0) 3}
mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) tc68(133) country(16) x9(840)
x9-63(63) schemes(0) 16}
The following object identifier indicates the digital signature
algorithm used in this document:
ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) 10045 signatures(4) 1 }
The following object identifier indicates the hash algorithm used
in this document:
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 26 }
The following object identifier is used in this document to
indicate an elliptic curve public key:
id-ecPublicKey OBJECT IDENTIFIER ::= { iso(1) member-body(2)
ansi-x9-62(10045) keyType(2) 1 }
7.2 Type definitions
The following ASN.1 type defintions are used.
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
MQVuserKeyingMaterial ::= SEQUENCE {
ephemeralPublicKey OriginatorPublicKey,
addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }
The former is taken from [X9.62]. In this document, DER encodings
as octet strings of values of the two above ASN.1 types
ECDSA-Sig-Value and MQVuserKeyingMaterial are used as values of
octet string ASN.1 types from [CMS]. An encoding of
ECDSA-Sig-Value is used as the value of a SignedData SignerInfo
SignatureValue and an encoding of MQVuserKeyingMaterial is used as
the value of EnvelopedData KeyAgreeRecipeintInfo UserKeyingMaterial
or AuthenticatedData KeyAgreeRecipeintInfo UserKeyingMaterial.
8 Summary
This document specifies how to use ECC methods with S/MIME CMS
type. The most notable advantage of ECC methods over integer
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
[CMS] content type AuthenticatedData. The cryptographic method is
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 References
[CMS] Housley, R., "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
2631, June 1999.
[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-180] Federal Information Processing Standards Publication
(FIPS PUB) 180-1, "Secure Hash Standard", 1995 April 17. (FIPS PUB) 180-1, "Secure Hash Standard", 1995 April
17.
[FIPS-186] Federal Information Processing Standards Publication [FIPS-186] Federal Information Processing Standards Publication
(FIPS PUB) 186, "Digital Signature Standard", 1994 May (FIPS PUB) 186, "Digital Signature Standard", 1994 May
19. 19.
[LAW98] L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone, [GEC1] Certicom Research, "Guidelines for Efficinet
"An efficient protocol for authenticated key agreement", Cryptography", GEC1, February, 1999.
Technical report CORR 98-05, University of Waterloo,
1998.
[LL97] C.H. Lim and P.J. Lee, "A key recovery attack on discrete [KEA] J. Pawling, "CMS KEA and SKIPJACK Conventions", S/MIME
log-based schemes using a prime order subgroup", B.S. Working Group Internet-Draft, December, 1999.
Kaliski, Jr., editor, Advances in Cryptology - Crypto
'97, Lecture Notes in Computer Science, vol. 1295, 1997,
Springer-Verlag, pp. 249-263.
[P1363] "Standard Specifications for Public Key Cryptography", [LAW98] L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone,
IEEE P1363 working group draft, 1998, Annex D. "An efficient protocol for authenticated key
agreement", Technical report CORR 98-05, University of
Waterloo, 1998.
[X9.42] "Agreement Of Symmetric Keys Using Diffie-Hellman and MQV [LL97] C.H. Lim and P.J. Lee, "A key recovery attack on
Algorithms", ANSI draft, May 1999. 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.
[X9.62] X9.62-1999, "Public Key Cryptography For The Financial [MSG] B. Ramsdell, "S/MIME Version 3 Message Specification",
Services Industry: The Elliptic Curve Digital Signature RFC 2633, June 1999.
Algorithm (ECDSA)".
[X9.63] "Public Key Cryptography For The Financial Services [MUST] S. Bradner, "Key Words for Use in RFCs to Indicate
Industry: Key Agreement and Key Transport Using Elliptic Requirement Levels", RFC 2119, March 1997.
Curve Cryptography", Draft ANSI X9F1, October 1999.
[NIST-ECC] National Institute for Standards and Technology, [NIST-ECC] National Institute for Standards and Technology,
"Recommended Elliptic Curves for Federal Government Use", "Recommended Elliptic Curves for Federal Government
July 1999, <http://csrc.nist.gov/encryption/NISTReCur.pdf> 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, [SEC1] Certicom Research, "Elliptic Curve Cryptography", SEC1,
February, 1999. February, 1999.
[GEC1] Certicom Research, "Guidelines for Efficinet Cryptography", [SEC-WG-EC] Certicom Research, "ECC in X.509", SEC X.509 Working
GEC1, February, 1999. 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
MQV Algorithms", ANSI draft, May 1999.
[X9.62] ANSI X9.62-1999, "Public Key Cryptography For The
Financial Services Industry: The Elliptic Curve Digital
Signature Algorithm (ECDSA)", 1999.
[X9.63] "Public Key Cryptography For The Financial Services
Industry: Key Agreement and Key Transport Using
Elliptic Curve Cryptography", Draft ANSI X9F1, October
1999.
Security Considerations
This specification is based on [CMS], [X9.62] and [X9.63] and the
appropriate security considerations of those documents apply.
Intellectual Property Rights
This specification is based on ANSI specification X9.62 and X9.63.
A variety of patent statements in these working may apply to this
specification. A later draft will attempt to identify a reference
for the ANSI X9F1 related claims.
Acknowledgments
The key agreement methods described in this document is based on
work done by the ANSI X9F1 working group. The author wishes to
extend his thanks for their assistance.
The author also wishes to thank Paul Lambert, Simon Blake-Wilson,
and Peter de Rooij for their patient assistance. The basis of this
work is derived from the ANSI X9F1 working group and their
specifications for ECDSA and EC key agreement techniques.
Author's Address Author's Address
Paul Lambert Daniel R. L. Brown
Certicom, Corp. Certicom Corp
25801 Industrial Blvd. 5520 Explorer Drive #400
Hayward, CA 94545 Mississauga, ON L4W 5L1
EMail: plambert@sprintmail.com EMail: dbrown@certicom.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied, published it or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of any published and distributed, in whole or in part, without restriction
kind, provided that the above copyright notice and this paragraph are of any kind, provided that the above copyright notice and this
included on all such copies and derivative works. However, this paragraph are included on all such copies and derivative works.
document itself may not be modified in any way, such as by removing However, this document itself may not be modified in any way, such
the copyright notice or references to the Internet Society or other as by removing the copyright notice or references to the Internet
Internet organizations, except as needed for the purpose of Society or other Internet organizations, except as needed for the
developing Internet standards in which case the procedures for purpose of developing Internet standards in which case the
copyrights defined in the Internet Standards process must be procedures for copyrights defined in the Internet Standards process
followed, or as required to translate it into languages other than must be followed, or as required to translate it into languages
English. other than English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

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