SHA-1 recommendations

[Robert J. Hansen]

Daniel Kahn Gillmor wrote:
> This is a difficult tradeoff.  Certifications themselves seem to be the
> most likely place in the whole OpenPGP architecture where a keyholder
> will be signing material that is provided by a potential adversary.

I don't share in this assessment.  Digital signatures already enjoy the
force of law in many jurisdictions; the hold-up is digital signature
adoption, not legal.

If/as digital signatures become more widespread, the possibility for
document fraud via signature forgery increases.  If you sign Alice's key
at a keysigning party and then she uses that signature on a different
UID/cert, you can dust off Alice's original key and say, "look, there
are two identical sigs, Alice is up to something."  The keyservers don't
forget: they preserve Alice's original key.

Compare this to a script that automatically signs documents -- a trusted
timestamp, for instance.  The script may not retain copies of documents
it's seen or signatures it's made.  That means if someone forges that
timestamp signature, the only way to prove there's a forgery is to find
the original document which was signed.  That's a much dicier proposition.

Predicting future attack vectors is easy; prioritizing them is
incredibly difficult.  I don't know what the most likely avenue of
future attack will be, and am not persuaded that certifications seem to
be the most likely place where a keyholder will be signing material
provided by a potential adversary.  My trusted timestamp example is a
simple one: I'm sure if I were to think for a couple of hours I could
come up with much more subtle and pernicious ones.

That said, I agree with David's assessment that we need to migrate away
from using SHA-1 for cert signatures.  I just don't think that now is
the right time to do it.  I'd like to have some confidence that this
will not create an interoperability nightmare.

>> 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.
> 
> If it's a capability list, it's currently incorrectly set

Not at all.  It can only be incorrectly set if the certificate
advertises capabilities it doesn't possess.  If I tell you, "I can
handle SHA-1," that's a true statement of my capabilities even if I can
handle SHA512, SHA384, SHA256, SHA224, RIPEMD160, MD5 and SHA-1.

I believe it is a capability set, but there is nothing in the spec which
requires it to be a _complete_ capability set.

> If it's an ordered list of preferences, i think it's incorrectly set
> because we should be advertising our preference for stronger digests
> above SHA-1.

As mentioned above, since I think it's a cap set, this is a non-issue.
Other people may think differently, of course.

> It's relevant if either cert-digest-algo or default-preference-list is
> modified: the former affects the digest used to issue the self-sig, and
> the latter affects the embedded pref-hash-algos subpacket in the self-sig.

I'm not phrasing things in terms of logical clauses to be difficult; I'm
doing things this way for clarity.  Hopefully they can shed some light
on my position.



Relevant := Modified(cert-digest-algo) ||
            (Modified(default-preference-list) &&
            IsPrefList(default-preference-list))

Modified(cert-digest-algo) = False
Modified(digest-preference-list) = True
IsPrefList(default-preference-list) = False

Relevant := False || (True && False)
Relevant := False || False
Relevant := False



If you believe the list is a pref list, you will come to a different
evaluation of the relevancy than I do.  Hopefully this clarifies where I
stand on the relevancy issue.