[Top] [All Lists]

Re: OpenPGP keys and Suite-B

2008-06-18 08:38:36

On Mon, 16 Jun 2008 04:49, openpgp(_at_)brainhub(_dot_)org said:

The other pending issue is Curve ID v.s. OID, which would have
required significant re-write of the document, because IDs presently
appear in many packets, profiles, and data that we hash. However, it
looks to me that this issue has "coin toss" / "don't care" status for
most, so I would like to avoid the burden of re-editing.

Well, it depends on how you define "most".  If "most" refers to the WG
members, you might be right.  But we need to look at the user base and
that is not as US centric as these curves.  

In fact, with the current definition this OpenPGP draft for ECC is
useless for Germany (and I assume also for most of Europe).  The
catalogue of allowed algorithms and the technical guideline TR-03111 of
the BSI [1] do not include the NIST curves and explictly recommend the
curves defined by the ECC Brainpool working groop [2].

I already remarked that I do not consider these curves as MUST items.
But a way to optionally use other curves is paramount to allow OpenPGP
with ECC in Europe.  Without that ECC in OpenPGP and thus eventually
OpenPGP will be dead.  If it is a goal to keep OpenPGP alive we need to
have a way to allow the use of other curves.

The most flexible way would be the use of OIDs.  However if you really
don't want this, an alternative would be to define further algorithms
ids - at least for the Brainpool curves (An ID is availabe [3]).  But
wait, what about other countries?  Shouldn't we be nice to them and
allow them the use of their own curves - technically this is possible
and it won't pose an interop problem: If they can't use their curves
they won't use OpenPGP at all and go only with X.509.

Recall what happened with Camellia: It is now a year since David Shaw
implemented that cipher in GnuPG but we are still not able to enable
this because the RFC process has not been finished.  We have not even
agreed within the WG on algorithm identifiers.  Taking a year for such a
simple change - even with consensus in the WG that we want to have
Camellia in OpenPGP - is not really a useful way to get going with a new
cipher or a new curve.  OIDS nicely solve this problem for curves.

We should not drop a better technical better solution just for the
benefit that it is less work.  If you need help, just send me the source
of your ID and I do the editing.  I'd really like to get an ECC draft
out so that we can get ECDSA into GnuPG to start experimenting with it.
(DSA 2048bit is a bit slow and a transient interop problem)



[1] Federal Office for Information Security (

Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.