draft-ietf-smime-ecc-02.txt   draft-ietf-smime-ecc-03.txt 
INTERNET-DRAFT Simon Blake-Wilson, Certicom Corp INTERNET-DRAFT Simon Blake-Wilson, Certicom Corp
draft-ietf-smime-ecc-02.txt Daniel R. L. Brown, Certicom Corp draft-ietf-smime-ecc-03.txt Daniel R. L. Brown, Certicom Corp
7 September, 2000 Expires: 7 March, 2001 Paul Lambert, Cosine Communications
2 March, 2001 Expires: 2 September, 2001
Use of ECC Algorithms in CMS Use of ECC Algorithms in CMS
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are all provisions of Section 10 of RFC2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may also its areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
skipping to change at page 2, line 8 skipping to change at page 2, line 8
(ECC) public-key algorithms in the Cryptographic Message Syntax (ECC) public-key algorithms in the Cryptographic Message Syntax
(CMS). The ECC algorithms support the creation of digital (CMS). The ECC algorithms support the creation of digital
signatures and the exchange of keys to encrypt or authenticate signatures and the exchange of keys to encrypt or authenticate
content. The definition of the algorithm processing is based on content. The definition of the algorithm processing is based on
the ANSI X9.62 standard and the ANSI X9.63 draft, developed by the the ANSI X9.62 standard and the ANSI X9.63 draft, developed by the
ANSI X9F1 working group. ANSI X9F1 working group.
Table of Contents Table of Contents
1 Introduction ........................................ 3 1 Introduction ........................................ 3
1.1 Requirement terminology ........................ 3 1.1 Requirements terminology ....................... 3
2 SignedData using ECC ................................ 3 2 SignedData using ECC ................................ 3
2.1 SignedData using ECDSA ......................... 3 2.1 SignedData using ECDSA ......................... 3
2.1.1 Fields of the SignedData ................ 3 2.1.1 Fields of the SignedData ................ 3
2.1.2 Actions of the sending agent ............ 4 2.1.2 Actions of the sending agent ............ 4
2.1.3 Actions of the receiving agent .......... 4 2.1.3 Actions of the receiving agent .......... 4
3 EnvelopedData using ECC ............................. 5 3 EnvelopedData using ECC ............................. 5
3.1 EnvelopedData using ECDH ....................... 5 3.1 EnvelopedData using ECDH ....................... 5
3.1.1 Fields of KeyAgreeRecipientInfo ......... 5 3.1.1 Fields of KeyAgreeRecipientInfo ......... 5
3.1.2 Actions of the sending agent ............ 5 3.1.2 Actions of the sending agent ............ 5
3.1.3 Actions of the receiving agent .......... 6 3.1.3 Actions of the receiving agent .......... 6
3.2 EnvelopedData using 1-Pass ECMQV ............... 6 3.2 EnvelopedData using 1-Pass ECMQV ............... 6
3.2.1 Fields of KeyAgreeRecipientInfo ......... 6 3.2.1 Fields of KeyAgreeRecipientInfo ......... 6
3.2.2 Actions of the sending agent ............ 7 3.2.2 Actions of the sending agent ............ 7
3.2.3 Actions of the receiving agent .......... 8 3.2.3 Actions of the receiving agent .......... 8
4 AuthenticatedData using ECC ............ ............ 8 4 AuthenticatedData using ECC ............ ............ 8
4.1 AuthenticatedData using 1-pass ECMQV ........... 8 4.1 AuthenticatedData using 1-pass ECMQV ........... 8
4.1.1 Fields of KeyAgreeRecipientInfo ......... 8 4.1.1 Fields of KeyAgreeRecipientInfo ......... 8
4.1.2 Actions of the sending agent ............ 8 4.1.2 Actions of the sending agent ............ 8
4.1.3 Actions of the receiving agent .......... 9 4.1.3 Actions of the receiving agent .......... 9
5 Recommended Elliptic Curves ......................... 9 5 Recommended Algorithms and Elliptic Curves .......... 9
6 Certificates using ECC .............................. 9 6 Certificates using ECC .............................. 9
7 SMIMECapabilities Attribute and ECC ................. 9 7 SMIMECapabilities Attribute and ECC ................. 9
8 ASN.1 Syntax ........................................ 9 8 ASN.1 Syntax ........................................ 9
8.1 Algorithm identifiers .......................... 9 8.1 Algorithm identifiers .......................... 10
8.2 Other syntax ................................... 11 8.2 Other syntax ................................... 11
9 Summary ............................................. 12 9 Summary ............................................. 12
References ............................................. 12 References ............................................. 12
Security Considerations ................................ 14 Security Considerations ................................ 14
Intellectual Property Rights ........................... 14 Intellectual Property Rights ........................... 14
Acknowledgments ........................................ 14 Acknowledgments ........................................ 14
Authors' Address ....................................... 14 Authors' Address ....................................... 14
Full Copyright Statement ............................... 15 Full Copyright Statement ............................... 15
1 Introduction 1 Introduction
skipping to change at page 5, line 45 skipping to change at page 5, line 45
Section 8.1) if the cofactor ECDH primitive is used. The Section 8.1) if the cofactor ECDH primitive is used. The
parameter field contains KeyWrapAlgorithm. The KeyWrapAlgorithm parameter field contains KeyWrapAlgorithm. The KeyWrapAlgorithm
is the algorithm identifier that indicates the symmetric is the algorithm identifier that indicates the symmetric
encryption algorithm used to encrypt the CEK with the KEK. encryption algorithm used to encrypt the CEK with the KEK.
3.1.2 Actions of the sending agent 3.1.2 Actions of the sending agent
When using ephemeral-static ECDH with EnvelopedData, the sending When using ephemeral-static ECDH with EnvelopedData, the sending
agent first obtains the recipient's EC public key and domain agent first obtains the recipient's EC public key and domain
parameters (e.g. from the recipient's certificate). The sending parameters (e.g. from the recipient's certificate). The sending
agent then determines an integer "keydatalen" which is the agent then determines an integer "keydatalen", which is the
key-size, in bits, of the KeyWrapAlgorithm and a bit string KeyWrapAlgorithm symmetric key-size in bits, and also a bit string
"SharedData". The "SharedData" bit string is the DER encoding of "SharedData", which is the DER encoding of ECC-CMS-SharedInfo (see
ASN.1 type X9-63-CMS-SharedInfo (see Section 8.2). The sending Section 8.2). The sending agent then performs the initiator
agent then performs the initiator transformation of the 1-Pass transformation of the 1-Pass Diffie-Hellman scheme specified in
Diffie-Hellman scheme specified in [X9.63, Section 6.2.1]. As a [X9.63, Section 6.2.1]. As a result the sending agent obtains:
result the sending agent obtains:
- an ephemeral public key, which is represented as a value of - an ephemeral public key, which is represented as a value of
the type ECPoint (see Section 8.2), encapsulated in a bit the type ECPoint (see Section 8.2), encapsulated in a bit
string and placed in the KeyAgreeRecipientInfo originator string and placed in the KeyAgreeRecipientInfo originator
field, and field, and
- a shared secret bit string "KeyData" which is used as the - a shared secret bit string "KeyData" which is used as the
pairwise key-encryption key for that recipient. pairwise key-encryption key for that recipient.
3.1.3 Actions of the receiving agent 3.1.3 Actions of the receiving agent
skipping to change at page 7, line 28 skipping to change at page 7, line 28
KeyWrapAlgorithm. The KeyWrapAlgorithm indicates the symmetric KeyWrapAlgorithm. The KeyWrapAlgorithm indicates the symmetric
encryption algorithm used to encrypt the CEK with the KEK encryption algorithm used to encrypt the CEK with the KEK
generated using the 1-Pass ECMQV algorithm. generated using the 1-Pass ECMQV algorithm.
3.2.2 Actions of the sending agent 3.2.2 Actions of the sending agent
When using 1-Pass ECMQV with EnvelopedData, the sending agent first When using 1-Pass ECMQV with EnvelopedData, the sending agent first
obtains the recipient's EC public key and domain parameters, obtains the recipient's EC public key and domain parameters,
(e.g. from the recipient's certificate) and checks that the domain (e.g. from the recipient's certificate) and checks that the domain
parameters are the same. The sending agent then determines an parameters are the same. The sending agent then determines an
integer "keydatalen" which is the key-size, in bits, of the integer "keydatalen", which is the KeyWrapAlgorithm symmetric
KeyWrapAlgorithm and a bit string "SharedData" (see Section 8.2). key-size in bits, and also a bit string "SharedData", which is the
The sending agent then performs the initiator transformation of the DER encoding of ECC-CMS-SharedInfo (see Section 8.2). The sending
1-Pass ECMQV scheme specified in [X9.63, Section 6.9.1]. As a agent then performs the initiator transformation of the 1-Pass
result the sending agent obtains ECMQV scheme specified in [X9.63, Section 6.9.1]. As a result the
sending agent obtains
- an ephemeral public key, which is represented as a value of - an ephemeral public key, which is represented as a value of
type ECPoint (see Section 8.2), encapsulated in a bit string, type ECPoint (see Section 8.2), encapsulated in a bit string,
placed in an MQVuserKeyingMaterial ephemeralPublicKey placed in an MQVuserKeyingMaterial ephemeralPublicKey
publicKey field (see Section 8.2), and publicKey field (see Section 8.2), and
- a shared secret bit string "KeyData" which is used as the - a shared secret bit string "KeyData" which is used as the
pairwise key-encryption key for that recipient. Parity bits pairwise key-encryption key for that recipient. Parity bits
are adjust according to the key wrap algorithm. are adjust according to the key wrap algorithm.
skipping to change at page 9, line 12 skipping to change at page 9, line 12
noticing [BON]. A sending agent who is concerned with such an noticing [BON]. A sending agent who is concerned with such an
attack should use a separate AuthenticatedData for each recipient. attack should use a separate AuthenticatedData for each recipient.
4.1.3 Actions of the receiving agent 4.1.3 Actions of the receiving agent
The receiving agent uses the same actions as for EnvelopedData The receiving agent uses the same actions as for EnvelopedData
with 1-Pass ECMQV, as specified in Section 3.2.3 of this document. with 1-Pass ECMQV, as specified in Section 3.2.3 of this document.
Note: see Note in Section 4.1.2. Note: see Note in Section 4.1.2.
5 Recommended Elliptic Curves 5 Recommended Algorithms and Elliptic Curves
It is strongly recommended that agents use the elliptic curve Implementations of this specification SHOULD implement SignedData
domain parameters recommended by ANSI [X9.62, X9.63], NIST [REC-EC] with ECDSA and EnvelopedData with ECDH. Implementations MAY
and SECG [SEC3]. implement the other techniques specified.
Furthermore, in order to encourage interoperability,
implementations SHOULD use the elliptic curve domain parameters
recommended by ANSI [X9.62, X9.63], NIST [FIPS186-2] and SECG [SEC3].
6 Certificates using ECC 6 Certificates using ECC
Internet X.509 certificates [PKI] may be used in conjunction with Internet X.509 certificates [PKI] may be used in conjunction with
this specification to distribute agents' public keys. The use of this specification to distribute agents' public keys. The use of
ECC algorithms and keys within X.509 certificates is specified in ECC algorithms and keys within X.509 certificates is specified in
[PKI-ALG]. More details can be found in [SEC3]. [PKI-ALG]. More details can be found in [SEC3].
7 SMIMECapabilities Attribute and ECC 7 SMIMECapabilities Attribute and ECC
skipping to change at page 11, line 47 skipping to change at page 12, line 4
MQVuserKeyingMaterial value is DER-encoded and placed within in a MQVuserKeyingMaterial value is DER-encoded and placed within in a
ukm field of EnvelopedData or AuthenticatedData. ukm field of EnvelopedData or AuthenticatedData.
When using ECDH or ECMQV with EnvelopedData or AuthenticatedData, When using ECDH or ECMQV with EnvelopedData or AuthenticatedData,
the key-encryption keys are derived by using the type: the key-encryption keys are derived by using the type:
ECC-CMS-SharedInfo ::= SEQUENCE { ECC-CMS-SharedInfo ::= SEQUENCE {
keyInfo AlgorithmIdentifier, keyInfo AlgorithmIdentifier,
entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL, entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
suppPubInfo [2] EXPLICIT OCTET STRING } suppPubInfo [2] EXPLICIT OCTET STRING }
The fields of ECC-CMS-SharedInfo are as follows:
The fields of ECC-63-CMS-SharedInfo are as follows:
keyInfo contains the object identifier of the key-encryption keyInfo contains the object identifier of the key-encryption
algorithm (used to wrap the CEK) and NULL parameters. algorithm (used to wrap the CEK) and NULL parameters.
entityUInfo optionally contains additional keying material entityUInfo optionally contains additional keying material
supplied by the sending agent. When used with ECDH and CMS, the supplied by the sending agent. When used with ECDH and CMS, the
entityUInfo field contains the octet string ukm. When used with entityUInfo field contains the octet string ukm. When used with
ECMQV and CMS, the entityUInfo contains the octet string ECMQV and CMS, the entityUInfo contains the octet string
addedukm (encoded in MQVuserKeyingMaterial). addedukm (encoded in MQVuserKeyingMaterial).
skipping to change at page 12, line 33 skipping to change at page 12, line 37
This document specifies how to use ECC algorithms with the S/MIME This document specifies how to use ECC algorithms with the S/MIME
CMS. Use of ECC algorithm within CMS can result in reduced CMS. Use of ECC algorithm within CMS can result in reduced
processing requirements for S/MIME agents, and reduced bandwidth processing requirements for S/MIME agents, and reduced bandwidth
for CMS messages. for CMS messages.
References References
[X9.42] ANSI X9.42-xxxx, "Agreement Of Symmetric Keys Using [X9.42] ANSI X9.42-xxxx, "Agreement Of Symmetric Keys Using
Diffie-Hellman and MQV Algorithms", American National Diffie-Hellman and MQV Algorithms", American National
Standards Institute, 2000, Working draft. Standards Institute, 2001, Working draft.
[X9.62] ANSI X9.62-1999, "Public Key Cryptography For The [X9.62] ANSI X9.62-1999, "Public Key Cryptography For The
Financial Services Industry: The Elliptic Curve Financial Services Industry: The Elliptic Curve
Digital Signature Algorithm (ECDSA)", Americal Digital Signature Algorithm (ECDSA)", Americal
National Standards Institute, 1999. National Standards Institute, 1999.
[X9.63] ANSI X9.63-xzxx, "Public Key Cryptography For The [X9.63] ANSI X9.63-xxxx, "Public Key Cryptography For The
Financial Services Industry: Key Agreement and Key Financial Services Industry: Key Agreement and Key
Transport Using Elliptic Curve Cryptography", American Transport Using Elliptic Curve Cryptography", American
National Standards Institute, 1999, Working draft. National Standards Institute, 2000, Working draft.
[PKI-ALG] L. Bassham, R. Housley and W. Polk, "Internet X.509 [PKI-ALG] L. Bassham, R. Housley and W. Polk, "Algorithms and
Public Key Infrastructure Representation of Public Identifiers for the Internet X.509 Public Key
Keys and Digital Signatures in Internet X.509 Public Infrastructure Certificate and CRL profile", PKIX
Key Infrastructure Certificates", PKIX Working Group Working Group Internet-Draft, November 2000.
Internet-Draft, July 2000.
[BON] D. Boneh, "The Security of Multicast MAC", [BON] D. Boneh, "The Security of Multicast MAC",
Presentation at Selected Areas of Cryptography 2000, Presentation at Selected Areas of Cryptography 2000,
Center for Applied Cryptographic Research, University Center for Applied Cryptographic Research, University
of Waterloo, 2000 of Waterloo, 2000
[MUST] S. Bradner, "Key Words for Use in RFCs to Indicate [MUST] S. Bradner, "Key Words for Use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[FIPS-180] FIPS 180-1, "Secure Hash Standard", National Institute [FIPS-180] FIPS 180-1, "Secure Hash Standard", National Institute
of Standards and Technology, April 17, 1995. of Standards and Technology, April 17, 1995.
[FIPS-186-2] FIPS 186-2, "Digital Signature Standard", National [FIPS-186-2] FIPS 186-2, "Digital Signature Standard", National
Institute of Standards and Technology, 15 February Institute of Standards and Technology, 15 February
2000. 2000.
[PKI] W. Ford, R. Housley, W. Polk and D. Solo, "Internet X.509 [PKI] W. Ford, R. Housley, W. Polk and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and CRL Public Key Infrastructure Certificate and CRL
Profile", PKIX Working Group Internet-Draft, July Profile", PKIX Working Group Internet-Draft, January
2000. 2001.
[CMS] R. Housley, "Cryptographic Message Syntax", RFC 2630, [CMS] R. Housley, "Cryptographic Message Syntax", RFC 2630,
June 1999. June 1999.
[IEEE1363] IEEE P1363, "Standard Specifications for Public Key [IEEE1363] IEEE P1363, "Standard Specifications for Public Key
Cryptography", Institute of Electrical and Electronics Cryptography", Institute of Electrical and Electronics
Engineers, 2000. Engineers, 2000.
[LMQSV] L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone, [LMQSV] L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone,
"An efficient protocol for authenticated key agreement", "An efficient protocol for authenticated key agreement",
Technical report CORR 98-05, University of Waterloo, Technical report CORR 98-05, University of Waterloo,
1998. 1998.
[REC-EC] National Institute of Standards and Technology, [CMS-KEA] J. Pawling, "CMS KEA and SKIPJACK Conventions", RFC
"Recommended Elliptic Curves for Federal Government 2876, July 2000.
Use", July, 1999. Available from:
<http://csrc.nist.gov/encryption/>.
[CMS-KEA] J. Pawling, "CMS KEA and SKIPJACK Conventions", S/MIME
Working Group Internet-Draft, December, 1999.
[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.
[CMS-DH] E. Rescorla, "Diffie-Hellman Key Agreement Method", [CMS-DH] E. Rescorla, "Diffie-Hellman Key Agreement Method",
RFC 2631, June 1999. RFC 2631, June 1999.
[SEC1] SECG, "Elliptic Curve Cryptography", Standards for [SEC1] SECG, "Elliptic Curve Cryptography", Standards for
Efficient Cryptography Group, 2000. Efficient Cryptography Group, 2000.
skipping to change at page 14, line 16 skipping to change at page 14, line 16
Standards for Efficient Cryptography Group, 2000. Standards for Efficient Cryptography Group, 2000.
[SEC3] SECG, "ECC in X.509", Standards for Efficient [SEC3] SECG, "ECC in X.509", Standards for Efficient
Cryptography Group, 2000. Cryptography Group, 2000.
Security Considerations Security Considerations
This specification is based on [CMS], [X9.62] and [X9.63] and the This specification is based on [CMS], [X9.62] and [X9.63] and the
appropriate security considerations of those documents apply. appropriate security considerations of those documents apply.
In addition, implementors of AuthenticatedData should be aware of
the concerns expressed in [BON] when using AuthenticatedData to
send messages to more than one recipient.
Intellectual Property Rights Intellectual Property Rights
The IETF has been notified of intellectual property rights claimed The IETF has been notified of intellectual property rights claimed
in regard to the specification contained in this document. For in regard to the specification contained in this document. For
more information, consult the online list of claimed rights more information, consult the online list of claimed rights
(http://www.ietf.org/ipr.html). (http://www.ietf.org/ipr.html).
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
skipping to change at page 14, line 41 skipping to change at page 14, line 45
claims of rights made available for publication and any assurances claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat. can be obtained from the IETF Secretariat.
Acknowledgments Acknowledgments
The methods described in this document are based on work done by The methods described in this document are based on work done by
the ANSI X9F1 working group. The authors wish to extend their the ANSI X9F1 working group. The authors wish to extend their
thanks to ANSI X9F1 for their assistance. thanks to ANSI X9F1 for their assistance. The authors also wish to
thank Peter de Rooij for his patient assistance.
The authors also wish to thank Paul Lambert and Peter de Rooij for
their patient assistance.
Authors' Address Authors' Address
Simon Blake-Wilson Simon Blake-Wilson
Certicom Corp Certicom Corp
5520 Explorer Drive #400 5520 Explorer Drive #400
Mississauga, ON L4W 5L1 Mississauga, ON L4W 5L1
EMail: sblakewi@certicom.com e-mail: sblakewi@certicom.com
Daniel R. L. Brown Daniel R. L. Brown
Certicom Corp Certicom Corp
5520 Explorer Drive #400 5520 Explorer Drive #400
Mississauga, ON L4W 5L1 Mississauga, ON L4W 5L1
EMail: dbrown@certicom.com e-mail: dbrown@certicom.com
Paul Lambert
Director of Security Applications
CoSine Communications
1200 Bridge Parkway
Redwood City, CA, 94065
http://www.cosinecom.com
e-mail: plambert@cosinecom.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2001). 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 others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied, it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works. paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the Society or other Internet organizations, except as needed for the
 End of changes. 

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