un-trusting MD5 in gpg

[Daniel Kahn Gillmor]

On 05/06/2009 09:38 AM, Werner Koch wrote:
> This mixes trust with an algorithm, something we never did.  With the
> same reasoning we could say: Don't trust a key with less than 1536 bits.
> The point here is that we can't take a decision for the signer - he
> might have valid reasons to use certain parameters which reflects the
> needs to fulfill a ertain goal.

I agree that we can't force a decision on the signer, and we can't force
a decision on the person interpreting the signature either.  This option
would be mechanism to let signature-interpreters set policy like "i need
to be assured that the validation i'm seeing has a certain level of
tamper-resistance".

This is why i framed it as "trust", because validating a signature does
indeed imply that you trust the algorithms behind that signature.  If i
send you a message with a signature made over the simple 160-bit
checksum of the message (i know this isn't possible in OpenPGP -- it's a
hypothetical), you shouldn't trust that signature because you don't
trust the algorithm -- it's too easy to generate arbitrary content that
will match that signature.

And yes, we might also limit trust in keys by key length.  Do you really
trust a signature made by a 512-bit RSA key?

> An option --disable-digest-algo better reflects what you want to do: I
> don't want to check signatures made using algorithm MD5.  It is not a
> matter of trust but a decision by you and only you.

It's both, actually.  it's a decision by me and only me that i do not
trust signatures using certain algorithmic parameters.  I can even
specify this preference in a digest algorithms subpacket and broadcast
it to the world.

> We need to see whether we can use this option name without getting into
> problems with gpg2.  I don't know right now.  Another name might be
> something along the words --ignore-signatures-with.

I think --ignore-signatures-with makes more sense than
--disable-digest-algo simply because i can imagine wanting to add SHA1
to this list in a year and a half (for any work with US federal agencies
at least), but gnupg wouldn't even be able to calculate standard
fingerprints if SHA1 is completely ripped out.

> I can imagin adding a few new error codes; we already have:
> 
> 43	GPG_ERR_WEAK_KEY		Weak encryption key
> 
> and new ones like:
> 
>         GPG_ERR_WEAK_DIGEST_ALGO
>         GPG_ERR_WEAK_CIPHER_ALGO
> 
> may be useful for further processing; not necessary to be dispalyed to a
> user but may be displayed as well in cases you describe.

This seems reasonable to me.

	--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/702d794f/attachment-0001.pgp>