On Jan 31, 2009, at 4:17 PM, Christoph Anton Mitterer wrote:
On Thu, 2009-01-29 at 15:53 -0500, David Shaw wrote:
I suspect it wouldn't hurt, but wouldn't help much either.
Why not? It would solve the problem! Or am I wrong?
For
example, given this:
Signature === January 1
Signature === January 3
Signature === January 5
it is clear that the January 5 signature is the latest and the one to
use. Given this:
Signature === January 1
Revocation === January 2
Signature === January 3
Revocation === January 4
Signature === January 5
It's still clear which signature is the right one.
I suppose if you had an implementation that insisted on using the
first signature, regardless of the date, then the revocations would
force it to look at the last signature..
Yes and this is the point here, isn't it?! ;)
It may conclude
that there is no signature at all (after all, the one signature it
was
looking at is revoked).
Well and I think that's what Peter actually wants. And that's what I'd
suggest, too.
The point I was trying to make is a little different. The RFC
specifies a (RECOMMENDed) way to handle this problem, so that the
extra revocations are not needed for any implementation that is
compliant with that advice. This method with extra revocations is an
attempt to force non-compliant implementations into doing the right
thing. I suspect this may be tilting at windmills. These
implementations are already disregarding the RFC advice. It is
difficult to use RFC advice to get a non-RFC advice following
implementation to do the right thing.
In other words, why should they follow the RFC with regards to these
extra revocations? They're already disregarding the RFC advice with
regards to signature selection. Applications that follow the RFC
advice don't need the extra revocations. Applications that don't
follow the RFC advice anyway can't be expected to follow a new piece
of advice.
I tried to think a little bit about the whole issue with revoking
previous self-sigs. I'm not sure so pleas help me with the following:
One dangerous type of attack in cryptosystems are downgrade attacks.
I build some examples in order to find out whether an attacker could
do
downgrade attacks on self-sigs (e.g. with different hash algorithms
and
other different and security critical subpackets) and if this would be
prevented by _generally_ revoking old self-sigs that were replaced by
new ones.
I think for these kind of attacks, revoking the old self-sigs wouldn't
help anything, would it?
Because an attacker could always strip of newer self-signatures and
revocation signatures as he likes, and thus users and actually the
whole
OpenPGP-PKI really _RELY_ on functional keyservers the distribute the
complete and up-to-date version of the key.
Exactly right.
David