[Top] [All Lists]

Re: ECC curve ID

2008-02-27 16:49:30

Hello Werner, thank you for your comments.

Werner Koch wrote:

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

       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) NIST P-384 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.



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)

<Prev in Thread] Current Thread [Next in Thread>