laying groundwork for an eventual migration away from SHA1 with gpg

Daniel Kahn Gillmor dkg at
Thu May 7 22:57:23 CEST 2009

Hi David, thanks for your feedback.  Some comments below:

On 05/07/2009 02:03 PM, David Shaw wrote:
> I think you did a good job on this.I have one comment, in regards to
> step 5 in your migration plan:
>>> 5. (day 0 through day 90) Review the set of public certifications
>>> you've made ("keys you've signed") with your old key. For keys you
>>> believe to still be active (maybe you want to check with the key
>>> owner), issue a new certification with your new key. If you get a
>>> request for new keysignings, use your new key during this period.
> This one bothers me a bit.  I would definitely not want to re-sign a key
> without - at a minimum - checking with the key owner.  For all I know,
> he's lost the secret key or doesn't use that key any longer.  Presumably
> I did some decent level of checking when I first signed his key, and I
> need to take care if I don't want to violate that original check when/if
> I re-sign.

I agree that checking with the key owner is more of a requirement than a
recommendation before re-issuing the certifications.  i've updated the
blog post to reflect that change.  I welcome public comments on the blog
as well.

> Personally, when I switched to SHA-256 a few years ago, I didn't
> re-issue any signatures.  

Your key does not indicate a switch to SHA256:

0 dkg at pip:~$ gpg --export --export-options export-minimal 99242560 | \
> gpg --list-packets | grep pref-hash-algos

	hashed subpkt 21 len 2 (pref-hash-algos: 3 2)
0 dkg at pip:~$

Should i refresh it from somewhere else?

> If I happen on the same person at a keysigning
> event, I'll re-sign of course, but I didn't seek people out to do it.  I
> think it's prudent to move away from SHA-1 (and did), but actually going
> back and re-making old signatures seems excessive to me.

My goal is to make sure that there *is* a reasonable non-SHA1 WoT in the
near future, which is why i included that step.  If everyone had
switched to SHA256 when you did (i wish i had), we'd have such a WoT by
now, and we could start actively deprecating SHA-1 instead of just
laying groundwork.

My thought was that we could get new  non-SHA1 certifications out there
in the near-term, before there are active attacks(?) that would render
review of our previous SHA-1 signatures dubious.

> Incidentally, there is a minor technical gotcha in the re-signing plans
> in general.  Neither PGP nor GPG will allow you to re-sign a key you've
> already signed.  You can work around this by deleting the old signature
> first, then re-signing.

Ah, good point.  But this is signing with a new key (it's in the context
of a key transition).  That should be OK, right?

> GPG also lets you force a re-signing by signing with "--expert", but
> that's not really appropriate for a published plan like yours (as a
> general thing, if you have to use --expert to get a regular job done,
> something is wrong somewhere).



-------------- 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/20090507/00943468/attachment-0001.pgp>

More information about the Gnupg-devel mailing list