 1/draftietfsmimeecc03.txt 20060205 01:51:44.000000000 +0100
+++ 2/draftietfsmimeecc04.txt 20060205 01:51:44.000000000 +0100
@@ 1,14 +1,14 @@
INTERNETDRAFT Simon BlakeWilson, Certicom Corp
draftietfsmimeecc03.txt Daniel R. L. Brown, Certicom Corp
+draftietfsmimeecc04.txt Daniel R. L. Brown, Certicom Corp
Paul Lambert, Cosine Communications
2 March, 2001 Expires: 2 September, 2001
+12 March, 2001 Expires: 12 September, 2001
Use of ECC Algorithms in CMS
Status of this Memo
This document is an InternetDraft and is in full conformance with
all provisions of Section 10 of RFC2026. InternetDrafts 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 InternetDrafts.
@@ 40,64 +40,64 @@
1 Introduction ........................................ 3
1.1 Requirements terminology ....................... 3
2 SignedData using ECC ................................ 3
2.1 SignedData using ECDSA ......................... 3
2.1.1 Fields of the SignedData ................ 3
2.1.2 Actions of the sending agent ............ 4
2.1.3 Actions of the receiving agent .......... 4
3 EnvelopedData using ECC ............................. 5
3.1 EnvelopedData using ECDH ....................... 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.2 EnvelopedData using 1Pass 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.3 Actions of the receiving agent .......... 8
4 AuthenticatedData using ECC ............ ............ 8
4.1 AuthenticatedData using 1pass ECMQV ........... 8
4.1.1 Fields of KeyAgreeRecipientInfo ......... 8
4.1.2 Actions of the sending agent ............ 8
4.1.3 Actions of the receiving agent .......... 9
5 Recommended Algorithms and Elliptic Curves .......... 9
6 Certificates using ECC .............................. 9
7 SMIMECapabilities Attribute and ECC ................. 9
 8 ASN.1 Syntax ........................................ 9
+ 8 ASN.1 Syntax ........................................ 10
8.1 Algorithm identifiers .......................... 10
8.2 Other syntax ................................... 11
 9 Summary ............................................. 12
 References ............................................. 12
+ 9 Summary ............................................. 13
+ References ............................................. 13
Security Considerations ................................ 14
Intellectual Property Rights ........................... 14
 Acknowledgments ........................................ 14
 Authors' Address ....................................... 14
 Full Copyright Statement ............................... 15
+ Acknowledgments ........................................ 15
+ Authors' Addresses ..................................... 15
+ Full Copyright Statement ............................... 16
1 Introduction
The Cryptographic Message Syntax (CMS) is cryptographic algorithm
independent. This specification defines a standard profile for the
use of Elliptic Curve Cryptography (ECC) public key algorithms in
the CMS. The ECC algorithms are incorporated into the following
CMS content types:
 'SignedData' to support ECCbased digital signature methods
(ECDSA) to sign content
 'EnvelopedData' to support ECCbased publickey agreement
methods (ECDH and ECMQV) to generate pairwise keyencryption
keys to encrypt contentencryption keys used for content
encryption
 'AuthenticatedData' to support ECCbased publickey agreement
