Subject: Watches for him, her and you

From: "Federico Lowry" <[email-masked]>
Date: Thu, 26 Jun 2008 21:58:38 -0500

A Tag Heuer watch is a luxury statement on its own. Unfortunately, that luxury comes with a price... Except when you visit Diamond Replicas, the web's most comprehensive collection of brand name replica watches. In Diamond Replicas, any Tag Heuer is available for just over $200.
http://holenihidoz45.blogspot.com/

For those of us who have always dreamed of wearing a Tag Heuer, there is no better time to make our dream come true than this very moment, and no better place to do it, than at Diamond Replicas. Here you will find the most prestigious replica Tag Heuers, at an unbeatable price. Come inside now... your Tag Heuer watch is waiting for you at Diamond Replicas.
http://holenihidoz45.blogspot.com/

From: Werner Koch <[email-masked]>
To: Andrey Jivsov <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: OpenPGP keys and Suite-B, new revision
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Mon, 23 Jun 2008 10:42:48 +0200
Sender: [email-masked]

On Mon, 23 Jun 2008 06:33, [email-masked] said:

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

I have no more concerns about this versions.

Thanks,

  Werner

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

Date: Sun, 22 Jun 2008 21:33:44 -0700
From: Andrey Jivsov <[email-masked]>
To: OpenPGP <[email-masked]>
CC: Werner Koch <[email-masked]>
Subject: Re: OpenPGP keys and Suite-B, new revision
Sender: [email-masked]

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: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: algorithm IDs
Cc: [email-masked], [email-masked]
Date: Sat, 21 Jun 2008 17:54:19 +1200
Sender: [email-masked]

Werner Koch <[email-masked]> writes:
>On Fri, 20 Jun 2008 12:48, [email-masked] said:
>> Actually, my concern has to do with the fact that OIDs are of arbitrary
>> 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.

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: Werner Koch <[email-masked]>
To: Len Sassaman <[email-masked]>
Cc: Andrey Jivsov <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: algorithm IDs
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Fri, 20 Jun 2008 13:36:02 +0200
Sender: [email-masked]

On Fri, 20 Jun 2008 12:48, [email-masked] said:

> Actually, my concern has to do with the fact that OIDs are of arbitrary
> 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.

> I agree that's a problem, but isn't the solution "upgrade the client that
> 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

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

Date: Fri, 20 Jun 2008 03:48:58 -0700 (PDT)
From: Len Sassaman <[email-masked]>
To: Werner Koch <[email-masked]>
Cc: Andrey Jivsov <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: algorithm IDs
Sender: [email-masked]

On Fri, 20 Jun 2008, Werner Koch wrote:

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

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

> > How was PGP 7.5 handling this? Just one specified curve, or?
>
> 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.

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

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

--Len.

Date: Fri, 20 Jun 2008 03:46:33 -0700 (PDT)
From: Len Sassaman <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: Werner Koch <[email-masked]>, Andrey Jivsov <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: algorithm IDs (was: Re: OpenPGP keys and Suite-B)
Sender: [email-masked]

On Thu, 19 Jun 2008, Jon Callas wrote:

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

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.

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

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.

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

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: Werner Koch <[email-masked]>
To: Len Sassaman <[email-masked]>
Cc: Andrey Jivsov <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: algorithm IDs
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Fri, 20 Jun 2008 10:14:45 +0200
Sender: [email-masked]

On Fri, 20 Jun 2008 00:15, [email-masked] said:

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

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

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

From: Werner Koch <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: Len Sassaman <[email-masked]>, Andrey Jivsov <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: algorithm IDs
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Fri, 20 Jun 2008 10:07:58 +0200
Sender: [email-masked]

On Fri, 20 Jun 2008 02:37, [email-masked] said:

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

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

Cc: Werner Koch <[email-masked]>, Andrey Jivsov <[email-masked]>, OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
To: Len Sassaman <[email-masked]>
Subject: Re: algorithm IDs (was: Re: OpenPGP keys and Suite-B)
Date: Thu, 19 Jun 2008 17:37:35 -0700
Sender: [email-masked]

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

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.

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

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

