[PATCH] Make update_keysig_packet honour cert-digest-algo

[David Shaw]

On May 12, 2009, at 11:13 AM, Daniel Kahn Gillmor wrote:

> On 05/12/2009 09:42 AM, David Shaw wrote:
>> This patch would mean that when updating these signatures, the  
>> signature
>> hash may also be changed, as a secondary item.  So if the user  
>> changes
>> the primary UID flag, they'll get a new cert hash at the same time.
>> This is fine if someone intended to do that, but less fine if it  
>> happens
>> as an unexpected side-effect of doing something as simple as  
>> setting the
>> primary UID flag.
>
> So what if the update process produced a warning prompt to query if  
> the
> user really wants the digest algorithm to change?
>
> If people don't like the idea of adding an additional warning in some
> cases, (e.g. it might interrupt automated workflow for some users),  
> why
> not instead at least warn that --cert-digest-algo is not being  
> honored?
>
>> We still live in a world where a good percentage of the installed  
>> code
>> base cannot understand things like SHA256 (and fewer can understand
>> SHA512 or 384), so I think this violates the principle of least  
>> surprise
>
> I understand what you're saying.  However, i also think it violates  
> the
> principle of least-surprise to do something that you *know* updates  
> your
> self-sig (e.g. setpref) and see gpg not honor the explicitly-specified
> --cert-digest-algo).

You know that.  I'd be shocked to my core to find out that more than  
5-10% of randomly chosen OpenPGP users have any understanding at all  
that preferences are stored on the self-sig, that a valid self-sig is  
required to have a usable key, and that remaking the self-sig using a  
hash that doesn't exist on the recipient side will cause that  
recipient to not be able to use the key at all.

>> So all that said, if the goal is a new self sig, just sign your own  
>> UID
>> like you'd sign any other UID.  GPG will recognize that it needs to  
>> make
>> a self-signature, and will properly add the various self-sig things  
>> like
>> preferences and such.
>>
>> gpg --cert-digest-algo the-new-algo -u mykey --edit-key mykey
>> delsig (the old sig)
>> sign (make the new sig)
>> save
>
> For users with several UIDs where each UID has dozens of signatures,  
> the
> delsig step at least is a serious pain in the neck.  Why should the  
> user
> need to go through such a rigamarole just to be able to publish a
> stronger self-sig for those clients capable of consuming it?

Because there are vastly more users who don't want to do this.

> Here's an idea that might answer both concerns:
>
> Making a self-signature when cert-digest-algo is set to something  
> other
> than SHA1 could generate *two* self-signatures per UID:
>
> * an SHA-1-based self-sig (timestamped X) for consumption by clients
> who cannot handle other digests, and
>
> * a self-sig using cert-digest-algo (timestamped X+1) for consumption
> by clients who *can* handle the newer digests (and who may wish at  
> some
> point to deprecate SHA-1 sigs).
>
> Both self-sigs would contain identical subpackets other than the  
> digest
> algo and the timestamp.

It's always possible to come up with a complex solution, but then that  
complexity may have other side effects down the road, and will also  
have to be maintained as a feature in GPG for the indefinite future.

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

David