Daniel Kahn Gillmor
dkg at fifthhorseman.net
Sun May 17 23:44:49 CEST 2009
On 05/15/2009 11:43 PM, Robert J. Hansen wrote:
> Comments and constructive feedback are welcome.
Thanks for writing this up, Robert. A few thoughts:
As much as i'd love to see X.509 go away for a variety of reasons, i'm
not sure that saying "consider X.509 deprecated" is a realistic
recommendation on today's network. I'm also not sure that X.509 really
cannot handle more stronger digest algorithms. For example RFC 4055
(from June 2005) appears to list SHA-2 algorithms for X.509:
I could well be misinterpreting this, though. Could you provide some
references for the claim? NSS, GnuTLS, and OpenSSL (three free TLS
implementations with embedded X.509 certificate handling) all seemed
comfortable with certificates and requests which use the SHA-2 family in
my (currently unpublished) testing this past week.
Your 30-day timeframe for abandoning all 1024-bit DSA certificates seems
quite aggressive. I proposed 90 days in my earlier document (and did a
90 day transition myself two years ago, which was a very comfortable
timeline). I've seen other reasonable people propose 6 month transitions.
I think the proposed gpg.conf should also have "cert-digest-algo SHA256"
if people want to make sure their certifications (i.e. signatures made
over key+uid pairs) all use a stronger digest. Without that setting,
certificates will continue to be made with SHA-1.
I also think it's worth recommending an updated default-preference-list,
as recent versions of gpg default to SHA1 SHA256 RIPEMD160, which is
then embedded in the generated self-signatures and published.
Unfortunately, I don't see an easy UI step to help people adjust their
proclaimed digest preferences without also resetting their proclaimed
cipher and compression preferences, which makes this step a bit clunky.
Also in this section: it might be good to provide a link to evidence to
support the claim that RIPEMD160 is "somewhat stronger" than SHA1. My
impression was that it simply has not been the target of such heavy
I think it's also worth explicitly recommending that the above
configuration changes be made *before* generating a new key, so that the
specified changes affect the new key itself.
That's all the suggestions i've got for now. Let me know if any of the
above doesn't make sense.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 890 bytes
Desc: OpenPGP digital signature
More information about the Gnupg-devel