Hello Werner, thank you for your comments.
Werner Koch wrote:
Hi,
altough I am aware of the discussion about limiting the number of
algorithms/profiles in a future ECC option, I am not happy with section
10 of the draft:
10. ECC curve ID
The parameter ECC curve ID is an integer that defines the named
curve.
ID Curve description Curve name
0 Reserved
1 NIST Curve P-256 [FIPS 186-2] "NIST P256"
2 NIST Curve P-384 [FIPS 186-2] "NIST P384"
3 NIST Curve P-521 [FIPS 186-2] "NIST P521"
100-110 Private/Experimental curves
255 Reserved for future expansion
Although this uses the same scheme we use all over OpenPGP, we should
make future life easier for all by not using registered IDs but use
other identifiers here. For registering IDs we need to informal agree
on a new identifier, implement that one and then wait a couple of
months/years until it gets really assigned. The private/experimental
IDs are not really useful for this because they can't be used after the
algorithm has been offically registered.
Thus, I propose to use ASN.1 object identifiers for the curves; i.e.:
1.2.840.10045.3.1.7 NIST P-256 (Not sure about this OID)
1.3.132.0.34 NIST P-384
1.3.132.0.35 NIST P-521
and declare some of them as MUST be implemented if ECC is implemented.
Having object identifiers allows us to add other curves.
I think that support for arbitrary curves has some merits. On the other
hand, these benefits must be compared against possibility of ever
getting the ECC support in OpenPGP applications.
OpenPGP application is not required to understand ASN.1 / DER.
Essentially, this proposal means that we are replacing one-byte ID by
multi-byte ID. Would it be good to agree on new curve anyway and how it
fits relative strength, what are legal issues, what are implementation
issues, which MAY/SHOULD keyword it will be carrying, and so on? If we
cannot agree on this on the list, it is unlikely that applications will
be able to interoperate using curves we disagree on. The freedom will be
detrimental to interoperability. (Conversely, the small subset will
allow greater speed optimizations.)
While I think we need to start from "core" version of the standard and
cut options, perhaps in the future we need to allow named curves in
companion proposal or in the next version of the document. For example,
ID 254 might mean that there is an ASN.1 structure referencing the
curve, inserted somewhere into the sequence of currently defined fields.
(If you find it worthwhile, I can be more specific in the draft about
the extension path for future curves.)
Besides, I thought that once the group agrees on an ID, the IETF process
shouldn't take longer than a quarter.
Well, you will
now say, we should limit that to the NIST defined curves. May I now
remind you that there other national standard bodies which require the
use of other curves. In Europe we have a tendency to prefer our own
algorithms and sometimes it is a hard requirement not rely on foreign
crypto standard (cf. the use of RIPE-MD160).
Please note that proposed curves are a part of major international
standards: ANSI X9.62 (multiple updates) and industry standard SECG,
among others. It is a part of any ECC-related IETF standard. They come
with Windows Vista, Linux (openssl), etc. Which ECC standard *excludes*
the curves specified in the proposal? I claim that the proposed subset
of curves is the most widely supported subset of any standard. I suggest
that in the interest of adoption we start from core set and once we
deployed the applications that interoperate, we start adding marginal
improvements.
I know that interoperability will be limited but as long as other curves
are declared optional this is not a major issue. S/MIME users will
suffer from the same problem.
I note that this seems exactly opposite to what Ian wants, so I propose
the idea of core set + extensions as a compromise...
I have not yet looked at the preference system and how to integrate
curve names into it. I doubt that it is really required because we
don't have preference for key length eithers.
This is where freedom will make interoperability problematic. It is hard
to come up with preferences that control the structure of
self-signatures, because preferences themselves are stored in
self-signatures. The only solution to this chicken-and-egg problem is to
establish small core set of curves, the two ones I proposed in the
draft, and focus on supporting these curves first.
Shalom-Salam,
Werner
p.s.
I don't think that the notion of "Top Secret" And "Secret" belongs into
an RFC. I could also ask to add "VS/NfD", which is a secrecy level used
in Germany
This seems reasonable. If any of 3 curves in the proposal satisfy
another standard that the group thinks worth mentioning, such a standard
can be noted in the spec. (These references to non-OpenPGP profiles are
informative, BTW)