[PATCH] Make update_keysig_packet honour cert-digest-algo

[Daniel Kahn Gillmor]

On 05/12/2009 11:45 AM, David Shaw wrote:
> On May 12, 2009, at 11:13 AM, Daniel Kahn Gillmor wrote:
>>  Since
>> self-sigs are made over data entirely under the control of the
>> keyholder, there is no risk that the act of making a self-signature over
>> SHA-1 could be abused by someone exploiting the digest's weakened
>> collision resistance.
> 
> So then why is any of this necessary?

Because while *making* self-sigs doesn't make the keyholder more
vulnerable to a digest compromise, *trusting* self-sigs leaves the
interpreter vulnerable to a digest compromise.  See my followup
yesterday on ietf-openpgp:

  http://www.imc.org/ietf-openpgp/mail-archive/msg33452.html

So anyone checking signatures for validity has a good reason to ignore
signatures (self-sigs or otherwise) made over untrustworthy digests.

Since this is the case, people who want their certifications to be
deemed valid by everyone have an incentive to make those certifications
over digests that are not known to be compromised.

At the moment, you're saying there is a non-zero installed base of
clients that do not support signatures made over SHA-256.

In the future, there may be a non-zero base of clients who prefer to
disbelieve (blacklist) signatures made over SHA-1.

If gpg wants its generated self-signatures to be acceptable to members
of both of these sets, it must issue two signatures (one over each
digest).  You cannot issue two self-sigs like this in gpg right now
without the --expert option, which indicates that it's probably the
wrong way to do things.

If a gpg user wants to ignore either set of clients, the obvious way to
do that is by setting cert-digest-algo.  But that doesn't currently
behave as expected, as J Cruickshanks pointed out.

	--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/0c794443/attachment.pgp>