SHA-1 recommendations

[Robert J. Hansen]

Daniel Kahn Gillmor wrote:
> 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 was not aware of RFC 4055.  Judging from some of the talk on
ietf-openpgp, many people there are not aware of it, either.  In light
of this, the text should definitely be changed; thank you.

> Section 3.2
> 
> Your 30-day timeframe for abandoning all 1024-bit DSA certificates
> seems quite aggressive.

Yes, by design.  I think the likelihood of people completing a process
decreases exponentially with the length of the process.  30 days is the
most aggressive schedule I can think of that could still be considered
reasonable enough to give correspondents an opportunity to raise
objections, questions, etc., and get answers.

If there's a consensus that we should make this a 90-day or 180-day
process, I'll certainly change the text.  That said, I think we should
err on the side of an aggressive schedule.

> 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 am generally not a fan of altering this setting.  This will cripple
interoperability with other OpenPGP applications that do not support
SHA256 in certifications.  Again, though, if the consensus is for
something different, I'll change the text.

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

This goes back to an old argument I've had with David Shaw, over whether
the preference list is really a preference list at all.  I don't see
anything in RFC4880 which requires algorithms earlier in the list to be
preferred over algorithms later in the list.  (13.2 explicitly says it's
an 'ordered list', which seems to imply it should be this way; however,
a couple of paras later it says, 'the implementation may use any
mechanism to pick an algorithm in the intersection [of the sender's and
recipient's preferences]', which seems to strongly imply it's not the
case, and a random selection would still be perfectly conformant.)

If the preference list is really a capability set, then
default-preference-list is fine as-is.  We prefer to use SHA256, we
advertise we can use SHA256, there's no problem.

Even if the preference list is viewed as a preference list,
default-preference-list is irrelevant.  It only advertises to senders
what algorithms we prefer.  There is no requirement senders give us
SHA-1 signed traffic, and senders should be set up to prefer SHA256.

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

You're correct.  There are no significant attacks on RIPEMD-160, while
there are on SHA-1.  This means that at present RIPEMD-160 is believed
somewhat stronger.  Just how much stronger depends on how resistant
RIPEMD-160 will be to the SHA-1 attacks -- and we really can't say that
at present.  My suspicion is it will not turn out to be very resistant.

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

This only seems necessary if we use cert-digest-algo.  If we skip that,
this seems unnecessary.