draft-ietf-smime-ecc-03.txt | draft-ietf-smime-ecc-04.txt | |||
---|---|---|---|---|

INTERNET-DRAFT Simon Blake-Wilson, Certicom Corp | INTERNET-DRAFT Simon Blake-Wilson, Certicom Corp | |||

draft-ietf-smime-ecc-03.txt Daniel R. L. Brown, Certicom Corp | draft-ietf-smime-ecc-04.txt Daniel R. L. Brown, Certicom Corp | |||

Paul Lambert, Cosine Communications | Paul Lambert, Cosine Communications | |||

2 March, 2001 Expires: 2 September, 2001 | 12 March, 2001 Expires: 12 September, 2001 | |||

Use of ECC Algorithms in CMS | Use of ECC Algorithms in CMS | |||

Status of this Memo | Status of this Memo | |||

This document is an Internet-Draft and is in full conformance with | This document is an Internet-Draft and is in full conformance with | |||

all provisions of Section 10 of RFC2026. Internet-Drafts are | all provisions of Section 10 of RFC2026. Internet-Drafts are | |||

working documents of the Internet Engineering Task Force (IETF), | working documents of the Internet Engineering Task Force (IETF), | |||

its areas, and its working groups. Note that other groups may also | its areas, and its working groups. Note that other groups may also | |||

distribute working documents as Internet-Drafts. | distribute working documents as Internet-Drafts. | |||

skipping to change at page 2, line 17 | skipping to change at page 2, line 17 | |||

1 Introduction ........................................ 3 | 1 Introduction ........................................ 3 | |||

1.1 Requirements terminology ....................... 3 | 1.1 Requirements terminology ....................... 3 | |||

2 SignedData using ECC ................................ 3 | 2 SignedData using ECC ................................ 3 | |||

2.1 SignedData using ECDSA ......................... 3 | 2.1 SignedData using ECDSA ......................... 3 | |||

2.1.1 Fields of the SignedData ................ 3 | 2.1.1 Fields of the SignedData ................ 3 | |||

2.1.2 Actions of the sending agent ............ 4 | 2.1.2 Actions of the sending agent ............ 4 | |||

2.1.3 Actions of the receiving agent .......... 4 | 2.1.3 Actions of the receiving agent .......... 4 | |||

3 EnvelopedData using ECC ............................. 5 | 3 EnvelopedData using ECC ............................. 5 | |||

3.1 EnvelopedData using ECDH ....................... 5 | 3.1 EnvelopedData using ECDH ....................... 5 | |||

3.1.1 Fields of KeyAgreeRecipientInfo ......... 5 | 3.1.1 Fields of KeyAgreeRecipientInfo ......... 5 | |||

3.1.2 Actions of the sending agent ............ 5 | 3.1.2 Actions of the sending agent ............ 6 | |||

3.1.3 Actions of the receiving agent .......... 6 | 3.1.3 Actions of the receiving agent .......... 6 | |||

3.2 EnvelopedData using 1-Pass ECMQV ............... 6 | 3.2 EnvelopedData using 1-Pass ECMQV ............... 6 | |||

3.2.1 Fields of KeyAgreeRecipientInfo ......... 6 | 3.2.1 Fields of KeyAgreeRecipientInfo ......... 7 | |||

3.2.2 Actions of the sending agent ............ 7 | 3.2.2 Actions of the sending agent ............ 7 | |||

3.2.3 Actions of the receiving agent .......... 8 | 3.2.3 Actions of the receiving agent .......... 8 | |||

4 AuthenticatedData using ECC ............ ............ 8 | 4 AuthenticatedData using ECC ............ ............ 8 | |||

4.1 AuthenticatedData using 1-pass ECMQV ........... 8 | 4.1 AuthenticatedData using 1-pass ECMQV ........... 8 | |||

4.1.1 Fields of KeyAgreeRecipientInfo ......... 8 | 4.1.1 Fields of KeyAgreeRecipientInfo ......... 8 | |||

4.1.2 Actions of the sending agent ............ 8 | 4.1.2 Actions of the sending agent ............ 8 | |||

4.1.3 Actions of the receiving agent .......... 9 | 4.1.3 Actions of the receiving agent .......... 9 | |||

5 Recommended Algorithms and Elliptic Curves .......... 9 | 5 Recommended Algorithms and Elliptic Curves .......... 9 | |||

6 Certificates using ECC .............................. 9 | 6 Certificates using ECC .............................. 9 | |||

7 SMIMECapabilities Attribute and ECC ................. 9 | 7 SMIMECapabilities Attribute and ECC ................. 9 | |||

8 ASN.1 Syntax ........................................ 9 | 8 ASN.1 Syntax ........................................ 10 | |||

8.1 Algorithm identifiers .......................... 10 | 8.1 Algorithm identifiers .......................... 10 | |||

8.2 Other syntax ................................... 11 | 8.2 Other syntax ................................... 11 | |||

9 Summary ............................................. 12 | 9 Summary ............................................. 13 | |||

References ............................................. 12 | References ............................................. 13 | |||

Security Considerations ................................ 14 | Security Considerations ................................ 14 | |||

Intellectual Property Rights ........................... 14 | Intellectual Property Rights ........................... 14 | |||

Acknowledgments ........................................ 14 | Acknowledgments ........................................ 15 | |||

Authors' Address ....................................... 14 | Authors' Addresses ..................................... 15 | |||

Full Copyright Statement ............................... 15 | Full Copyright Statement ............................... 16 | |||

1 Introduction | 1 Introduction | |||

The Cryptographic Message Syntax (CMS) is cryptographic algorithm | The Cryptographic Message Syntax (CMS) is cryptographic algorithm | |||

