On 04/26/2014 08:20 AM, MFPA wrote: > On Friday 25 April 2014 at 5:47:46 PM, in > <mid:535a91b2.90...@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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