Date: Thu, 19 Jun 2008 15:15:33 -0700 (PDT)
From: Len Sassaman <[email-masked]>
To: Werner Koch <[email-masked]>
Cc: Andrey Jivsov <[email-masked]>, OpenPGP <[email-masked]>
Subject: algorithm IDs (was: Re: OpenPGP keys and Suite-B)
Sender: [email-masked]

On Wed, 18 Jun 2008, Werner Koch wrote:

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

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?

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

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

--Len.

From: Werner Koch <[email-masked]>
To: Andrey Jivsov <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: OpenPGP keys and Suite-B
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Wed, 18 Jun 2008 16:58:21 +0200
Sender: [email-masked]

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.

Date: Sun, 15 Jun 2008 19:49:29 -0700
From: Andrey Jivsov <[email-masked]>
CC: OpenPGP <[email-masked]>
Subject: Re: OpenPGP keys and Suite-B
Sender: [email-masked]

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.

Date: Sat, 14 Jun 2008 06:51:42 -0700 (PDT)
From: Len Sassaman <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Other OpenPGP tasks
Sender: [email-masked]

I was not paying attention for the discussion about the WG shutting down,
and would have brought this up then, but it seems that shouldn't affect us
much anyway.

In addition to the remaining drafts that have been mentioned recently
(including my WHIRLPOOL draft, which is blocking on a good, free citation,
though that should be fixed next week), I see a need for IETF guidance in
two other areas.

1. The trust calculations on key rings, AKA "the web of trust."

This is currently treated as out of scope of OpenPGP's message format and
up to the implementor. While I agree it doesn't belong in 4880, I think
that we would benefit from having a standardized trust metric algorithm.
The one in PGP is pretty sound, in my opinion, but has some arcane nits
that aren't obvious at first. I don't know if GnuPG calculates trust the
same way -- I'm pretty sure there are differences.

Minor differences in trust calculations are unlikely to lead to problems
-- it doesn't affect interoperability, and should only rarely cause
noticeable differences in behavior between implementations for the same
keyrings. Those aren't my concerns, though I'm sure that implementors
would like the ability to do trust calculations the way that the leading
implementations do them. I am, however, concerned about a 4880
implementation that decides to use a really broken trust calculation, such
as one that trusts keys six hops away on the signing chain, for instance.

So, an ID for Trust Calculation in OpenPGP seems like a good thing, both
from a "best practices" standpoint and a documentation of current
behavior.

2. Key servers. Last I visited this topic was about eight years ago;
Rodney Thayer and I had part of an ID written up describing HKP, the NAI
LDAP and LDAPS schemas, etc. I still have it if it useful, though it may
be mostly irrelevant now. But the question remains: as an implementor, if
I want to talk to the key servers, how do I do it? I'm sadly out of touch
with the key server operators community these days, and am not even sure
what the dominant key server software is (aside from the Global Directory,
which is a special case), but I think this issue warrants further work.
We've had quite a long time to come up with a stable key server interface;
let's document it so that it remains that way.

Thoughts?

Best,

Len

Date: Wed, 4 Jun 2008 13:47:16 -0700 (PDT)
From: Len Sassaman <[email-masked]>
To: David Shaw <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Whirlpool
Sender: [email-masked]

On Fri, 11 Apr 2008, David Shaw wrote:

>
> On Fri, Apr 11, 2008 at 07:01:24PM +0100, David Crick wrote:
> >
> > I've seen mention several times on this list (and others)
> > of Whirlpool's apparent pending inclusion into OpenPGP,
> > but have yet to see any actual drafts on here about it.
> >
> > Is anyone willing to admit they are working on one? :)
>
> I think Len was working on one.
>
> Len, you're welcome to the XML from my Camellia draft.  With that XML,
> a Whirlpool draft is pretty much cut and paste.

Hi David,

That would be really helpful. I have it mostly finished, but set it aside
because of some deadlines I had. My next week is already overbooked, but
after that I should have a few hours to finish it up, especially thanks to
your offer of the XML.

(Please send it to [email-masked]).

Thanks again!

--Len.