independent. This specification defines a standard profile for the | independent. This specification defines a standard profile for the | |||

use of Elliptic Curve Cryptography (ECC) public key algorithms in | use of Elliptic Curve Cryptography (ECC) public key algorithms in | |||

the CMS. The ECC algorithms are incorporated into the following | the CMS. The ECC algorithms are incorporated into the following | |||

CMS content types: | CMS content types: | |||

- 'SignedData' to support ECC-based digital signature methods | - 'SignedData' to support ECC-based digital signature methods | |||

(ECDSA) to sign content | (ECDSA) to sign content | |||

- 'EnvelopedData' to support ECC-based public-key agreement | - 'EnvelopedData' to support ECC-based public-key agreement | |||

methods (ECDH and ECMQV) to generate pairwise key-encryption | methods (ECDH and ECMQV) to generate pairwise key-encryption | |||

keys to encrypt content-encryption keys used for content | keys to encrypt content-encryption keys used for content | |||

encryption | encryption | |||

- 'AuthenticatedData' to support ECC-based public-key agreement | - 'AuthenticatedData' to support ECC-based public-key agreement | |||

methods (ECMQV) to generate pairwise key-encryption keys to | methods (ECMQV) to generate pairwise key-encryption keys to | |||

encrypt MAC keys used for content authentication | encrypt MAC keys used for content authentication and integrity | |||

Certification of EC public keys is also described to provide | Certification of EC public keys is also described to provide | |||

public-key distribution in support of the specified techniques. | public-key distribution in support of the specified techniques. | |||

1.1 Requirements terminology | 1.1 Requirements terminology | |||

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in | |||

this document are to be interpreted as described in RFC 2119 | this document are to be interpreted as described in RFC 2119 | |||

[MUST]. | [MUST]. | |||

skipping to change at page 3, line 47 | skipping to change at page 3, line 47 | |||

This section describes how to use ECC algorithms with the CMS | This section describes how to use ECC algorithms with the CMS | |||

SignedData format to sign data. | SignedData format to sign data. | |||

2.1 SignedData using ECDSA | 2.1 SignedData using ECDSA | |||

This section describes how to use the Elliptic Curve Digital | This section describes how to use the Elliptic Curve Digital | |||

Signature Algorithm (ECDSA) with SignedData. ECDSA is specified in | Signature Algorithm (ECDSA) with SignedData. ECDSA is specified in | |||

[X9.62]. The method is the elliptic curve analog of the | [X9.62]. The method is the elliptic curve analog of the | |||

Digital Signature Algorithm (DSA) [FIPS 186-2]. | Digital Signature Algorithm (DSA) [FIPS 186-2]. | |||

In an implementation that uses ECDSA with CMS SignedData, the | ||||

following techniques and formats MUST be used. | ||||

2.1.1 Fields of the SignedData | 2.1.1 Fields of the SignedData | |||

When using ECDSA with SignedData the fields of SignerInfo are as in | When using ECDSA with SignedData the fields of SignerInfo are as in | |||

[CMS], but with the following restrictions: | [CMS], but with the following restrictions: | |||

digestAlgorithm contains the algorithm identifier sha-1 (see | digestAlgorithm MUST contain the algorithm identifier sha-1 (see | |||

Section 8.1) which identifies the SHA-1 hash algorithm. | Section 8.1) which identifies the SHA-1 hash algorithm. | |||

signatureAlgorithm contains the algorithm identifier | signatureAlgorithm contains the algorithm identifier | |||

ecdsa-with-SHA1 (see Section 8.1) which identifies the ECDSA | ecdsa-with-SHA1 (see Section 8.1) which identifies the ECDSA | |||

signature algorithm. | signature algorithm. | |||

signature contains the DER encoding (as an octet string) of a | signature MUST contain the DER encoding (as an octet string) of | |||

value of the ASN.1 type ECDSA-Sig-Value (see Section | a value of the ASN.1 type ECDSA-Sig-Value (see Section 8.2). | |||

7.2). | ||||

When using ECDSA, the SignedData certificates field may include the | When using ECDSA, the SignedData certificates field MAY include the | |||

certificate(s) for the EC public key(s) used in the generation of | certificate(s) for the EC public key(s) used in the generation of | |||

the ECDSA signatures in SignedData. ECC certificates are discussed | the ECDSA signatures in SignedData. ECC certificates are discussed | |||

in Section 6. | in Section 6. | |||

2.1.2 Actions of the sending agent | 2.1.2 Actions of the sending agent | |||

When using ECDSA with SignedData, the sending agent uses the | When using ECDSA with SignedData, the sending agent uses the | |||

message digest calculation process and signature generation process | message digest calculation process and signature generation process | |||

for SignedData that are specified in [CMS]. To sign data, the | for SignedData that are specified in [CMS]. To sign data, the | |||

sending agent uses the signature method specified in [X9.62, | sending agent uses the signature method specified in [X9.62, | |||

Section 5.3] with the following exceptions: | Section 5.3] with the following exceptions: | |||

- In [X9.62, Section 5.3.1], the integer "e" shall instead be | - In [X9.62, Section 5.3.1], the integer "e" is instead | |||

determined by converting the octet string resulting from [CMS, | determined by converting the message digest generated | |||

Section 5.4] to an integer using the data conversion method in | according to [CMS, Section 5.4] to an integer using the data | |||

[X9.62, Section 4.3.2]. | conversion method in [X9.62, Section 4.3.2]. | |||

The sending agent encodes the resulting signature using the | The sending agent encodes the resulting signature using the | |||

