un-trusting MD5 in gpg

[Daniel Kahn Gillmor]

On 05/06/2009 04:23 PM, David Shaw wrote:
> Maybe we should name it personal-digest-something.  It makes it clear
> that these are personal settings, pertain to digests, and that this is
> sort of a parallel function to personal-digest-preferences.  What are
> the antonyms of preferences?  personal-digest-dislikes? 
> personal-digest-rejections?  personal-digest-disable?

I'm not so sure.  as currently defined, personal-digest-preferences
apply mainly in situations where you are the only person whose
preferences can be taken into account (clearsigning a public document,
for example) -- there are no recipients to consider, and you are
creating the digest yourself.  This seems to be what makes them "personal".

But instead, we're talking about not *accepting* a particular digest
from someone else (or from yourself at an earlier time).  Should this
blacklist we're creating also govern digests that we sign over?  if we
say --personal-digest-blacklist, does that mean both that we will never
*generate* signatures over the given hash and that we will not accept
signatures over the given hash?

> Hashes are a bit easier, but you can imagine some real problems with a
> list of unacceptable ciphers.  Let's say that we had a user who set
> "personal-cipher-donotaccept 3des".  What could this user do when
> encrypting to a bunch of recipients whose ciphers do not intersect on
> anything other than 3des? I guess the best thing to do would be to
> simply error out.

There is always going to be a problem if the sets of user preferences
have no intersection, and this covers digests as well as ciphers.

Consider the case where alice at example.org indicates digest preferences
in her public self-sig that she only accepts signatures over MD5 and
SHA1 hashes, but bob at example.net decides that SHA1 and MD5 are
unacceptably compromised and he'll never issue signatures over them for
fear that his signature will be transferred to another message. bob
simply cannot send signed messages to alice in that case.  And yes, gpg
should probably error out (or recommend refreshing the recipient's keys,
etc) if bob says "sign this message which is going to alice"

4880 mandates that all compliant tools must be *capable* of using SHA1,
but it can't compel all humans using the tools to happily generate
signatures over that (or any other) algorithm.  With flexible cipher
suites and tools which adequately represent their users intent, it seems
likely that there will always exist some intersection of a user with a
pathologically archaic toolset and a user with pathologically
bleeding-edge demands.  The tools need to be able to fail gracefully
when they recognize that such an intersection exists.

	--dkg

-------------- 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/20090506/645578a3/attachment.pgp>