un-trusting MD5 in gpg

[Daniel Kahn Gillmor]

On 05/06/2009 06:04 PM, David Shaw wrote:
> The cipher is chosen by taking the union of Baker and
> Charlie's cipher preferences and then using Alice's
> personal-cipher-preferences to pick Alice's favorite choice from the
> union.

Is it really the union and not the intersection?  It seems that choosing
from the union could leave either Baker or Charlie with an unacceptable
choice.

> Blacklist is pretty good.  We could call it "blacklist-digests" (which
> gives us a name for "blacklist-ciphers" later).  It's reasonably clear
> just from the name.

works for me.

> In terms of whether blacklist-digests only rejects incoming signatures
> or both rejects incoming signatures and refuses to generate a signature
> as well, I could make a reasonable argument for either side, but I think
> I lean more towards doing both - rejecting incoming and not generating
> outgoing.  It would be a strange sort of thing if user disliked an
> algorithm so much that he refused to accept it from somewhere else, but
> yet still generated it himself.

i lean the same way myself, toward having it cover both directions.

> Up until today, we have relied on the must-implement algorithms to get
> us out of a conflict like this.  This will be a new, and surprising,
> behavior for GPG.  It will need to be off by default.

"off by default" just means the "must-implement algorithms" are not
included in the blacklist by default, right?  or do you envision some
additional switch needed in order to say "yes, i really want to put the
must-implement algorithm in the blacklist"?

	--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/e7ffeabd/attachment.pgp>