ECDSA-sig-value syntax and places it in the SignerInfo signature | ECDSA-Sig-Value syntax (see Section 8.2) and places it in the | |||

field. | SignerInfo signature field. | |||

2.1.3 Actions of the receiving agent | 2.1.3 Actions of the receiving agent | |||

When using ECDSA with SignedData, the receiving agent uses the | When using ECDSA with SignedData, the receiving agent uses the | |||

message digest calculation process and signature verification | message digest calculation process and signature verification | |||

process for SignedData that are specified in [CMS]. To verify | process for SignedData that are specified in [CMS]. To verify | |||

SignedData, the receiving agent uses the signature verification | SignedData, the receiving agent uses the signature verification | |||

method specified in [X9.62, Section 5.4] with the following | method specified in [X9.62, Section 5.4] with the following | |||

exceptions: | exceptions: | |||

- In [X9.62, Section 5.4.1] the integer "e" shall instead be | - In [X9.62, Section 5.4.1] the integer "e'" is instead | |||

determined by converting the octet string resulting from [CMS, | determined by converting the message digest generated | |||

Section 5.4] to an integer using the data conversion method in | according to [CMS, Section 5.4] to an integer using the data | |||

[X9.62, Section 4.3.2]. | conversion method in [X9.62, Section 4.3.2]. | |||

In order to verify the signature, the receiving agent retrieves the | In order to verify the signature, the receiving agent retrieves the | |||

integers r and s from the SignerInfo signature field of the | integers r and s from the SignerInfo signature field of the | |||

received message. | received message. | |||

3 EnvelopedData using ECC Algorithms | 3 EnvelopedData using ECC Algorithms | |||

This section describes how to use ECC algorithms with the CMS | This section describes how to use ECC algorithms with the CMS | |||

EnvelopedData format. | EnvelopedData format. | |||

3.1 EnvelopedData using (ephemeral-static) ECDH | 3.1 EnvelopedData using (ephemeral-static) ECDH | |||

This section describes how to use ephemeral-static Elliptic Curve | This section describes how to use ephemeral-static Elliptic Curve | |||

Diffie-Hellman (ECDH) key agreement algorithm with EnvelopedData. | Diffie-Hellman (ECDH) key agreement algorithm with EnvelopedData. | |||

Ephemeral-static ECDH is specified in [X9.63]. Ephemeral-static | Ephemeral-static ECDH is specified in [X9.63]. Ephemeral-static | |||

ECDH is the the elliptic curve analog of the ephemeral-static | ECDH is the elliptic curve analog of the ephemeral-static | |||

Diffie-Hellman key agreement algorithm specified jointly in the | Diffie-Hellman key agreement algorithm specified jointly in the | |||

documents [CMS, Section 12.3.1.1] and [CMS-DH]. | documents [CMS, Section 12.3.1.1] and [CMS-DH]. | |||

In an implementation that uses ECDH with CMS EnvelopedData with key | ||||

agreement, the following techniques and formats MUST be used. | ||||

3.1.1 Fields of KeyAgreeRecipientInfo | 3.1.1 Fields of KeyAgreeRecipientInfo | |||

When using ephemeral-static ECDH with EnvelopedData, the fields of | When using ephemeral-static ECDH with EnvelopedData, the fields of | |||

KeyAgreeRecipientInfo are as in [CMS], but with the following | KeyAgreeRecipientInfo are as in [CMS], but with the following | |||

restrictions: | restrictions: | |||

originator is the alternative originatorKey. The originatorKey | originator MUST be the alternative originatorKey. The | |||

algorithm field contains the id-ecPublicKey object identifier | originatorKey algorithm field MUST contain the id-ecPublicKey | |||

(see Section 8.1) with NULL parameters. The originatorKey | object identifier (see Section 8.1) with NULL parameters. The | |||

publicKey field contains the DER-encoding of a value of the | originatorKey publicKey field MUST contain the DER-encoding of a | |||

ASN.1 type ECPoint (see Section 8.2). | value of the ASN.1 type ECPoint (see Section 8.2), which | |||

represents the sending agent's ephemeral EC public key. | ||||

keyEncryptionAlgorithm contains the | keyEncryptionAlgorithm MUST contain the | |||

dhSinglePass-stdDH-sha1kdf-scheme object identifier (see Section | dhSinglePass-stdDH-sha1kdf-scheme object identifier (see Section | |||

7.1) if standard ECDH primitive is used, or the | 8.1) if standard ECDH primitive is used, or the | |||

dhSinglePass-cofactorDH-sha1kdf-scheme object identifier (see | dhSinglePass-cofactorDH-sha1kdf-scheme object identifier (see | |||

Section 8.1) if the cofactor ECDH primitive is used. The | Section 8.1) if the cofactor ECDH primitive is used. The | |||

parameter field contains KeyWrapAlgorithm. The KeyWrapAlgorithm | parameters field contains KeyWrapAlgorithm. The | |||

is the algorithm identifier that indicates the symmetric | KeyWrapAlgorithm is the algorithm identifier that indicates the | |||

encryption algorithm used to encrypt the CEK with the KEK. | symmetric encryption algorithm used to encrypt the CEK with the | |||

KEK. | ||||

3.1.2 Actions of the sending agent | 3.1.2 Actions of the sending agent | |||

When using ephemeral-static ECDH with EnvelopedData, the sending | When using ephemeral-static ECDH with EnvelopedData, the sending | |||

agent first obtains the recipient's EC public key and domain | agent first obtains the recipient's EC public key and domain | |||

parameters (e.g. from the recipient's certificate). The sending | parameters (e.g. from the recipient's certificate). The sending | |||

agent then determines an integer "keydatalen", which is the | agent then determines an integer "keydatalen", which is the | |||

