Subject: Re: OpenPGP keys and Suite-B

From: Andrey Jivsov <[email-masked]>
Date: Sun, 15 Jun 2008 19:49:29 -0700

Greeting! As we agreed earlier on the list, I significantly trimmed 
references to Suite-B.

Some of us wanted completely remove Suite-B, while others felt that it 
should exist to add valuable endorsement. I think the middle ground is 
to leave informative references to Suite B, which tell how to use the 
specification with each level of security. These references are limited 
to "protocol level" of Suite-B compliance.

I would like to believe that once we settle this thread, the technical 
content of the document will be largely complete.

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.

In summary, Suite B is the only notable change in the following latest 
version:

   http://brainhub.googlepages.com/draft-jivsov-openpgp-ecc-01-pre-00.txt

The same version is available in other formats that support 
cross-references as navigation links here:

    http://brainhub.googlepages.com/pgp

I intend to submit this edition as -01 revision of the IETF draft as 
soon as there are no contentions. I will wait until at least June 25th.

Thank you.

---

From: Werner Koch <[email-masked]>
Date: Wed, 18 Jun 2008 16:58:21 +0200

On Mon, 16 Jun 2008 04:49, [email-masked] 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)

Salam-Shalom,

   Werner

[1] Federal Office for Information Security (www.bsi.bund.de)
[2] http://www.ecc-brainpool.org/ecc-standard.htm
[3]
http://www.ietf.org/internet-drafts/draft-lochter-pkix-brainpool-ecc-01.txt

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

---

From: Len Sassaman <[email-masked]>
Date: Thu, 19 Jun 2008 15:15:33 -0700 (PDT)

> cipher or a new curve.  OIDS nicely solve this problem for curves.

I really don't like OIDs, given the potential for format-based attacks
that they introduce, but we're already using them anyway. I would like to
see them phased out by v5 though.

However, I see a very large problem here with the "it takes a year to get
an algorithm ID" situation. What's holding that up? And while we're at it,
can we get an algorithm ID assigned for WHIRLPOOL?

> (DSA 2048bit is a bit slow and a transient interop problem)

How was PGP 7.5 handling this? Just one specified curve, or?

--Len.

---

From: Jon Callas <[email-masked]>
Date: Thu, 19 Jun 2008 17:37:35 -0700

> see them phased out by v5 though.

On the one hand, an OID is just a bit string. It's no worse than  
UTF-8. Consider the way we do it to be ISO Latin1, and OIDs to be  
Unicode. On the other hand, you're right.

I don't see that an OID actually solves the problem. The problem is  
that the bureaucracy of IANA needs to assign the bit string. It  
doesn't matter if the bit string is an OID or one of our constants.

It's a process issue, not a format issue.

> can we get an algorithm ID assigned for WHIRLPOOL?

Make one up. Ditto for Camellia. Pick the obvious right number, and we  
all agree we'll start using it. Then we tell IANA to assign that number.

I leave the solution to the obvious error condition (what if IANA  
picks a different one) as an exercise for the reader. If you want,  
I'll tell you my workaround.

	Jon

---

From: Werner Koch <[email-masked]>
Date: Fri, 20 Jun 2008 10:14:45 +0200

> see them phased out by v5 though.

You assume arbitrary OIDs. I am talking about changing a one byte value
to a multi byte value.  They both get assigned by IANA for OpenPGP use
and thus it does not make a difference.

> How was PGP 7.5 handling this? Just one specified curve, or?

I don't know about PGP 7.5.

The practical problem with DSA 2048 is that you create a key, ask people
to sign it and the majority of people are not able to sign it because
there software can't handle that.  We do not have a way to specify
preferences for algorithm lengths (that would in theory only be possible
for subkeys).

Shalom-Salam,

   Werner

---

From: Werner Koch <[email-masked]>
Date: Fri, 20 Jun 2008 10:07:58 +0200

> doesn't matter if the bit string is an OID or one of our constants.

It solves the problem that one can start using an OID even if it is not
registered with IANA for OpenPGP use.  If that OID eventually gets
registered, all works as expected and there is no need to start from
scratch with a new OID or AlgoID.  If that OID won't get registered the
existing keys and messages can still be used for testing purposes.

In that sense it is nothing else than our 100--110 range of algorithms
IDs used for testing. However it is more practical.

We can deploy applications and as soon as an OID gets approved for
OpenPGP we can tell users to enable the hidden option xy and everything
works.  If another OID get assigned we need to get out a new version.

Compare that to algorithm IDs: We could do the same of course - but what
are we supposed to do if the assumed ID gets assigned to a another curve
and yet another ID get assigned to our curve.  That is not easy to
handle and hard to document and explain.

