Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation
draft-lochter-pkix-brainpool-ecc-03

[Ballot discuss]
I would like to talk about this on the call.

I am trying to reconcile the facts that we are OK with the publication, the IANA considerations sections says there are no IANA actions, ecStdCurvesAndGeneration uses a value from the ISO tree, and defines a new subtree which presumably could have sub-allocations in it.

At the very least, I'd like to know that

(a) ISO is OK with this allocation (we should avoid stepping on IETF
values *and* other people's values, too.

(b) ISO or someone else has already a rule that tells what to do for
suballocations under ecStdCurvesAndGeneration.

This RFC-to-be was submitted to the RFC Editor to be published as
Informational: draft-lochter-pkix-brainpool-ecc-01.txt.

Please let us know if this document conflicts with the IETF standards
process or other work being done in the IETF community.

Five week timeout expires on 13 August 2008. (Please note that we
have included an additional week because of the upcoming IETF.)

ECC Brainpool Standard Curves and Curve Generation

This Memo proposes several elliptic curve domain parameters over
finite prime fields for use in cryptographic applications. The
domain parameters are consistent with the relevant international
standards, and can be used in X.509 certificates and certificate
revocation lists (CRLs), for Internet Key Exchange (IKE), Transport
Layer Security (TLS), XML signatures, and all applications or
protocols based on the cryptographic message syntax (CMS).


This document was reviewed by Hal Finney, and his suggestion
was incorporated in the -01 version. Finney wrote in review:

"This is a very good idea. Present NIST curves do not have proofs that
all their parameters are random, a fact which caused trouble when it
came time to create the EC RNG in FIPS SP 800-90, as pointed out by
Shumow and Ferguson, who found a possible backdoor. NIST curves also
are optimized for performance, with field primes that have a lot of 1
bits at the top, allowing for very fast modular arithmetic. However
certain techniques along these lines are patented so there is a risk
that NIST may be inadvertently leading implementors into legal trouble.
Using random primes will avoid this problem. Hopefully performance will
still be acceptable.'This is a very good idea. Present NIST curves do
not have proofs that all their parameters are random, a fact which
caused trouble when it came time to create the EC RNG in FIPS SP
800-90, as pointed out by Shumow and Ferguson, who found a possible
backdoor. NIST curves also are optimized for performance, with field
primes that have a lot of 1 bits at the top, allowing for very fast
modular arithmetic. However certain techniques along these lines are
patented so there is a risk that NIST may be inadvertently leading
implementors into legal trouble. Using random primes will avoid this
problem. Hopefully performance will still be acceptable."


Sincerely,

Sandy Ginoza - USC/ISI
Request for Comments Documents