methods (ECMQV) to generate pairwise keyencryption 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
publickey distribution in support of the specified techniques.
1.1 Requirements terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119
[MUST].
@@ 107,109 +107,116 @@
This section describes how to use ECC algorithms with the CMS
SignedData format to sign data.
2.1 SignedData using ECDSA
This section describes how to use the Elliptic Curve Digital
Signature Algorithm (ECDSA) with SignedData. ECDSA is specified in
[X9.62]. The method is the elliptic curve analog of the
Digital Signature Algorithm (DSA) [FIPS 1862].
+ In an implementation that uses ECDSA with CMS SignedData, the
+ following techniques and formats MUST be used.
+
2.1.1 Fields of the SignedData
When using ECDSA with SignedData the fields of SignerInfo are as in
[CMS], but with the following restrictions:
 digestAlgorithm contains the algorithm identifier sha1 (see
+ digestAlgorithm MUST contain the algorithm identifier sha1 (see
Section 8.1) which identifies the SHA1 hash algorithm.
signatureAlgorithm contains the algorithm identifier
ecdsawithSHA1 (see Section 8.1) which identifies the ECDSA
signature algorithm.
 signature contains the DER encoding (as an octet string) of a
 value of the ASN.1 type ECDSASigValue (see Section
 7.2).
+ signature MUST contain the DER encoding (as an octet string) of
+ a value of the ASN.1 type ECDSASigValue (see Section 8.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
the ECDSA signatures in SignedData. ECC certificates are discussed
in Section 6.
2.1.2 Actions of the sending agent
When using ECDSA with SignedData, the sending agent uses the
message digest calculation process and signature generation process
for SignedData that are specified in [CMS]. To sign data, the
sending agent uses the signature method specified in [X9.62,
Section 5.3] with the following exceptions:
  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].
+  In [X9.62, Section 5.3.1], the integer "e" is instead
+ determined by converting the message digest generated
+ according to [CMS, Section 5.4] to an integer using the data
+ conversion method in [X9.62, Section 4.3.2].
The sending agent encodes the resulting signature using the
 ECDSAsigvalue syntax and places it in the SignerInfo signature
 field.
+ ECDSASigValue syntax (see Section 8.2) and places it in the
+ SignerInfo signature field.
2.1.3 Actions of the receiving agent
When using ECDSA with SignedData, the receiving agent uses the
message digest calculation process and signature verification
process for SignedData that are specified in [CMS]. To verify
SignedData, the receiving agent uses the signature verification
method 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].
+  In [X9.62, Section 5.4.1] the integer "e'" is instead
+ determined by converting the message digest generated
+ according to [CMS, Section 5.4] to an integer using the data
+ conversion method in [X9.62, Section 4.3.2].
In order to verify the signature, the receiving agent retrieves the
integers r and s from the SignerInfo signature field of the
received message.
3 EnvelopedData using ECC Algorithms
This section describes how to use ECC algorithms with the CMS
EnvelopedData format.
3.1 EnvelopedData using (ephemeralstatic) ECDH
This section describes how to use ephemeralstatic Elliptic Curve
DiffieHellman (ECDH) key agreement algorithm with EnvelopedData.
Ephemeralstatic ECDH is specified in [X9.63]. Ephemeralstatic
 ECDH is the the elliptic curve analog of the ephemeralstatic
+ ECDH is the elliptic curve analog of the ephemeralstatic
DiffieHellman key agreement algorithm specified jointly in the
documents [CMS, Section 12.3.1.1] and [CMSDH].
+ 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
When using ephemeralstatic ECDH with EnvelopedData, the fields of
KeyAgreeRecipientInfo are as in [CMS], but with the following
restrictions:
 originator is the alternative originatorKey. The originatorKey
 algorithm field contains the idecPublicKey object identifier
 (see Section 8.1) with NULL parameters. The originatorKey
 publicKey field contains the DERencoding of a value of the
 ASN.1 type ECPoint (see Section 8.2).
+ originator MUST be the alternative originatorKey. The
+ originatorKey algorithm field MUST contain the idecPublicKey
+ object identifier (see Section 8.1) with NULL parameters. The
+ originatorKey publicKey field MUST contain the DERencoding of a
+ 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
dhSinglePassstdDHsha1kdfscheme object identifier (see Section
 7.1) if standard ECDH primitive is used, or the
+ 8.1) if standard ECDH primitive is used, or the
dhSinglePasscofactorDHsha1kdfscheme object identifier (see
Section 8.1) if the cofactor ECDH primitive is used. The
 parameter field contains KeyWrapAlgorithm. The KeyWrapAlgorithm
 is the algorithm identifier that indicates the symmetric
 encryption algorithm used to encrypt the CEK with the KEK.