KeyWrapAlgorithm symmetric key-size in bits, and also a bit string | KeyWrapAlgorithm symmetric key-size in bits, and also a bit string | |||

"SharedData", which is the DER encoding of ECC-CMS-SharedInfo (see | "SharedData", which is the DER encoding of ECC-CMS-SharedInfo (see | |||

Section 8.2). The sending agent then performs the initiator | Section 8.2). The sending agent then performs the initiator | |||

skipping to change at page 6, line 16 | skipping to change at page 6, line 28 | |||

the type ECPoint (see Section 8.2), encapsulated in a bit | the type ECPoint (see Section 8.2), encapsulated in a bit | |||

string and placed in the KeyAgreeRecipientInfo originator | string and placed in the KeyAgreeRecipientInfo originator | |||

field, and | field, and | |||

- a shared secret bit string "KeyData" which is used as the | - a shared secret bit string "KeyData" which is used as the | |||

pairwise key-encryption key for that recipient. | pairwise key-encryption key for that recipient. | |||

3.1.3 Actions of the receiving agent | 3.1.3 Actions of the receiving agent | |||

When using ephemeral-static ECDH with EnvelopedData, the receiving | When using ephemeral-static ECDH with EnvelopedData, the receiving | |||

agent determines the bit string "SharedData" (see Section 8.2) and | agent determines the bit string "SharedData", which is the DER | |||

the integer "keydatalen" from the key-size, in bits, of the | encoding of ECC-CMS-SharedInfo (see Section 8.2), and the integer | |||

KeyWrapAlgorithm. The receiving agent retrieves the ephemeral EC | "keydatalen" from the key-size, in bits, of the KeyWrapAlgorithm. | |||

public key from the bit string KeyAgreeRecipientInfo originator, | The receiving agent retrieves the ephemeral EC public key from the | |||

which an value of the type ECPoint (see Section 8.2) encapsulated | bit string KeyAgreeRecipientInfo originator, which an value of the | |||

as a bit string. The receiving agent completes the responder | type ECPoint (see Section 8.2) encapsulated as a bit string. The | |||

transformation of the 1-Pass Diffie-Hellman scheme [X9.63, Section | receiving agent completes the responder transformation of the | |||

6.2.2]. As a result the receiving agent obtains a shared secret | 1-Pass Diffie-Hellman scheme [X9.63, Section 6.2.2]. As a result | |||

bit string "KeyData" which is used as the pairwise key-encryption | the receiving agent obtains a shared secret bit string "KeyData" | |||

key to unwrap the CEK. | which is used as the pairwise key-encryption key to unwrap the CEK. | |||

3.2 EnvelopedData using 1-Pass ECMQV | 3.2 EnvelopedData using 1-Pass ECMQV | |||

This section describes how to use the 1-Pass elliptic curve MQV | This section describes how to use the 1-Pass elliptic curve MQV | |||

(ECMQV) key agreement algorithm with EnvelopedData. 1-Pass ECMQV | (ECMQV) key agreement algorithm with EnvelopedData. 1-Pass ECMQV | |||

is specified in [X9.63]. Like the KEA algorithm [CMS-KEA], 1-Pass | is specified in [X9.63]. Like the KEA algorithm [CMS-KEA], 1-Pass | |||

ECMQV uses three key pairs: an ephemeral key pair, a static key | ECMQV uses three key pairs: an ephemeral key pair, a static key | |||

pair of the sending agent, and a static key pair of the receiving | pair of the sending agent, and a static key pair of the receiving | |||

agent. An advantage of using 1-Pass ECMQV is that it may be used | agent. An advantage of using 1-Pass ECMQV is that it can be used | |||

with both EnvelopedData and AuthenticatedData. | with both EnvelopedData and AuthenticatedData. | |||

In an implementation that uses 1-Pass ECMQV with CMS EnvelopedData | ||||

with key agreement, the following techniques and formats MUST be | ||||

used. | ||||

3.2.1 Fields of KeyAgreeRecipientInfo | 3.2.1 Fields of KeyAgreeRecipientInfo | |||

When using 1-Pass ECMQV with EnvelopedData the fields of | When using 1-Pass ECMQV with EnvelopedData the fields of | |||

KeyAgreeRecipientInfo are: | KeyAgreeRecipientInfo are: | |||

version is 3 | ||||

originator identifies the static EC public key of the sender. | originator identifies the static EC public key of the sender. | |||

It should be the one of the alternatives issuerAndSerialNumber | It SHOULD be the one of the alternatives issuerAndSerialNumber | |||

or subjectKeyIdentifier and point to one of the sending agent's | or subjectKeyIdentifier and point to one of the sending agent's | |||

certificates supplied in the EnvelopedData originatorInfo field. | certificates. | |||

ukm is present. The ukm field contains an octet string which is | ukm MUST be present. The ukm field MUST contain an octet string | |||

the DER encoding of the type MQVuserKeyingMaterial (see Section | which is the DER encoding of the type MQVuserKeyingMaterial (see | |||

8.2). The MQVuserKeyingMaterial ephemeralPublicKey algorithm | Section 8.2). The MQVuserKeyingMaterial ephemeralPublicKey | |||

field contains the id-ecPublicKey object identifier (see Section | algorithm field MUST contain the id-ecPublicKey object | |||

8.1) with NULL parameters field. The MQVuserKeyingMaterial | identifier (see Section 8.1) with NULL parameters field. The | |||

ephemeralPublicKey publicKey field contains the DER-encoding of | MQVuserKeyingMaterial ephemeralPublicKey publicKey field MUST | |||

