dshaw at jabberwocky
May 6, 2009, 3:04 PM
Post #13 of 23
(1695 views)
Permalink
|
On May 6, 2009, at 4:46 PM, Daniel Kahn Gillmor wrote:
> 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".
p-d-p is used during all signing operations whether there are
recipients or not. The clearsign case has no recipients, but an
encrypt+sign does. Say Alice was signing a document and encrypting it
to Baker and Charlie. 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.
The digest is chosen in the same way: take the union of Baker and
Charlie's preferences, and then use Alice's personal-digest-
preferences to pick Alice's favorite choice from the union. The only
thing that is special about picking digests is that some results are
impossible and are automatically discarded. Let's say Alice had a
3072-bit DSA key. The answer thus has to be SHA256, SHA384, or
SHA512. If the preferences cannot agree on one of these, then it is
forced.
Either way, though, Baker and Charlie's preferences are consulted first.
> 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?
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.
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.
> 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.
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.
David
_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
|
signature.asc
