[PATCH] Make update_keysig_packet honour cert-digest-algo
dshaw at jabberwocky.com
Tue May 12 17:45:23 CEST 2009
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
>> hash may also be changed, as a secondary item. So if the user
>> 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
>> 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
> 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),
> not instead at least warn that --cert-digest-algo is not being
>> We still live in a world where a good percentage of the installed
>> base cannot understand things like SHA256 (and fewer can understand
>> SHA512 or 384), so I think this violates the principle of least
> I understand what you're saying. However, i also think it violates
> principle of least-surprise to do something that you *know* updates
> self-sig (e.g. setpref) and see gpg not honor the explicitly-specified
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
>> like you'd sign any other UID. GPG will recognize that it needs to
>> a self-signature, and will properly add the various self-sig things
>> preferences and such.
>> gpg --cert-digest-algo the-new-algo -u mykey --edit-key mykey
>> delsig (the old sig)
>> sign (make the new sig)
> For users with several UIDs where each UID has dozens of signatures,
> delsig step at least is a serious pain in the neck. Why should the
> 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
> 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
> point to deprecate SHA-1 sigs).
> Both self-sigs would contain identical subpackets other than the
> 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.
> 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
> SHA-1 could be abused by someone exploiting the digest's weakened
> collision resistance.
So then why is any of this necessary?
More information about the Gnupg-devel