[PATCH] Make update_keysig_packet honour cert-digest-algo

[Daniel Kahn Gillmor]

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).

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

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.

The result of this would be that all compliant OpenPGP clients would get
the same information, and clients who prefer stronger digests can get
the additional assurance provided by the --cert-digest-algo.  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.

Thoughts?

	--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/2464a293/attachment.pgp>