[PATCH] Make update_keysig_packet honour cert-digest-algo

[J Cruickshanks]

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.
> 
> 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
> - people should not be able to easily render their keys unusable by some
> percentage of the population without doing that on purpose.  (It's
> actually a bit more complex than this if people are using the keyserver
> net to distribute their keys, but the basic point is the same).
> 
> 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

The method you have described appears to work successfully. It does
however have the side effect of wiping away any preferences you already
have set, therefore they need to be set again. I would also assume that
expiry dates and primary UIDs would also have to be set again.

I agree that the user must be fully aware of what they are doing when
making a change like this as it is pretty aggressive. Perhaps an
alternative to the above method could be the addition of a new option
called something along the lines of '--force-cert-digest-algo'. This
would be used in addition to '--cert-digest-algo' for updating self
signatures when changing preferences, expiry dates, etc. along with
changing the digest algorithm for the first time the user wishes to use
a new digest algorithm. We can then be reasonably sure the user intended
for the digest function to be changed. This option would then of course
be accompanied by a warning much like for the '--cert-digest-algo'
option in the man page.

As I mentioned above, this option would probably only be used once or
twice depending on the future of cryptography, so we could stick with
the method you have provided for updating the digest. The only worry I
have with that approach is the potential for the user to forget to
reapply their preferences, expiry dates, etc. or getting caught out by
other side effects that I didn't witness in my quick test. I guess it
depends on how much usage this option will get as to whether to warrant
its inclusion, but it would make the process much easier for users who
do wish to change digest algorithms.

If you believe that this approach would be better, I will be quite
willing to write a patch for the option.

Regards
J Cruickshanks