the ASN.1 type ECPoint representing sending agent's ephemeral EC | contain the DER-encoding of the ASN.1 type ECPoint (see Section | |||

public key. The MQVuserKeyingMaterial addedukm field, if | 8.2) representing sending agent's ephemeral EC public key. The | |||

present, contains an octet string of additional user keying | MQVuserKeyingMaterial addedukm field, if present, SHOULD contain | |||

material of the sending agent. | an octet string of additional user keying material of the | |||

sending agent. | ||||

keyEncryptionAlgorithm is the mqvSinglePass-sha1kdf-scheme | keyEncryptionAlgorithm MUST be the mqvSinglePass-sha1kdf-scheme | |||

algorithm identifier (see Section 8.1), with parameter field | algorithm identifier (see Section 8.1), with parameters field | |||

KeyWrapAlgorithm. The KeyWrapAlgorithm indicates the symmetric | KeyWrapAlgorithm. The KeyWrapAlgorithm indicates the symmetric | |||

encryption algorithm used to encrypt the CEK with the KEK | encryption algorithm used to encrypt the CEK with the KEK | |||

generated using the 1-Pass ECMQV algorithm. | generated using the 1-Pass ECMQV algorithm. | |||

3.2.2 Actions of the sending agent | 3.2.2 Actions of the sending agent | |||

When using 1-Pass ECMQV with EnvelopedData, the sending agent first | When using 1-Pass ECMQV with EnvelopedData, the sending agent first | |||

obtains the recipient's EC public key and domain parameters, | obtains the recipient's EC public key and domain parameters, | |||

(e.g. from the recipient's certificate) and checks that the domain | (e.g. from the recipient's certificate) and checks that the domain | |||

parameters are the same. The sending agent then determines an | parameters are the same. The sending agent then determines an | |||

skipping to change at page 7, line 42 | skipping to change at page 7, line 53 | |||

ECMQV scheme specified in [X9.63, Section 6.9.1]. As a result the | ECMQV scheme specified in [X9.63, Section 6.9.1]. As a result the | |||

sending agent obtains | sending agent obtains | |||

- an ephemeral public key, which is represented as a value of | - an ephemeral public key, which is represented as a value of | |||

type ECPoint (see Section 8.2), encapsulated in a bit string, | type ECPoint (see Section 8.2), encapsulated in a bit string, | |||

placed in an MQVuserKeyingMaterial ephemeralPublicKey | placed in an MQVuserKeyingMaterial ephemeralPublicKey | |||

publicKey field (see Section 8.2), and | publicKey field (see Section 8.2), and | |||

- a shared secret bit string "KeyData" which is used as the | - a shared secret bit string "KeyData" which is used as the | |||

pairwise key-encryption key for that recipient. Parity bits | pairwise key-encryption key for that recipient. Parity bits | |||

are adjust according to the key wrap algorithm. | are adjusted according to the key wrap algorithm. | |||

The ephemeral public key may be re-used with an AuthenticatedData | The ephemeral public key can be re-used with an AuthenticatedData | |||

for greater efficiency. | for greater efficiency. | |||

3.2.3 Actions of the receiving agent | 3.2.3 Actions of the receiving agent | |||

When using 1-Pass ECMQV with EnvelopedData, the receiving agent | When using 1-Pass ECMQV with EnvelopedData, the receiving agent | |||

determines the bit string "SharedData" (see Section 8.2) and the | determines the bit string "SharedData", which is the DER encoding | |||

of ECC-CMS-SharedInfo (see Section 8.2), and the | ||||

integer "keydatalen" from the key-size, in bits, of the | integer "keydatalen" from the key-size, in bits, of the | |||

KeyWrapAlgorithm. The receiving agent then retrieves the static | KeyWrapAlgorithm. The receiving agent then retrieves the static | |||

and ephemeral EC public keys of the originator, from the originator | and ephemeral EC public keys of the originator, from the originator | |||

and ukm fields as described in Section 3.2.1, and its static EC | and ukm fields as described in Section 3.2.1, and its static EC | |||

public key identified in the rid field and checks that the domain | public key identified in the rid field and checks that the domain | |||

parameters are the same. The receiving agent then performs the | parameters are the same. The receiving agent then performs the | |||

responder transformation of the 1-Pass ECMQV scheme [X9.63, Section | responder transformation of the 1-Pass ECMQV scheme [X9.63, Section | |||

6.9.2]. As a result the receiving agent obtains a shared secret | 6.9.2]. As a result the receiving agent obtains a shared secret | |||

bit string "KeyData" which is used as the pairwise key-encryption | bit string "KeyData" which is used as the pairwise key-encryption | |||

key to unwrap the CEK. | key to unwrap the CEK. | |||

4 AuthenticatedData using ECC | 4 AuthenticatedData using ECC | |||

This section describes how to use ECC algorithms with the CMS | This section describes how to use ECC algorithms with the CMS | |||

AuthenticatedData format. AuthenticatedData lacks non-repudiation, | AuthenticatedData format. AuthenticatedData lacks non-repudiation, | |||

and so in some instances is preferrable SignedData. (For example, | and so in some instances is preferable to SignedData. (For | |||

the sending agent may not want the message to be authenticated when | example, the sending agent might not want the message to be | |||

forwarded.) | authenticated when forwarded.) | |||

4.1 AuthenticatedData using 1-pass ECMQV | 4.1 AuthenticatedData using 1-pass ECMQV | |||

This section describes how to use the 1-Pass elliptic curve MQV | This section describes how to use the 1-Pass elliptic curve MQV | |||

(ECMQV) key agreement algorithm with AuthenticatedData. 1-Pass | (ECMQV) key agreement algorithm with AuthenticatedData. 1-Pass | |||

