RFC relevance of algorithm

As per Relevance of the word algorithm, we have this rfc below:

Network Working Group S. Blake-
Request for Comments: 3278 D.
Category: Informational Certicom
P.
Cosine
April 2002

Use of Elliptic Curve Cryptography (ECC)
in Cryptographic Message Syntax (CMS

Status of this

This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited

Copyright

Copyright (C) The Internet Society (2002). All Rights Reserved

This document describes how to use Elliptic Curve Cryptography (ECC
public-key algorithms in the Cryptographic Message Syntax (CMS).
ECC algorithms support the creation of digital signatures and
exchange of keys to encrypt or authenticate content. The
of the algorithm processing is based on the ANSI X9.62 standard
developed by the ANSI X9F1 working group, the IEEE 1363 standard,
the SEC 1 standard

The readers attention is called to the Intellectual Property
section at the end of this document

Blake-Wilson, et al. Informational [Page 1]

RFC 3278 Use of ECC Algorithms in CMS April 2002

Table of

1 Introduction ................................................... 2
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 ....................................... 4
3.1 EnvelopedData using ECDH ................................. 5
3.1.1 Fields of KeyAgreeRecipientInfo ................... 5
3.1.2 Actions of the sending agent ...................... 5
3.1.3 Actions of the receiving agent .................... 6
3.2 EnvelopedData using 1-Pass ECMQV ......................... 6
3.2.1 Fields of KeyAgreeRecipientInfo ................... 6
3.2.2 Actions of the sending agent ...................... 7
3.2.3 Actions of the receiving agent .................... 7
4 AuthenticatedData using ECC ............ ...................... 8
4.1 AuthenticatedData using 1-pass 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 .................... 8
5 Recommended Algorithms and Elliptic Curves .................... 9
6 Certificates using ECC ........................................ 9
7 SMIMECapabilities Attribute and ECC ........................... 9
8 ASN.1 Syntax .................................................. 10
8.1 Algorithm identifiers .................................... 10
8.2 Other syntax ............................................. 11
9 Summary ....................................................... 12
References ....................................................... 13
Security Considerations .......................................... 14
Intellectual Property Rights ..................................... 14
Acknowledgments .................................................. 15
Authors' Addresses ............................................... 15
Full Copyright Statement ......................................... 16

1

The Cryptographic Message Syntax (CMS) is cryptographic
independent. This specification defines a profile for the use
Elliptic Curve Cryptography (ECC) public key algorithms in the CMS
The ECC algorithms are incorporated into the following CMS
types

- 'SignedData' to support ECC-based digital signature
(ECDSA) to sign

Blake-Wilson, et al. Informational [Page 2]

RFC 3278 Use of ECC Algorithms in CMS April 2002

- 'EnvelopedData' to support ECC-based public-key
methods (ECDH and ECMQV) to generate pairwise key-
keys to encrypt content-encryption keys used for

- 'AuthenticatedData' to support ECC-based public-key
methods (ECMQV) to generate pairwise key-encryption keys
encrypt MAC keys used for content authentication and

Certification of EC public keys is also described to provide public
key distribution in support of the specified techniques

1.1 Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in BCP 14, RFC 2119
[MUST].

2 SignedData using

This section describes how to use ECC algorithms with the
SignedData format to sign data

2.1 SignedData using

This section describes how to use the Elliptic Curve
Signature Algorithm (ECDSA) with SignedData. ECDSA is specified
[X9.62]. The method is the elliptic curve analog of the
Signature Algorithm (DSA) [FIPS 186-2].

In an implementation that uses ECDSA with CMS SignedData,
following techniques and formats MUST be used

2.1.1 Fields of the

When using ECDSA with SignedData, the fields of SignerInfo are as
[CMS], but with the following restrictions

digestAlgorithm MUST contain the algorithm identifier sha-1 (
Section 8.1) which identifies the SHA-1 hash algorithm

signatureAlgorithm contains the algorithm identifier ecdsa-with
SHA1 (see Section 8.1) which identifies the ECDSA
algorithm

signature MUST contain the DER encoding (as an octet string) of
value of the ASN.1 type ECDSA-Sig-Value (see Section 8.2).

Blake-Wilson, et al. Informational [Page 3]

RFC 3278 Use of ECC Algorithms in CMS April 2002

When using ECDSA, the SignedData certificates field MAY include
certificate(s) for the EC public key(s) used in the generation of
ECDSA signatures in SignedData. ECC certificates are discussed
Section 6.

2.1.2 Actions of the sending

When using ECDSA with SignedData, the sending agent uses the
digest calculation process and signature generation process
SignedData that are specified in [CMS]. To sign data, the
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" is
determined by converting the message digest generated
to [CMS, Section 5.4] to an integer using the data
method in [X9.62, Section 4.3.2].

The sending agent encodes the resulting signature using the ECDSA
Sig-Value syntax (see Section 8.2) and places it in the
signature field

2.1.3 Actions of the receiving

When using ECDSA with SignedData, the receiving agent uses
message digest calculation process and signature verification
for SignedData that are specified in [CMS]. To verify SignedData
the receiving agent uses the signature verification method
in [X9.62, Section 5.4] with the following exceptions

- In [X9.62, Section 5.4.1] the integer "e'" is
determined by converting the message digest generated
to [CMS, Section 5.4] to an integer using the data
method in [X9.62, Section 4.3.2].

In order to verify the signature, the receiving agent retrieves
integers r and s from the SignerInfo signature field of the
message

3 EnvelopedData using ECC

This section describes how to use ECC algorithms with the
EnvelopedData format

Blake-Wilson, et al. Informational [Page 4]

RFC 3278 Use of ECC Algorithms in CMS April 2002

3.1 EnvelopedData using (ephemeral-static)

This section describes how to use the ephemeral-static Elliptic
Diffie-Hellman (ECDH) key agreement algorithm with EnvelopedData
Ephemeral-static ECDH is specified in [SEC1] and [IEEE1363].
Ephemeral-static ECDH is the the elliptic curve analog of
ephemeral-static Diffie-Hellman key agreement algorithm
jointly in the documents [CMS, Section 12.3.1.1] and [CMS-DH].

In an implementation that uses ECDH with CMS EnvelopedData with
agreement, the following techniques and formats MUST be used

3.1.1 Fields of

When using ephemeral-static ECDH with EnvelopedData, the fields
KeyAgreeRecipientInfo are as in [CMS], but with the
restrictions

originator MUST be the alternative originatorKey.
originatorKey algorithm field MUST contain the id-
object identifier (see Section 8.1) with NULL parameters.
originatorKey publicKey field MUST contain the DER-encoding of
value of the ASN.1 type ECPoint (see Section 8.2),
represents the sending agent's ephemeral EC public key

keyEncryptionAlgorithm MUST contain the dhSinglePass-stdDH
sha1kdf-scheme object identifier (see Section 8.1) if
ECDH primitive is used, or the dhSinglePass-cofactorDH-sha1kdf
scheme object identifier (see Section 8.1) if the cofactor
primitive is used. The parameters field
KeyWrapAlgorithm. The KeyWrapAlgorithm is the
identifier that indicates the symmetric encryption algorithm
to encrypt the content-encryption key (CEK) with the key
encryption key (KEK).

3.1.2 Actions of the sending

When using ephemeral-static ECDH with EnvelopedData, the
agent first obtains the recipient's EC public key and
parameters (e.g. from the recipient's certificate). The
agent then determines an integer "keydatalen", which is
KeyWrapAlgorithm symmetric key-size in bits, and also a bit
"SharedInfo", which is the DER encoding of ECC-CMS-SharedInfo (
Section 8.2). The sending agent then performs the key deployment
the key agreement operation of the Elliptic Curve Diffie-
Scheme specified in [SEC1, Section 6.1]. As a result the
agent obtains

Blake-Wilson, et al. Informational [Page 5]

RFC 3278 Use of ECC Algorithms in CMS April 2002

- an ephemeral public key, which is represented as a value of
type ECPoint (see Section 8.2), encapsulated in a bit
and placed in the KeyAgreeRecipientInfo originator field,

- a shared secret bit string "K", which is used as the
key-encryption key for that recipient, as specified in [CMS].

3.1.3 Actions of the receiving

When using ephemeral-static ECDH with EnvelopedData, the
agent determines the bit string "SharedInfo", which is the
encoding of ECC-CMS-SharedInfo (see Section 8.2), and the
"keydatalen" from the key-size, in bits, of the KeyWrapAlgorithm
The receiving agent retrieves the ephemeral EC public key from
bit string KeyAgreeRecipientInfo originator, with a value of the
ECPoint (see Section 8.2) encapsulated as a bit string.
receiving agent performs the key agreement operation of the
Curve Diffie-Hellman Scheme specified in [SEC1, Section 6.1]. As
result, the receiving agent obtains a shared secret bit string "K",
which is used as the pairwise key-encryption key to unwrap the CEK

3.2 EnvelopedData using 1-Pass

This section describes how to use the 1-Pass elliptic curve
(ECMQV) key agreement algorithm with EnvelopedData. ECMQV
specified in [SEC1] and [IEEE1363]. Like the KEA algorithm [CMS
KEA], 1-Pass ECMQV uses three key pairs: an ephemeral key pair,
static key pair of the sending agent, and a static key pair of
receiving agent. An advantage of using 1-Pass ECMQV is that it
be used with both EnvelopedData and AuthenticatedData

In an implementation that uses 1-Pass ECMQV with CMS
with key agreement, the following techniques and formats MUST
used

3.2.1 Fields of

When using 1-Pass ECMQV with EnvelopedData, the fields
KeyAgreeRecipientInfo are

originator identifies the static EC public key of the sender.
SHOULD be one of the alternatives, issuerAndSerialNumber
subjectKeyIdentifier, and point to one of the sending agent'
certificates

ukm MUST be present. The ukm field MUST contain an octet
which is the DER encoding of the type MQVuserKeyingMaterial (
Section 8.2). The MQVuserKeyingMaterial

Blake-Wilson, et al. Informational [Page 6]

RFC 3278 Use of ECC Algorithms in CMS April 2002

algorithm field MUST contain the id-ecPublicKey object
(see Section 8.1) with NULL parameters field.
MQVuserKeyingMaterial ephemeralPublicKey publicKey field
contain the DER-encoding of the ASN.1 type ECPoint (see
8.2) representing sending agent's ephemeral EC public key.
MQVuserKeyingMaterial addedukm field, if present, SHOULD
an octet string of additional user keying material of the
agent

keyEncryptionAlgorithm MUST be the mqvSinglePass-sha1kdf-
algorithm identifier (see Section 8.1), with the parameters
KeyWrapAlgorithm. The KeyWrapAlgorithm indicates the
encryption algorithm used to encrypt the CEK with the
generated using the 1-Pass ECMQV algorithm

3.2.2 Actions of the sending

When using 1-Pass ECMQV with EnvelopedData, the sending agent
obtains the recipient's EC public key and domain parameters, (e.g
from the recipient's certificate) and checks that the
parameters are the same. The sending agent then determines
integer "keydatalen", which is the KeyWrapAlgorithm symmetric key
size in bits, and also a bit string "SharedInfo", which is the
encoding of ECC-CMS-SharedInfo (see Section 8.2). The sending
then performs the key deployment and key agreement operations of
Elliptic Curve MQV Scheme specified in [SEC1, Section 6.2]. As
result, the sending agent obtains

- an ephemeral public key, which is represented as a value
type ECPoint (see Section 8.2), encapsulated in a bit string
placed in an MQVuserKeyingMaterial ephemeralPublicKey
field (see Section 8.2),

- a shared secret bit string "K", which is used as the
key-encryption key for that recipient, as specified in [CMS].

The ephemeral public key can be re-used with an AuthenticatedData
greater efficiency

3.2.3 Actions of the receiving

When using 1-Pass ECMQV with EnvelopedData, the receiving
determines the bit string "SharedInfo", which is the DER encoding
ECC-CMS-SharedInfo (see Section 8.2), and the integer "keydatalen
from the key-size, in bits, of the KeyWrapAlgorithm. The
agent then retrieves the static and ephemeral EC public keys of
originator, from the originator and ukm fields as described
Section 3.2.1, and its static EC public key identified in the

Blake-Wilson, et al. Informational [Page 7]

RFC 3278 Use of ECC Algorithms in CMS April 2002

field and checks that the domain parameters are the same.
receiving agent then performs the key agreement operation of
Elliptic Curve MQV Scheme [SEC1, Section 6.2]. As a result,
receiving agent obtains a shared secret bit string "K" which is
as the pairwise key-encryption key to unwrap the CEK

4 AuthenticatedData using

This section describes how to use ECC algorithms with the
AuthenticatedData format. AuthenticatedData lacks non-repudiation
and so in some instances is preferable to SignedData. (For example
the sending agent might not want the message to be authenticated
forwarded.)

4.1 AuthenticatedData using 1-pass

This section describes how to use the 1-Pass elliptic curve
(ECMQV) key agreement algorithm with AuthenticatedData. ECMQV
specified in [SEC1]. An advantage of using 1-Pass ECMQV is that
can be used with both EnvelopedData and AuthenticatedData

4.1.1 Fields of the

The AuthenticatedData KeyAgreeRecipientInfo fields are used in
same manner as the fields for the corresponding
KeyAgreeRecipientInfo fields of Section 3.2.1 of this document

4.1.2 Actions of the sending

The sending agent uses the same actions as for EnvelopedData with 1-
Pass ECMQV, as specified in Section 3.2.2 of this document

The ephemeral public key can be re-used with an EnvelopedData
greater efficiency

Note: if there are multiple recipients, an attack is possible
one recipient modifies the content without other recipients
[BON]. A sending agent who is concerned with such an attack
use a separate AuthenticatedData for each recipient

4.1.3 Actions of the receiving

The receiving agent uses the same actions as for EnvelopedData
1-Pass ECMQV, as specified in Section 3.2.3 of this document

Note: see Note in Section 4.1.2.

Blake-Wilson, et al. Informational [Page 8]

RFC 3278 Use of ECC Algorithms in CMS April 2002

5 Recommended Algorithms and Elliptic

Implementations of this specification MUST implement
SignedData with ECDSA or EnvelopedData with ephemeral-static ECDH
Implementations of this specification SHOULD implement
SignedData with ECDSA and EnvelopedData with ephemeral-static ECDH
Implementations MAY implement the other techniques specified, such
AuthenticatedData and 1-Pass ECMQV

Furthermore, in order to encourage interoperability,
SHOULD use the elliptic curve domain parameters specified by
[X9.62], NIST [FIPS-186-2] and SECG [SEC2].

6 Certificates using

Internet X.509 certificates [PKI] can be used in conjunction
this specification to distribute agents' public keys. The use of
algorithms and keys within X.509 certificates is specified in [PKI
ALG].

7 SMIMECapabilities Attribute and

A sending agent MAY announce to receiving agents that it supports
or more of the ECC algorithms in this document by using
SMIMECapabilities signed attribute [MSG, Section 2.5.2].

The SMIMECapability value to indicate support for the ECDSA
algorithm is the SEQUENCE with the capabilityID field containing
object identifier ecdsa-with-SHA1 with NULL parameters. The
encoding is

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

The SMIMECapability capabilityID object identifiers for the
key agreement algorithms in this document are dhSinglePass-stdDH
sha1kdf-scheme, dhSinglePass-cofactorDH-sha1kdf-scheme,
mqvSinglePass-sha1kdf-scheme. For each of these
SEQUENCEs, the parameters field is present and indicates
supported key-encryption algorithm with the
algorithm identifier. The DER encodings that indicate capability
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

Blake-Wilson, et al. Informational [Page 9]

RFC 3278 Use of ECC Algorithms in CMS April 2002

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,

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

The ASN.1 syntax used in this document is gathered in this
for reference purposes

8.1 Algorithm

The algorithm identifiers used in this document are taken
[X9.62], [SEC1] and [SEC2].

The following object identifier indicates the hash algorithm used
this document

sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 26 }

The following object identifier is used in this document to
an elliptic curve public key

id-ecPublicKey OBJECT IDENTIFIER ::= { ansi-x9-62 keyType(2) 1 }

ansi-x9-62 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
10045 }

When the object identifier id-ecPublicKey is used here with
algorithm identifier, the associated parameters contain NULL

The following object identifier indicates the digital
algorithm used in this document

ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { ansi-x9-62 signatures(4)
1 }

Blake-Wilson, et al. Informational [Page 10]

RFC 3278 Use of ECC Algorithms in CMS April 2002

When the object identifier ecdsa-with-SHA1 is used within
algorithm identifier, the associated parameters field contains NULL

The following object identifiers indicate the key
algorithms used in this document

dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 2}

dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 3}

mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 16}

x9-63-scheme OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) tc68(133) country(16) x9(840)
x9-63(63) schemes(0) }

When the object identifiers are used here within an
identifier, the associated parameters field contains the
KeyWrapAlgorithm algorithm identifier

8.2 Other

The following additional syntax is used here

When using ECDSA with SignedData, ECDSA signatures are encoded
the type

ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER
s INTEGER }

ECDSA-Sig-Value is specified in [X9.62]. Within CMS, ECDSA-Sig-
is DER-encoded 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

When using ECMQV with EnvelopedData and AuthenticatedData,
sending agent's ephemeral public key and additional keying
are encoded using the type

Blake-Wilson, et al. Informational [Page 11]

RFC 3278 Use of ECC Algorithms in CMS April 2002

MQVuserKeyingMaterial ::= SEQUENCE {
ephemeralPublicKey OriginatorPublicKey
addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }

The ECPoint syntax in used to represent the ephemeral public key
placed in the ephemeralPublicKey field. The additional user
material is placed in the addedukm field. Then
MQVuserKeyingMaterial value is DER-encoded and placed within a
field of EnvelopedData or AuthenticatedData

When using ECDH or ECMQV with EnvelopedData or AuthenticatedData,
key-encryption keys are derived by using the type

