Subject: ECC curve ID

From: Werner Koch <[email-masked]>
Date: Wed, 27 Feb 2008 16:51:50 +0100

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

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.

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.

---

From: Mike Markowitz <[email-masked]>
Date: Wed, 27 Feb 2008 12:54:39 -0600

>     1.2.840.10045.3.1.7  NIST P-256   (Not sure about this OID)

Werner: We think that this is correct -- at least it's what we've been using
for quite some time and have received no complaints to date (and have witnessed
no conflicts between our code and everything we've been able to access for
compatibility testing).

Microsoft agrees (and our P-256 ECC certs are accepted by Vista IE):
   "XCN_OID_ECC_CURVE_P256 (1.2.840.10045.3.1.7) "
http://msdn2.microsoft.com/en-us/library/aa379070(VS.85).aspx

Also, if you need an official NIST reference, SP 800-78-1 lists this OID on
page 9 (table 3-6):
   http://csrc.nist.gov/publications/nistpubs/800-78-1/SP-800-78-1_final2.pdf

In hex, it's "0x2A8648CE3D030107."

Cheers,
Michael

==========
Michael J. Markowitz, Ph.D.        Email: [email-masked]
Vice President R&D                 Voice: 708-445-1704 (Oak Park)
Information Security Corporation          847-405-0500 (Deerfield)
1011 Lake Street, Suite 425        Fax:   708-445-9705
Oak Park, IL  60301                WWW:   http://www.infoseccorp.com

---

From: Andrey Jivsov <[email-masked]>
Date: Wed, 27 Feb 2008 15:31:09 -0800

Hello Werner, thank you for your comments.

Werner Koch wrote:
> 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

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.

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

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

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

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 28 Feb 2008 11:04:35 +0100

> OpenPGP application is not required to understand ASN.1 /

You don't need to support ASN.1 or DER to support OIDs as identities for
curves.  Just use memcpy or memcmp with a fixed string.
>
> Besides, I thought that once the group agrees on an ID, the IETF
> process shouldn't take longer than a quarter.

I think that is quite optimistic.  Further, the problem with the process
is that you don't get the actual ID number until after that process has
finished.  This seriously delay deployment and early testing.  If IANA
could reserve numbers early for experiments, this wouldn't have been
such a big problem.

Finally, I'd like to +1 Werner's suggestion to use OID's.

/Simon