+ parameters field contains KeyWrapAlgorithm. The
+ KeyWrapAlgorithm is the algorithm identifier that indicates the
+ symmetric encryption algorithm used to encrypt the CEK with the
+ KEK.
3.1.2 Actions of the sending agent
When using ephemeralstatic ECDH with EnvelopedData, the sending
agent first obtains the recipient's EC public key and domain
parameters (e.g. from the recipient's certificate). The sending
agent then determines an integer "keydatalen", which is the
KeyWrapAlgorithm symmetric keysize in bits, and also a bit string
"SharedData", which is the DER encoding of ECCCMSSharedInfo (see
Section 8.2). The sending agent then performs the initiator
@@ 220,66 +227,69 @@
the type ECPoint (see Section 8.2), encapsulated in a bit
string and placed in the KeyAgreeRecipientInfo originator
field, and
 a shared secret bit string "KeyData" which is used as the
pairwise keyencryption key for that recipient.
3.1.3 Actions of the receiving agent
When using ephemeralstatic ECDH with EnvelopedData, the receiving
 agent determines the bit string "SharedData" (see Section 8.2) and
 the integer "keydatalen" from the keysize, in bits, of the
 KeyWrapAlgorithm. The receiving agent retrieves the ephemeral EC
 public key from the bit string KeyAgreeRecipientInfo originator,
 which an value of the type ECPoint (see Section 8.2) encapsulated
 as a bit string. The receiving agent completes the responder
 transformation of the 1Pass DiffieHellman scheme [X9.63, Section
 6.2.2]. As a result the receiving agent obtains a shared secret
 bit string "KeyData" which is used as the pairwise keyencryption
 key to unwrap the CEK.
+ agent determines the bit string "SharedData", which is the DER
+ encoding of ECCCMSSharedInfo (see Section 8.2), and the integer
+ "keydatalen" from the keysize, in bits, of the KeyWrapAlgorithm.
+ The receiving agent retrieves the ephemeral EC public key from the
+ bit string KeyAgreeRecipientInfo originator, which an value of the
+ type ECPoint (see Section 8.2) encapsulated as a bit string. The
+ receiving agent completes the responder transformation of the
+ 1Pass DiffieHellman scheme [X9.63, Section 6.2.2]. As a result
+ the receiving agent obtains a shared secret bit string "KeyData"
+ which is used as the pairwise keyencryption key to unwrap the CEK.
3.2 EnvelopedData using 1Pass ECMQV
This section describes how to use the 1Pass elliptic curve MQV
(ECMQV) key agreement algorithm with EnvelopedData. 1Pass ECMQV
is specified in [X9.63]. Like the KEA algorithm [CMSKEA], 1Pass
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
 agent. An advantage of using 1Pass ECMQV is that it may be used
+ agent. An advantage of using 1Pass ECMQV is that it can be used
with both EnvelopedData and AuthenticatedData.
+ In an implementation that uses 1Pass ECMQV with CMS EnvelopedData
+ with key agreement, the following techniques and formats MUST be
+ used.
+
3.2.1 Fields of KeyAgreeRecipientInfo
When using 1Pass ECMQV with EnvelopedData the fields of
KeyAgreeRecipientInfo are:
 version is 3

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
 certificates supplied in the EnvelopedData originatorInfo field.
+ certificates.
 ukm is present. The ukm field contains an octet string which is
 the DER encoding of the type MQVuserKeyingMaterial (see Section
 8.2). The MQVuserKeyingMaterial ephemeralPublicKey algorithm
 field contains the idecPublicKey object identifier (see Section
 8.1) with NULL parameters field. The MQVuserKeyingMaterial
 ephemeralPublicKey publicKey field contains the DERencoding of
 the ASN.1 type ECPoint representing sending agent's ephemeral EC
 public key. The MQVuserKeyingMaterial addedukm field, if
 present, contains an octet string of additional user keying
 material of the sending agent.
+ ukm MUST be present. The ukm field MUST contain an octet string
+ which is the DER encoding of the type MQVuserKeyingMaterial (see
+ Section 8.2). The MQVuserKeyingMaterial ephemeralPublicKey
+ algorithm field MUST contain the idecPublicKey object
+ identifier (see Section 8.1) with NULL parameters field. The
+ MQVuserKeyingMaterial ephemeralPublicKey publicKey field MUST
+ contain the DERencoding of the ASN.1 type ECPoint (see Section
+ 8.2) representing sending agent's ephemeral EC public key. The
+ MQVuserKeyingMaterial addedukm field, if present, SHOULD contain
+ an octet string of additional user keying material of the
+ sending agent.
 keyEncryptionAlgorithm is the mqvSinglePasssha1kdfscheme
 algorithm identifier (see Section 8.1), with parameter field
+ keyEncryptionAlgorithm MUST be the mqvSinglePasssha1kdfscheme
+ algorithm identifier (see Section 8.1), with parameters field
KeyWrapAlgorithm. The KeyWrapAlgorithm indicates the symmetric
encryption algorithm used to encrypt the CEK with the KEK
generated using the 1Pass ECMQV algorithm.
3.2.2 Actions of the sending agent
When using 1Pass ECMQV with EnvelopedData, the sending agent first
obtains the recipient's EC public key and domain parameters,
(e.g. from the recipient's certificate) and checks that the domain
parameters are the same. The sending agent then determines an
@@ 290,118 +300,141 @@
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
type ECPoint (see Section 8.2), encapsulated in a bit string,
placed in an MQVuserKeyingMaterial ephemeralPublicKey
publicKey field (see Section 8.2), and
 a shared secret bit string "KeyData" which is used as the
pairwise keyencryption 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 reused with an AuthenticatedData
+ The ephemeral public key can be reused with an AuthenticatedData
for greater efficiency.
3.2.3 Actions of the receiving agent
When using 1Pass 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 ECCCMSSharedInfo (see Section 8.2), and the
integer "keydatalen" from the keysize, in bits, of the
KeyWrapAlgorithm. The receiving agent then retrieves the static
and ephemeral EC public keys of the originator, from the originator
and ukm fields as described in Section 3.2.1, and its static EC
public key identified in the rid field and checks that the domain
parameters are the same. The receiving agent then performs the
responder transformation of the 1Pass ECMQV scheme [X9.63, Section
6.9.2]. As a result the receiving agent obtains a shared secret
bit string "KeyData" which is used as the pairwise keyencryption
key to unwrap the CEK.
4 AuthenticatedData using ECC
This section describes how to use ECC algorithms with the CMS
AuthenticatedData format. AuthenticatedData lacks nonrepudiation,
 and so in some instances is preferrable SignedData. (For example,
 the sending agent may not want the message to be authenticated when
 forwarded.)
+ and so in some instances is preferable to SignedData. (For
+ example, the sending agent might not want the message to be
+ authenticated when forwarded.)
4.1 AuthenticatedData using 1pass ECMQV
This section describes how to use the 1Pass elliptic curve MQV
(ECMQV) key agreement algorithm with AuthenticatedData. 1Pass
ECMQV is specified in [X9.63]. An advantage of using 1Pass ECMQV
 is that it may be used with both EnvelopedData and
+ is that it can be used with both EnvelopedData and
AuthenticatedData.
4.1.1 Fields of the KeyAgreeRecipientInfo
The AuthenticatedData KeyAgreeRecipientInfo fields are used in the
same manner as the fields for the corresponding EnvelopedData
KeyAgreeRecipientInfo fields of Section 3.2.1 of this document.
4.1.2 Actions of the sending agent
The sending agent uses the same actions as for EnvelopedData
with 1Pass ECMQV, as specified in Section 3.2.2 of this document.
 The ephemeral public key may be reused with an EnvelopedData for
+ The ephemeral public key can be reused with an EnvelopedData for
greater efficiency.
Note: if there are multiple recipients then an attack is possible
where one recipient modifies the content without other recipients
noticing [BON]. A sending agent who is concerned with such an
 attack should use a separate AuthenticatedData for each recipient.
+ attack SHOULD use a separate AuthenticatedData for each recipient.
4.1.3 Actions of the receiving agent
The receiving agent uses the same actions as for EnvelopedData
with 1Pass ECMQV, as specified in Section 3.2.3 of this document.
Note: see Note in Section 4.1.2.
5 Recommended Algorithms and Elliptic Curves
 Implementations of this specification SHOULD implement SignedData
 with ECDSA and EnvelopedData with ECDH. Implementations MAY
 implement the other techniques specified.
+ Implementations of this specification MUST implement either
+ SignedData with ECDSA or EnvelopedData with ephemeralstatic ECDH.
+ Implementations of this specification SHOULD implement both
+ SignedData with ECDSA and EnvelopedData with ephemeralstatic ECDH.
+ Implementations MAY implement the other techniques specified, such
+ as AuthenticatedData and 1Pass ECMQV.
Furthermore, in order to encourage interoperability,
implementations SHOULD use the elliptic curve domain parameters
 recommended by ANSI [X9.62, X9.63], NIST [FIPS1862] and SECG [SEC3].
+ specified by ANSI [X9.62, X9.63], NIST [FIPS1862] and SECG
+ [SEC2].
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
ECC algorithms and keys within X.509 certificates is specified in
[PKIALG]. More details can be found in [SEC3].
7 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 the SMIMECapabilities signed attribute [MSG, Section 2.5.2].
+ A sending agent MAY announce to receiving agents that it supports
+ one or more of the ECC algorithms in this document by using the
+ SMIMECapabilities signed attribute [MSG, Section 2.5.2].
The SMIMECapability value to indicate support for the ECDSA
signature algorithm is the SEQUENCE with the capabilityID field
containing the object identifier ecdsawithSHA1 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
supported key agreement algorithms in this document are
dhSinglePassstdDHsha1kdfscheme,
dhSinglePasscofactorDHsha1kdfscheme, and
mqvSinglePasssha1kdfscheme. For each of these SMIMECapability
SEQUENCEs the parameters field is present and indicates the
supported keyencryption algorithm with the KeyWrapAlgorithm
 algorithm identifier.
+ algorithm identifier. The DER encodings that indicate capability
+ of the three key agreement algorithms with CMS TripleDES 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 ephemeralstatic 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 ephemeralstatic 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
The ASN.1 syntax that is used in this document is gathered together
in this section for reference purposes.
8.1 Algorithm identifiers
The algorithm identifiers used in this document are taken from
[X9.62] and [X9.63].
@@ 470,21 +502,21 @@
ECDSASigValue is specified in [X9.62]. Within CMS,
ECDSASigValue is DERencoded and placed within a signature field
of SignedData.
When using ECDH and ECMQV with EnvelopedData and AuthenticatedData,
ephemeral and static public keys are encoded using the type
ECPoint.
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
are encoded using the type:
MQVuserKeyingMaterial ::= SEQUENCE {
ephemeralPublicKey OriginatorPublicKey,
addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }
The ECPoint syntax in used to represent the ephemeral public key
and placed in the ephemeralPublicKey field. The additional user
keying material is place in the addedukm field. Then the
@@ 505,44 +538,44 @@
entityUInfo optionally contains additional keying material
supplied by the sending agent. When used with ECDH and CMS, the
entityUInfo field contains the octet string ukm. When used with
ECMQV and CMS, the entityUInfo contains the octet string
addedukm (encoded in MQVuserKeyingMaterial).
suppPubInfo contains the length of the generated KEK, in bits,
represented as a 32 bit number, as in [CMSDH]. (E.g. for 3DES
it would be 00 00 00 c0.)

Within CMS, ECCCMSSharedInfo is DERencoded and used as input to
 the key derivation function, as specified in [X9.63]. Note that
 ECCCMSSharedInfo differs from the OtherInfo specified in
 [CMSDH]. Here a counter value is not included in the keyInfo
 field because the key derivation function specified in [X9.63]
 ensures that sufficient keying data is provided.
+ the key derivation function, as specified in [X9.63, Section
+ 5.6.3]. Note that ECCCMSSharedInfo differs from the OtherInfo
+ specified in [CMSDH]. Here a counter value is not included in the
+ keyInfo field because the key derivation function specified in
+ [X9.63, Section 5.6.3] ensures that sufficient keying data is
+ provided.
9 Summary
This document specifies how to use ECC algorithms with the S/MIME
CMS. Use of ECC algorithm within CMS can result in reduced
processing requirements for S/MIME agents, and reduced bandwidth
for CMS messages.
References
 [X9.42] ANSI X9.42xxxx, "Agreement Of Symmetric Keys Using
+ [X9.42] ANSI X9.422001, "Agreement Of Symmetric Keys Using
DiffieHellman and MQV Algorithms", American National
 Standards Institute, 2001, Working draft.
+ Standards Institute, 2001, Approved draft.
 [X9.62] ANSI X9.621999, "Public Key Cryptography For The
+ [X9.62] ANSI X9.621998, "Public Key Cryptography For The
Financial Services Industry: The Elliptic Curve
 Digital Signature Algorithm (ECDSA)", Americal
+ Digital Signature Algorithm (ECDSA)", American
National Standards Institute, 1999.
[X9.63] ANSI X9.63xxxx, "Public Key Cryptography For The
Financial Services Industry: Key Agreement and Key
Transport Using Elliptic Curve Cryptography", American
National Standards Institute, 2000, Working draft.
[PKIALG] L. Bassham, R. Housley and W. Polk, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and CRL profile", PKIX
@@ 589,21 +622,21 @@
[CMSDH] E. Rescorla, "DiffieHellman Key Agreement Method",
RFC 2631, June 1999.
[SEC1] SECG, "Elliptic Curve Cryptography", Standards for
Efficient Cryptography Group, 2000.
[SEC2] SECG, "Recommended Elliptic Curve Domain Parameters",
Standards for Efficient Cryptography Group, 2000.
[SEC3] SECG, "ECC in X.509", Standards for Efficient
 Cryptography Group, 2000.
+ Cryptography Group, Working Draft, 2000.
Security Considerations
This specification is based on [CMS], [X9.62] and [X9.63] and the
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.
@@ 626,30 +659,32 @@
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat.
Acknowledgments
The methods described in this document are based on work done by
the ANSI X9F1 working group. The authors wish to extend their
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 BlakeWilson
Certicom Corp
5520 Explorer Drive #400
Mississauga, ON L4W 5L1
email: sblakewi@certicom.com
+
Daniel R. L. Brown
Certicom Corp
5520 Explorer Drive #400
Mississauga, ON L4W 5L1
email: dbrown@certicom.com
Paul Lambert
Director of Security Applications
CoSine Communications