ECC-CMS-SharedInfo ::= SEQUENCE {
keyInfo AlgorithmIdentifier
entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL
suppPubInfo [2] EXPLICIT OCTET STRING }

The fields of ECC-CMS-SharedInfo are as follows

keyInfo contains the object identifier of the key-
algorithm (used to wrap the CEK) and NULL parameters

entityUInfo optionally contains additional keying
supplied by the sending agent. When used with ECDH and CMS,
entityUInfo field contains the octet string ukm. When used
ECMQV and CMS, the entityUInfo contains the octet string
(encoded in MQVuserKeyingMaterial).

suppPubInfo contains the length of the generated KEK, in bits
represented as a 32 bit number, as in [CMS-DH]. (E.g. for 3DES
would be 00 00 00 c0.)

Within CMS, ECC-CMS-SharedInfo is DER-encoded and used as input
the key derivation function, as specified in [SEC1, Section 3.6.1].
Note that ECC-CMS-SharedInfo differs from the OtherInfo specified
[CMS-DH]. Here, a counter value is not included in the keyInfo
because the key derivation function specified in [SEC1,
3.6.1] ensures that sufficient keying data is provided

9

This document specifies how to use ECC algorithms with the S/
CMS. Use of ECC algorithm within CMS can result in
processing requirements for S/MIME agents, and reduced bandwidth
CMS messages

