[PATCH] Make update_keysig_packet honour cert-digest-algo

[Daniel Kahn Gillmor]

On 05/12/2009 01:27 PM, David Shaw wrote:
>  This is not a perfect world where as
> soon as there was a question even asked about an algorithm, we could
> just shove it aside and use something else.  This is a very messy world
> where the vast majority of users don't upgrade, don't use the latest
> algorithms, and don't even understand the problem.

Agreed, and i'm *not* suggesting that we should cast SHA-1 aside right
now.  The fact that the majority of users don't understand the problem
and take a long time to upgrade is an indication that we need tools to
do the Right Thing proactively, well before the "weaponized" attacks are
created.  The tools we release this year will likely still be in use 5
years from now, in a different cryptographic landscape, on behalf of
those same users who don't understand the issues.

I can think of two situations where the set of users who decline to rely
on SHA-1-based signatures will be a significantly larger than the empty set:

 * When an "weaponized" attack against SHA-1's collision-resistance does
come out, or

 * When a large organization decides that SHA-1 is no longer
trustworthy, and mandates that signatures based on it be disregarded
(for example, the US Federal Gov't will do this at the end of 2010).


When either event happens, the current WoT will suffer.  For example,
all the published sigs (self-sigs and those made by others) on
0x99242560 are made with either MD5 or SHA1.  Even if all of your
correspondents were to re-issue their certifications over stronger
digests, your key would not be considered valid by someone choosing to
deprecate SHA-1 because your self-sigs are made over the compromised
algorithm.


So, before either of these two events happen, we need a couple things to
already be comfortably in place:

 A) we'll need tools that are capable of simply deprecating signatures
made over SHA-1 (see the earlier discussion about blacklist-digest-algo)

 B) we'll need a WoT with sufficient post-SHA1 certifications to provide
useful connectivity.

As the widest-used free implementation of OpenPGP, gnupg is in a unique
position to make sure that both of these things happen.

My proposal adds no new UI features to gpg, and is a simple rule:

 * if cert-digest-algo is not SHA-1, gnupg generates all self-signatures
twice, over SHA-1 and cert-digest-algo

If blacklist-digest-algo was currently implemented, we could consider
expanding this rule to:

 * if cert-digest-algo is not SHA-1, and SHA-1 is not blacklisted, gnupg
generates all certifications (self-sigs and otherwise) twice, over SHA-1
and cert-digest-algo.


If we make this change now, then users stuck on, say, debian oldstable 3
years from now (about the time SHA-3 will be finalized, if i'm reading
the timetable correctly, and well after the US Gov't has started
ignoring SHA-1 signatures) have a chance at being able to interact with
the OpenPGP WoT where a significant set of their correspondents have
deprecated SHA-1-based signatures.

Since gpg would make SHA-1 self-sigs as well under this scenario, it
would not cause users today to cut themselves off from current
populations of users with minimal implementations which can only handle
SHA-1.

> There are tools within GPG to accomplish what you want to do today.  It
> may not be as neat as a new feature, but you, nor anyone else who feels
> the need to do this, are not being blocked for lack of this feature.

I've already done it, but it was confusing and more complicated than it
needed to be, even for someone who is heavily invested in understanding
the detailed issues here.

I'm concerned about the majority of users who, as you say, don't even
understand the problem.  gnupg can make things work securely for them,
and help to maintain the global WoT without requiring each user to jump
through the same hoops i did.

> Again, if we were in the position of changing digest hashes more often
> than once a decade, I might feel differently about some spiffy new
> feature to automate it, but this is the first time it's been necessary
> since 1997.

So how do you suggest we prepare for this transition?

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 890 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090512/ab7b1f4e/attachment.pgp>