ietf-openpgp
[Top] [All Lists]

Re: Series of minor questions about OpenPGP 4

2009-02-01 13:32:31
On Sun, 2009-02-01 at 00:41 +0100, Peter Thomas wrote:
Thus you cannot resign a subkey to un-revoke it.
Uhm what do you mean with this?
He probably meant re-sign ;-)


In fact, there was a proposal for
perfect forward security in OpenPGP a few years ago that involved
generating new subkeys very frequently (even to the point of a new subkey 
per message)
Wouldn't this actually create new security problems? I'm by no means a
crypto-expert, but AFAIK the more one uses a key to sign/encrypt data,
the more it is likely that someone can use all this data for
statistical attacks.
And this would be especially bad for the primary key, as far as I understand?
Personally I'm using my primary key just for signing other keys...


I must apologize myself,.. but I don't understand this.
The RFC must somehow specify which of the earlier self-signatures is
revoked by it, or not? Or does it always revoke the MOST RECENT found
signature BEFORE its own timestamp? If so where is this specified (I'm
just curious, not that I wouldn't believe you ;-) )?
And if that's the case we must remember that an implementation is
allowed to use any self-signature, it's just RECOMMENDED to use the
most recent.
Well I'm actually a little bit surprised about how revocation actually
works. This was not clear to me before, and without signature targets I
consider it somewhat wishy-washy.


This will work in GPG, but I don't think it is necessary -
Sorry when I'm nasty, but just think of the example directly above
this text? Or the other examples I gave (with the older self-signature
using MD5 and the new SHAsomething, or other differing subpackets).
Of course probably any reasonable implementation will follow the
recommendation and just use the most recent self-sig like gnupg does
(sig+sig+revoc), but others might not.

What's the opinion on the others on this?
Well my opinion is - don't forget that I'm by no means an expert - that
this issue is not very dangerous at least in practice.
But on the other hand, I agree that _without_ signature targets there is
a chance for problems, especially when applications have their own
mechanism how to resolve ambiguities with multiple-self-sigs.

Even if an implementation follows the RFC RECOMMENDATION it could be
stupid:
Public Key
time 1: 0x1F on that key
time 2: 0x1F on that key
time 3: 0x30 on that key/0x1F's

In that order,.. the application might perhaps work (even then it could
be very stupid ^^) but consider the following order that an attacker
might give you:
Public Key
time 2: 0x1F on that key
time 1: 0x1F on that key
time 3: 0x30 on that key/0x1F's

Isn't this what Daniel had in mind?


But again, the practical impact is probably little as most
implementations behave reasonable (I assume gpg always orders all
signatures by time, before it looks at them?).
And that's probably why David sees not much of a problem here :-)
However I'd be curious what the other experts are thinking ;-)

So when will we see Signature Targets support in PGP and gnupg?! XD
Any voluntary to code? *G*



-- 
Christoph Anton Mitterer
Ludwig-Maximilians-Universität München

christoph(_dot_)anton(_dot_)mitterer(_at_)physik(_dot_)uni-muenchen(_dot_)de
mail(_at_)christoph(_dot_)anton(_dot_)mitterer(_dot_)name

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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