Blake-Wilson, et al. Informational [Page 12]

RFC 3278 Use of ECC Algorithms in CMS April 2002

[X9.62] ANSI X9.62-1998, "Public Key Cryptography For
Financial Services Industry: The Elliptic Curve
Signature Algorithm (ECDSA)", American
Standards Institute, 1999.

[PKI-ALG] Bassham, L., Housley R. and W. Polk, "Algorithms
Identifiers for the Internet X.509 Public
Infrastructure Certificate and CRL Profile", RFC 3279,
April 2002.

[BON] D. Boneh, "The Security of Multicast MAC",
at Selected Areas of Cryptography 2000, Center
Applied Cryptographic Research, University of Waterloo
2000. Paper version available
http://crypto.stanford.edu/~dabo/papers/mmac.

[MUST] Bradner, S., "Key Words for Use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.

[FIPS-180] FIPS 180-1, "Secure Hash Standard", National
of Standards and Technology, April 17, 1995.

[FIPS-186-2] FIPS 186-2, "Digital Signature Standard",
Institute of Standards and Technology, 15 February 2000.

[PKI] Housley, R., Polk, W., Ford, W. and D. Solo, "
X.509 Public Key Infrastructure Certificate
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.

[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 1999.

[IEEE1363] IEEE P1363, "Standard Specifications for Public
Cryptography", Institute of Electrical and
Engineers, 2000.

[K] B. Kaliski, "MQV Vulnerabilty", Posting to ANSI X9F1
IEEE P1363 newsgroups, 1998.

[LMQSV] L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone
"An efficient protocol for authenticated key agreement",
Technical report CORR 98-05, University of Waterloo
1998.

Blake-Wilson, et al. Informational [Page 13]

RFC 3278 Use of ECC Algorithms in CMS April 2002

[CMS-KEA] Pawling, J., "CMS KEA and SKIPJACK Conventions",
2876, July 2000.

[MSG] Ramsdell, B., "S/MIME Version 3 Message Specification",
RFC 2633, June 1999.

[CMS-DH] Rescorla, E., "Diffie-Hellman Key Agreement Method",
2631, June 1999.

[SEC1] SECG, "Elliptic Curve Cryptography", Standards
Efficient Cryptography Group, 2000. Available
www.secg.org/collateral/sec1.pdf

[SEC2] SECG, "Recommended Elliptic Curve Domain Parameters",
Standards for Efficient Cryptography Group, 2000.
Available from www.secg.org/collateral/sec2.pdf

Security

This specification is based on [CMS], [X9.62] and [SEC1] and
appropriate security considerations of those documents apply

In addition, implementors of AuthenticatedData should be aware of
concerns expressed in [BON] when using AuthenticatedData to
messages to more than one recipient. Also, users of MQV should
aware of the vulnerability in [K].

When 256, 384, and 512 bit hash functions succeed SHA-1 in
revisions of [FIPS], [FIPS-186-2], [X9.62] and [SEC1], then they
similarly succeed SHA-1 in a future revision of this document

Intellectual Property

The IETF has been notified of intellectual property rights claimed
regard to the specification contained in this document. For
information, consult the online list of claimed
(http://www.ietf.org/ipr.html).

The IETF takes no position regarding the validity or scope of
intellectual property or other rights that might be claimed
pertain to the implementation or use of the technology described
this document or the extent to which any license under such
might or might not be available; neither does it represent that
has made any effort to identify any such rights. Information on
IETF's procedures with respect to rights in standards-track
standards-related documentation can be found in BCP 11. Copies
claims of rights made available for publication and any assurances
licenses to be made available, or the result of an attempt made

Blake-Wilson, et al. Informational [Page 14]

RFC 3278 Use of ECC Algorithms in CMS April 2002

obtain a general license or permission for the use of
proprietary rights by implementors or users of this specification
be obtained from the IETF Secretariat

The methods described in this document are based on work done by
ANSI X9F1 working group. The authors wish to extend their thanks
ANSI X9F1 for their assistance. The authors also wish to thank
de Rooij for his patient assistance. The technical comments
Francois Rousseau were valuable contributions

Authors'

Simon Blake-
Certicom
5520 Explorer Drive #400
Mississauga, ON L4W 5L

EMail: sblakewi@certicom.

Daniel R. L.
pCerticom
5520 Explorer Drive #400
Mississauga, ON L4W 5L

EMail: dbrown@certicom.

Paul

EMail: plambert@sprintmail.

Blake-Wilson, et al. Informational [Page 15]

RFC 3278 Use of ECC Algorithms in CMS April 2002

Full Copyright

Copyright (C) The Internet Society (2002). All Rights Reserved

This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English

The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE

Funding for the RFC Editor function is currently provided by
Internet Society

Blake-Wilson, et al. Informational [Page 16]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX