INTERNET-DRAFT Paul A. Lambert
draft-ietf-smime-ecc-00.txt Certicom, Inc.
22 October, 1999
Expires: 22 April 2000
Elliptic Curve S/MIME
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document is the first draft of a profile for the incorporation
of Elliptic Curve (EC) public key algorithms in the Cryptographic
Message Syntax (CMS). The EC algorithms support the creation of
digital signatures and the distribution of keys to encrypt or authen-
ticate message content. The definition of the algorithm processing
is based on the ANSI X9.63 draft, developed by the ANSI X9F1
working group.
Table of Contents
1. Introduction
2. Signed-data
2.1. ECDSA Algorithm Support
3. Enveloped-data
3.1 ECDH Algorithm Support
4. Authenticated-data
1. Introduction
The Cryptographic Message Syntax (CMS) is cryptographic algorithm
independent. This specification defines a standard profile for the
use of Elliptic Curve (EC) public key cryptography in the CMS. The
EC algorithms are incorporated into following CMS content types:
o 'SignedData' to support EC based digital signatures
o 'EnvelopedData' to support EC public key agreement to
create shared keys to encrypt information
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
DSA signature [FIPS-186]. The Elliptic Curve Digital Signature Algorithm
(ECDSA) is defined by ANSI [X9.62]. A profile for the use of ECDSA in
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
the Diffie-Hellman key agreement mechanism [RFC2631][ANSIX9.42]. A
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
EC signatures are identified in CMS syntax by the 'signatureAlgorithm'
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
validation processing. This public key may be contained in the option
'certificates' field of 'SignedData'. The incorporation of EC public
keys in X.509 certificates is specified in [EPKIX].
The 'SignerInfo' in 'SignedData', uses the 'sid' field to identify a
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
for CMS signed data.
2.1. ECDSA Algorithm Support
The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in
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 ::=
{ iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 1 }
The algorithm parameters field must not be present.
3. Enveloped-data
Information is encrypted by the 'EnvelopedData' content type in the CMS.
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
is typically a symmetric algorithm and key like Triple-DES.
2) For each recipient:
a) Obtain the recipients public key (often in a certificate).
This is a static public key.
This key is identified by the 'KeyAgreeRecipientIdentifier'.
When carried as a 'SubjectKeyIdentifier' the identifier may
be a EC public key.
b) Use the recipients public key to determine the
appropriate type of EC key and parameters for the
key agreement process.
c) Generate a unique new public ephemeral key with the
same set of defining parameters as the recipient.
This key should only be used once.
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
a shared secret, ZZ, using the two public public keys
(static recipient and ephemeral originator).
This key agreement algorithm is identified in the CMS
by the 'KeyEncryptionAlgorithm' object identifier.
d) Use the appropriate Key Derivation Function (KDF) to
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 key wrap algorithm is identified by the 'KeyWrapAlgorithm'
parameter within the 'KeyEncryptionAlgorithm' object.
Where EC public keys are described by object identifiers ( like
'OriginatorPublicKey') the following definition must be used:
id-ecPublicKey OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) ansi-X9-62(10045)
id-public-key-type(2) 1 }
Editors note - need to investigate the encoding for the ECAES
algorithm that direcetly combnes the definition of the key agreement
and the key encryption.
3.1 ECDH Algorithm Support
The processing of the 1-Pass Diffie-Hellman scheme is defined in
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 ::=
{ iso(1) member-body(2) us(840) ansi-x9-63(??) schemes(0) 2 }
When the cofactor Diffie-Hellman primitive is used the object identifier
is defined as:
dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) ansi-x9-63(??) schemes(0) 3 }
Editor note - need to identify one as prefered/mandatory.
The processing definition in [X9.63] includes SHA-1 as the KDF.
When using ECDH the following constraints on the 'KeyAgreeRecipientInfo'
must be enforced:
o The 'version' must be 3.
o The 'originatorKey' algorithm fields must contain the
'id-ecPublicKey' object identifier with absent parameters.
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
CMS content can be authenticated using a message authentication code (MAC)
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
identical to the processing for 'EnvelopedData' described in Section 3.
The only difference in the processing is that the generated key
(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 techniques specified herein do not guarantee that a particular
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
field and curves parameters. Selection guidelines for EC parameters
are provided in [NIST-ECC],[GEC1], [X9.63]
The strength of cryptographic algorithms depend on the effective
key size. Key size recommendations are provided in [NIST-ECC]
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 method 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 Simon Blake-Wilson, and Peter de Roij
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.
References
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 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
(FIPS PUB) 186, "Digital Signature Standard", 1994 May
19.
[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.
[P1363] "Standard Specifications for Public Key Cryptography",
IEEE P1363 working group draft, 1998, Annex D.
[X9.42] "Agreement Of Symmetric Keys Using Diffie-Hellman and MQV
Algorithms", ANSI draft, May 1999.
[X9.62] X9.62-1999, "Public Key Cryptography For The Financial
Services Industry: The Elliptic Curve Digital Signature
Algorithm (ECDSA)".
[X9.63] "Public Key Cryptography For The Financial Services
Industry: Key Agreement and Key Transport Using Elliptic
Curve Cryptography", Draft ANSI X9F1, October 1999.
[NIST-ECC] National Institute for Standards and Technology,
"Recommended Elliptic Curves for Federal Government Use",
July 1999,
[SEC1] Certicom Research, "Elliptic Curve Cryptography", SEC1,
February, 1999.
[GEC1] Certicom Research, "Guidelines for Efficinet Cryptography",
GEC1, February, 1999.
Author's Address
Paul Lambert
Certicom, Corp.
25801 Industrial Blvd.
Hayward, CA 94545
EMail: plambert@sprintmail.com
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.