ECMQV is specified in [X9.63]. An advantage of using 1-Pass ECMQV | ECMQV is specified in [X9.63]. An advantage of using 1-Pass ECMQV | |||

is that it may be used with both EnvelopedData and | is that it can be used with both EnvelopedData and | |||

AuthenticatedData. | AuthenticatedData. | |||

4.1.1 Fields of the KeyAgreeRecipientInfo | 4.1.1 Fields of the KeyAgreeRecipientInfo | |||

The AuthenticatedData KeyAgreeRecipientInfo fields are used in the | The AuthenticatedData KeyAgreeRecipientInfo fields are used in the | |||

same manner as the fields for the corresponding EnvelopedData | same manner as the fields for the corresponding EnvelopedData | |||

KeyAgreeRecipientInfo fields of Section 3.2.1 of this document. | KeyAgreeRecipientInfo fields of Section 3.2.1 of this document. | |||

4.1.2 Actions of the sending agent | 4.1.2 Actions of the sending agent | |||

The sending agent uses the same actions as for EnvelopedData | The sending agent uses the same actions as for EnvelopedData | |||

with 1-Pass ECMQV, as specified in Section 3.2.2 of this document. | with 1-Pass ECMQV, as specified in Section 3.2.2 of this document. | |||

The ephemeral public key may be re-used with an EnvelopedData for | The ephemeral public key can be re-used with an EnvelopedData for | |||

greater efficiency. | greater efficiency. | |||

Note: if there are multiple recipients then an attack is possible | Note: if there are multiple recipients then an attack is possible | |||

where one recipient modifies the content without other recipients | where one recipient modifies the content without other recipients | |||

noticing [BON]. A sending agent who is concerned with such an | noticing [BON]. A sending agent who is concerned with such an | |||

attack should use a separate AuthenticatedData for each recipient. | attack SHOULD use a separate AuthenticatedData for each recipient. | |||

4.1.3 Actions of the receiving agent | 4.1.3 Actions of the receiving agent | |||

The receiving agent uses the same actions as for EnvelopedData | The receiving agent uses the same actions as for EnvelopedData | |||

with 1-Pass ECMQV, as specified in Section 3.2.3 of this document. | with 1-Pass ECMQV, as specified in Section 3.2.3 of this document. | |||

Note: see Note in Section 4.1.2. | Note: see Note in Section 4.1.2. | |||

5 Recommended Algorithms and Elliptic Curves | 5 Recommended Algorithms and Elliptic Curves | |||

Implementations of this specification SHOULD implement SignedData | Implementations of this specification MUST implement either | |||

with ECDSA and EnvelopedData with ECDH. Implementations MAY | SignedData with ECDSA or EnvelopedData with ephemeral-static ECDH. | |||

implement the other techniques specified. | Implementations of this specification SHOULD implement both | |||

SignedData with ECDSA and EnvelopedData with ephemeral-static ECDH. | ||||

Implementations MAY implement the other techniques specified, such | ||||

as AuthenticatedData and 1-Pass ECMQV. | ||||

Furthermore, in order to encourage interoperability, | Furthermore, in order to encourage interoperability, | |||

implementations SHOULD use the elliptic curve domain parameters | implementations SHOULD use the elliptic curve domain parameters | |||

recommended by ANSI [X9.62, X9.63], NIST [FIPS186-2] and SECG [SEC3]. | specified by ANSI [X9.62, X9.63], NIST [FIPS-186-2] and SECG | |||

[SEC2]. | ||||

6 Certificates using ECC | 6 Certificates using ECC | |||

Internet X.509 certificates [PKI] may be used in conjunction with | Internet X.509 certificates [PKI] can be used in conjunction with | |||

this specification to distribute agents' public keys. The use of | this specification to distribute agents' public keys. The use of | |||

ECC algorithms and keys within X.509 certificates is specified in | ECC algorithms and keys within X.509 certificates is specified in | |||

[PKI-ALG]. More details can be found in [SEC3]. | [PKI-ALG]. More details can be found in [SEC3]. | |||

7 SMIMECapabilities Attribute and ECC | 7 SMIMECapabilities Attribute and ECC | |||

A sending agent may choose to announce to receiving agents that it | A sending agent MAY announce to receiving agents that it supports | |||

supports one or more of the ECC algorithms in this document by | one or more of the ECC algorithms in this document by using the | |||

using the SMIMECapabilities signed attribute [MSG, Section 2.5.2]. | SMIMECapabilities signed attribute [MSG, Section 2.5.2]. | |||

The SMIMECapability value to indicate support for the ECDSA | The SMIMECapability value to indicate support for the ECDSA | |||

signature algorithm is the SEQUENCE with the capabilityID field | signature algorithm is the SEQUENCE with the capabilityID field | |||

containing the object identifier ecdsa-with-SHA1 with NULL | containing the object identifier ecdsa-with-SHA1 with NULL | |||

parameters. | parameters. The DER encoding is: | |||

30 0b 06 07 2a 86 48 ce 3d 04 01 05 00 | ||||

The SMIMECapability capabilityID object identifiers for the | The SMIMECapability capabilityID object identifiers for the | |||

supported key agreement algorithms in this document are | supported key agreement algorithms in this document are | |||

dhSinglePass-stdDH-sha1kdf-scheme, | dhSinglePass-stdDH-sha1kdf-scheme, | |||

dhSinglePass-cofactorDH-sha1kdf-scheme, and | dhSinglePass-cofactorDH-sha1kdf-scheme, and | |||

mqvSinglePass-sha1kdf-scheme. For each of these SMIMECapability | mqvSinglePass-sha1kdf-scheme. For each of these SMIMECapability | |||

