UI terminology for calculated validities

[Daniel Kahn Gillmor]

On 04/26/2014 08:20 AM, MFPA wrote:
> On Friday 25 April 2014 at 5:47:46 PM, in
> <mid:535A91B2.90602 at fifthhorseman.net>, Daniel Kahn Gillmor wrote:
> 
>> PS MFPA's original idea of using a notation to link two
>> primary keys is interesting, and i see how it could be
>> useful, but i don't think it belongs in the public
>> keyservers either.
> 
> Interesting. Why not?

Because i think that the keyservers are the most useful and predictable
and minimally leaky when we keep the data on them as simple as possible.

of course, the data is already not simple (OpenPGP is a huge sprawling
mess of a format), but that doesn't mean we should add new forms of
assertion to the data hosted there, especially if that data could be
used to flesh out the social graph in potentially worrisome ways.

>> Perhaps something like that (using
>> full fingerprints, as hauke suggests) could be made by
>> a non-exportable certification directly on the primary
>> key itself (not over User IDs).
> 
> Why non-exportable? If I were making such a declaration about the
> relationship between my multiple keys, I would want to declare it to
> others. This could be useful for key transitions, but also for an
> individual who chooses to use different keys with different email
> addresses (so may not have a "identical-valid-user-id" across
> different keys).

I can see wanting to assert that i personally have control over both
keys, and making that assertion publicly (perhaps from both keys).  but
i don't see the advantage of someone else publishing claims that i am
the same person holding two different keys.  That looks to me like
people using the keyservers to document social relationships that they
are not involved in; i don't think that's a good idea.

> Or do you envisage somebody else with my public keys on their keyring
> would make that non-exportable certification themselves, in order to
> clean up their own WoT calculations? Actually, on thinking about it,
> that option also would be useful.

yes, exactly.

> A certification directly on the primary key itself would make sense,
> because it is a statement about the key itself, not just the key and
> it's current set of UIDs. But having it over the UIDs, so
> requiring a re-certification from my other key to cover any new
> user-ids, maybe adds a certain amount of security. How do you make a
> certification directly on the primary key itself.

i don't see how including the UserIDs in such a certification makes any
sense, let alone adds any extra security.  One way that gpg makes
certifications directly on the primary key itself is when you revoke a
key.  I don't know if there are other mechanisms in gpg to expose that
sort of thing.

>> But this should only be done if there is an algorithm in
>> place to make use of this information.
> 
> Isn't that kind of a "chicken and egg" statement? Would it not be an
> idea to discuss a standardised notation, so that if anybody chooses to
> put the information out there, it could be interpreted by an algorithm
> that might get written in the future.

I tend to see it the other way; i'd want to know specifically how the
proposed information is supposed to be useful *first*, and then (if it's
a compelling enough case) we can talk about how to specify it.

--ask-cert-level fails this test, for example.  We don't actually make
use of that data in any certificate validation algorithm, so publishing
it just produces a richer social graph than we need to publish, and
doesn't benefit anyone other than folks who want to data mine the social
graph on the keyservers.  That's a net loss in my opinion.

I make this argument in more detail about --ask-cert-level here:

https://www.debian-administration.org/users/dkg/weblog/98

>> Anyone implementing this kind of
>> cleanup should probably start simpler and just handle
>> the identical-valid-user-id case first.
> 
> Maybe "identical" should be expanded to cover such things as different
> capitalisation, etc.

ugh, unicode canonicalization :P  You're probably right, but: ugh!

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1010 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140501/ef5235c9/attachment-0001.sig>