Spending a few extra bytes for an OID is justified - they don't create
noicable larger signatures or keys.

> Make one up. Ditto for Camellia. Pick the obvious right number, and we  

We do have one for Camellia - however it has changed over the last year
and it is still only desribed in an ID.  We can assume that IANA will
eventually assign the suggested algorithm IDs but we can't be sure.

Salam-Shalom,

   Werner

---

From: Len Sassaman <[email-masked]>
Date: Fri, 20 Jun 2008 03:46:33 -0700 (PDT)

> Unicode. On the other hand, you're right.

Ick, yeah. On the other hand, UTF-8 stuff is generally considered an
attack vector; it's only recently that we've seen OID-based conditional
jump attacks, etc. Maybe I'm naive, but I expect people to be careful with
UTF-8; I don't necessarily expect them to be so careful with OIDs.

> doesn't matter if the bit string is an OID or one of our constants.

What I thought Werner meant was that we'd use whatever OIDs were assigned
*already* for a given curve; in his response, he mentioned that IANA would
be assigning them for use in OpenPGP. So then I ask "why not use OpenPGP
IDs for these?" If we have to deal with IANA, I don't see how OIDs are
better than anything else.

> all agree we'll start using it. Then we tell IANA to assign that number.

That's easy enough. For WHIRLPOOL, I'm claiming ID 4 (unassigned in 4880,
previously reserved for Double-width SHA). Please let me know if you think
it should be something else.

Best,

Len

---

From: Len Sassaman <[email-masked]>
Date: Fri, 20 Jun 2008 03:48:58 -0700 (PDT)

> and thus it does not make a difference.

Actually, my concern has to do with the fact that OIDs are of arbitrary
length. X.509 got it wrong; we might too.

> I don't know about PGP 7.5.

I've got some 7.5 ECC keys I could look at, though I suspect it was just
one curve. Jon or Hal could answer this better than I, though.

> preferences for algorithm lengths (that would in theory only be possible

I agree that's a problem, but isn't the solution "upgrade the client that
can't handle the larger keys?"

--Len.

---

From: Werner Koch <[email-masked]>
Date: Fri, 20 Jun 2008 13:36:02 +0200

> length. X.509 got it wrong; we might too.

How can you get this wrong?  You compare the length byte and the the
data.  That is trivial.  Some folks might be tempted to use a BER parser
but is overkill and a bad practise.

We have far more complicated encoding schemes in OpenPGP packets than a
length byte and some opaque data bytes as I suggest to use for the OID.

> can't handle the larger keys?"

Sure, it is just a practical problem.  The users need to ge a new
version of the software.  For GNU/Linux that may take half a year and
the willingness to update to something new.

Salam-Shalom,

   Werner

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 21 Jun 2008 17:54:19 +1200

Werner Koch <[email-masked]> writes:
>How can you get this wrong?  You compare the length byte and the the data.
>That is trivial.  Some folks might be tempted to use a BER parser but is
>overkill and a bad practise.

You don't even check the length byte, you just have a table of encoded OIDs
and walk down them doing a memcmp() of the full encoded form.  Also, while
they *can* be of arbitrary length, unless you design a pathologically stupid
one it's going to be in the region 5-15 bytes.

(You can also optimise the check by comparing an integer checksum of the OID
with a stored integer checksum as a quick-reject check, so an OID match
search is just a walk down a list of ints followed by a single memcmp()).

Peter.

---

From: Andrey Jivsov <[email-masked]>
Date: Sun, 22 Jun 2008 21:33:44 -0700

Greetings!

In the interest of moving forward with the specification I changed the 
document to use OIDs for curves. Please take a look at latest
    http://brainhub.googlepages.com/draft-jivsov-openpgp-ecc-01-pre-01.txt

(also available in other formats here: http://brainhub.googlepages.com/pgp)

* I treated OIDs as binary arrays throughout document, as we discussed. 
ASN.1 parser is not required to identify the curve.
* The "curve OID" used to identify a curve is a portion of OID, as 
Werner suggested. We drop two bytes from ASN.1 DER representation of 
OID. The method to create "curve OID" is defined in section 10.
* This edition also includes Suite-B changes that I posted earlier in 
...01-pre-00.txt.

I will wait until at least July 6 before submitting this as a second 
revisions of the draft to IETF.

I will appreciate your comments. Thank you.

---

From: Werner Koch <[email-masked]>
Date: Mon, 23 Jun 2008 10:42:48 +0200

>    http://brainhub.googlepages.com/draft-jivsov-openpgp-ecc-01-pre-01.txt

I have no more concerns about this versions.

Thanks,

  Werner