[Top] [All Lists]

ECC curve ID

2008-02-27 09:26:23


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.  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).

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 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.



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.

Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.

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