Re: New version: draft-green-secsh-ecc-06

[Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost>]

Douglas Stebila <douglas%stebila.ca@localhost> writes:

>My preference would be the following:
>
>[...]

That sounds sensible.

>1) Should the list of named curves be longer, for example, including all the
>NIST curves or all the SEC curves?

This could be really hard to answer because there isn't enough operational
experience in using these.  I know from TLS that some people seem to be
implementing every curve they can think of, but also that these are a lot of
our-curves-go-to-11 implementations done more to show off the capabilities for
interop purposes rather than everyday use (whoever ships with the most curves
wins).  If you look at the more mainstream implementations they're mostly just
Suite-B and that's it, for example Vista (via MSIE/IIS/whatever) just does
P256, 384, and 521 and that's it.  This is why your suggestion to have the two
Suite-B's (and I'd add 521 to that) as the mandatory-to-support standard is a
good one, you can pretty much assume that everyone will do that anyway.

>2) Should the named curves be named by their NIST name or their SEC name?
>(nistp256 versus secp256r1)

I'd go for NIST for the Suite-B's and SECG for the rest, because they've named
a lot more than NIST has.  This also means that you could define Suite-B's as
mandatory, refer to the SECG names (via "as defined in 'SEC 2:2000' or any
later version") for the remaiming names without explicitly having to catalogue
them all, and then leave the hash as anything-that's-left.

Having said that though I'm still a bit nervous about using the OIDs, there
are all sorts of other odd things you can do with those that could cause
problems, for example there's the "use this with a hash algorithm that's the
largest possible that can be used with the curve without truncation" OID and
the "dance along the wharf slapping people with a dead fish" OID and ... .
Since you can have multiple OIDs for a curve and anything that defines an OID
will also define a curve name, it'd be much easier to just use the name
directly since you're not getting much from the OID except complexity.  If you
really want to be safe, use 'name@source', e.g. curve1@standardsgroupname,
although even then it seems that groups are being careful to choose unique
names.  For example all the SECG names being 'sec' to distinguish them from
other names.

BTW the TLS ECC RFC has a table at the end mapping X9.62 <-> NIST <-> SECG
names for people who need this.

Peter.