SEQUENCEs the parameters field is present and indicates the | SEQUENCEs the parameters field is present and indicates the | |||

supported key-encryption algorithm with the KeyWrapAlgorithm | supported key-encryption algorithm with the KeyWrapAlgorithm | |||

algorithm identifier. | algorithm identifier. The DER encodings that indicate capability | |||

of the three key agreement algorithms with CMS Triple-DES key wrap | ||||

are: | ||||

30 1c 06 09 2b 81 05 10 86 48 3f 00 02 30 0f 06 | ||||

0b 2a 86 48 86 f7 0d 01 09 10 03 06 05 00 | ||||

for ephemeral-static ECDH, | ||||

30 1c 06 09 2b 81 05 10 86 48 3f 00 03 30 0f 06 | ||||

0b 2a 86 48 86 f7 0d 01 09 10 03 06 05 00 | ||||

for ephemeral-static ECDH with cofactor method, and | ||||

30 1c 06 09 2b 81 05 10 86 48 3f 00 10 30 0f 06 | ||||

0b 2a 86 48 86 f7 0d 01 09 10 03 06 05 00 | ||||

for ECMQV. | ||||

8 ASN.1 Syntax | 8 ASN.1 Syntax | |||

The ASN.1 syntax that is used in this document is gathered together | The ASN.1 syntax that is used in this document is gathered together | |||

in this section for reference purposes. | in this section for reference purposes. | |||

8.1 Algorithm identifiers | 8.1 Algorithm identifiers | |||

The algorithm identifiers used in this document are taken from | The algorithm identifiers used in this document are taken from | |||

[X9.62] and [X9.63]. | [X9.62] and [X9.63]. | |||

skipping to change at page 11, line 33 | skipping to change at page 12, line 14 | |||

ECDSA-Sig-Value is specified in [X9.62]. Within CMS, | ECDSA-Sig-Value is specified in [X9.62]. Within CMS, | |||

ECDSA-Sig-Value is DER-encoded and placed within a signature field | ECDSA-Sig-Value is DER-encoded and placed within a signature field | |||

of SignedData. | of SignedData. | |||

When using ECDH and ECMQV with EnvelopedData and AuthenticatedData, | When using ECDH and ECMQV with EnvelopedData and AuthenticatedData, | |||

ephemeral and static public keys are encoded using the type | ephemeral and static public keys are encoded using the type | |||

ECPoint. | ECPoint. | |||

ECPoint ::= OCTET STRING | ECPoint ::= OCTET STRING | |||

When using ECQMV with EnvelopedData and AuthenticatedData, the | When using ECMQV with EnvelopedData and AuthenticatedData, the | |||

sending agent's ephemeral public key and additional keying material | sending agent's ephemeral public key and additional keying material | |||

are encoded using the type: | are encoded using the type: | |||

MQVuserKeyingMaterial ::= SEQUENCE { | MQVuserKeyingMaterial ::= SEQUENCE { | |||

ephemeralPublicKey OriginatorPublicKey, | ephemeralPublicKey OriginatorPublicKey, | |||

addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL } | addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL } | |||

The ECPoint syntax in used to represent the ephemeral public key | The ECPoint syntax in used to represent the ephemeral public key | |||

and placed in the ephemeralPublicKey field. The additional user | and placed in the ephemeralPublicKey field. The additional user | |||

keying material is place in the addedukm field. Then the | keying material is place in the addedukm field. Then the | |||

skipping to change at page 12, line 18 | skipping to change at page 13, line 4 | |||

entityUInfo optionally contains additional keying material | entityUInfo optionally contains additional keying material | |||

supplied by the sending agent. When used with ECDH and CMS, the | supplied by the sending agent. When used with ECDH and CMS, the | |||

entityUInfo field contains the octet string ukm. When used with | entityUInfo field contains the octet string ukm. When used with | |||

ECMQV and CMS, the entityUInfo contains the octet string | ECMQV and CMS, the entityUInfo contains the octet string | |||

addedukm (encoded in MQVuserKeyingMaterial). | addedukm (encoded in MQVuserKeyingMaterial). | |||

suppPubInfo contains the length of the generated KEK, in bits, | suppPubInfo contains the length of the generated KEK, in bits, | |||

represented as a 32 bit number, as in [CMS-DH]. (E.g. for 3DES | represented as a 32 bit number, as in [CMS-DH]. (E.g. for 3DES | |||

it would be 00 00 00 c0.) | it would be 00 00 00 c0.) | |||

Within CMS, ECC-CMS-SharedInfo is DER-encoded and used as input to | Within CMS, ECC-CMS-SharedInfo is DER-encoded and used as input to | |||

the key derivation function, as specified in [X9.63]. Note that | the key derivation function, as specified in [X9.63, Section | |||

ECC-CMS-SharedInfo differs from the OtherInfo specified in | 5.6.3]. Note that ECC-CMS-SharedInfo differs from the OtherInfo | |||

[CMS-DH]. Here a counter value is not included in the keyInfo | specified in [CMS-DH]. Here a counter value is not included in the | |||

field because the key derivation function specified in [X9.63] | keyInfo field because the key derivation function specified in | |||

ensures that sufficient keying data is provided. | [X9.63, Section 5.6.3] ensures that sufficient keying data is | |||

provided. | ||||

9 Summary | 9 Summary | |||

This document specifies how to use ECC algorithms with the S/MIME | This document specifies how to use ECC algorithms with the S/MIME | |||

CMS. Use of ECC algorithm within CMS can result in reduced | CMS. Use of ECC algorithm within CMS can result in reduced | |||

processing requirements for S/MIME agents, and reduced bandwidth | processing requirements for S/MIME agents, and reduced bandwidth | |||

for CMS messages. | for CMS messages. | |||

References | References | |||

[X9.42] ANSI X9.42-xxxx, "Agreement Of Symmetric Keys Using | [X9.42] ANSI X9.42-2001, "Agreement Of Symmetric Keys Using | |||

Diffie-Hellman and MQV Algorithms", American National | Diffie-Hellman and MQV Algorithms", American National | |||

Standards Institute, 2001, Working draft. | Standards Institute, 2001, Approved draft. | |||

[X9.62] ANSI X9.62-1999, "Public Key Cryptography For The | [X9.62] ANSI X9.62-1998, "Public Key Cryptography For The | |||

Financial Services Industry: The Elliptic Curve | Financial Services Industry: The Elliptic Curve | |||

Digital Signature Algorithm (ECDSA)", Americal | Digital Signature Algorithm (ECDSA)", American | |||

National Standards Institute, 1999. | National Standards Institute, 1999. | |||

[X9.63] ANSI X9.63-xxxx, "Public Key Cryptography For The | [X9.63] ANSI X9.63-xxxx, "Public Key Cryptography For The | |||

Financial Services Industry: Key Agreement and Key | Financial Services Industry: Key Agreement and Key | |||

Transport Using Elliptic Curve Cryptography", American | Transport Using Elliptic Curve Cryptography", American | |||

National Standards Institute, 2000, Working draft. | National Standards Institute, 2000, Working draft. | |||

[PKI-ALG] L. Bassham, R. Housley and W. Polk, "Algorithms and | [PKI-ALG] L. Bassham, R. Housley and W. Polk, "Algorithms and | |||

Identifiers for the Internet X.509 Public Key | Identifiers for the Internet X.509 Public Key | |||

Infrastructure Certificate and CRL profile", PKIX | Infrastructure Certificate and CRL profile", PKIX | |||

skipping to change at page 14, line 9 | skipping to change at page 14, line 38 | |||

[CMS-DH] E. Rescorla, "Diffie-Hellman Key Agreement Method", | [CMS-DH] E. Rescorla, "Diffie-Hellman Key Agreement Method", | |||

RFC 2631, June 1999. | RFC 2631, June 1999. | |||

[SEC1] SECG, "Elliptic Curve Cryptography", Standards for | [SEC1] SECG, "Elliptic Curve Cryptography", Standards for | |||

Efficient Cryptography Group, 2000. | Efficient Cryptography Group, 2000. | |||

[SEC2] SECG, "Recommended Elliptic Curve Domain Parameters", | [SEC2] SECG, "Recommended Elliptic Curve Domain Parameters", | |||

Standards for Efficient Cryptography Group, 2000. | Standards for Efficient Cryptography Group, 2000. | |||

[SEC3] SECG, "ECC in X.509", Standards for Efficient | [SEC3] SECG, "ECC in X.509", Standards for Efficient | |||

Cryptography Group, 2000. | Cryptography Group, Working Draft, 2000. | |||

Security Considerations | Security Considerations | |||

This specification is based on [CMS], [X9.62] and [X9.63] and the | This specification is based on [CMS], [X9.62] and [X9.63] and the | |||

appropriate security considerations of those documents apply. | appropriate security considerations of those documents apply. | |||

In addition, implementors of AuthenticatedData should be aware of | In addition, implementors of AuthenticatedData should be aware of | |||

the concerns expressed in [BON] when using AuthenticatedData to | the concerns expressed in [BON] when using AuthenticatedData to | |||

send messages to more than one recipient. | send messages to more than one recipient. | |||

skipping to change at page 14, line 46 | skipping to change at page 15, line 24 | |||

of licenses to be made available, or the result of an attempt made | of licenses to be made available, or the result of an attempt made | |||

to obtain a general license or permission for the use of such | to obtain a general license or permission for the use of such | |||

proprietary rights by implementors or users of this specification | proprietary rights by implementors or users of this specification | |||

can be obtained from the IETF Secretariat. | can be obtained from the IETF Secretariat. | |||

Acknowledgments | Acknowledgments | |||

The methods described in this document are based on work done by | The methods described in this document are based on work done by | |||

the ANSI X9F1 working group. The authors wish to extend their | the ANSI X9F1 working group. The authors wish to extend their | |||

thanks to ANSI X9F1 for their assistance. The authors also wish to | thanks to ANSI X9F1 for their assistance. The authors also wish to | |||

thank Peter de Rooij for his patient assistance. | thank Peter de Rooij for his patient assistance. The technical | |||

comments of Francois Rousseau were valuable contributions. | ||||

Authors' Address | Authors' Addresses | |||

Simon Blake-Wilson | Simon Blake-Wilson | |||

Certicom Corp | Certicom Corp | |||

5520 Explorer Drive #400 | 5520 Explorer Drive #400 | |||

Mississauga, ON L4W 5L1 | Mississauga, ON L4W 5L1 | |||

e-mail: sblakewi@certicom.com | e-mail: sblakewi@certicom.com | |||

Daniel R. L. Brown | Daniel R. L. Brown | |||

Certicom Corp | Certicom Corp | |||

5520 Explorer Drive #400 | 5520 Explorer Drive #400 | |||

Mississauga, ON L4W 5L1 | Mississauga, ON L4W 5L1 | |||

e-mail: dbrown@certicom.com | e-mail: dbrown@certicom.com | |||

Paul Lambert | Paul Lambert | |||

Director of Security Applications | Director of Security Applications | |||

CoSine Communications | CoSine Communications | |||

End of changes. | ||||

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