On 21/01/15 04:27, Daniel Kahn Gillmor wrote: > Here are some possible certifications that > might be interesting: > > A) The owner of OpenPGP key K wants to assert (to other OpenPGP users) > that https://social.example/foo "belongs" to them. > > B) The user associated with the https://social.example/foo user account > wants to assert that OpenPGP K belongs to them. > > These are actually different claims, because they "come from" different > perspectives. > > For claim (A), i think adding a new user ID of > "https://social.example/foo"; should do it. For claim (B), isn't that > best done directly on the social networking site itself, since it is a > place that can be used for publication?
I believe these assertions are actually the other way around, and there's a little more to it than that. - By adding a new user ID of "https://social.example/foo";, you do two things: - *Claim* that this social networking account belongs to you. - *Prove* that OpenPGP key K belongs to the owner of the social media account (modulo private key being compromised), subject to that account having made the claim. So prove (B). - By posting the pubkey (or equiv) on the social network, you: - *Claim* that the OpenPGP key K belongs to you. - *Prove* that the social networking account belongs to the owner of the PGP key (modulo twitter compromise, client connection compromise, or account compromise), subject to the OpenPGP key K having made that claim. And the beauty of this is that it is strictly more useful than what user IDs are currently used for today, and if the workflow of verifying the proofs can be built in to new clients, then awesome! It may be the case that a user ID is all we need from the PGP side. >> So my proposal is a new user attribute subtype, which ties a resource on the >> web >> to the keyring by mutual proof of control. It can be self-certified, >> certified >> by others, revoked, and most importantly distributed via keyservers just >> like a >> regular user id. I am still in the process of doing background research and >> theoretical evaluation of the concept. I plan to write the standard as an >> internet draft, extending rfc4880, but I'm still in the process of working >> out a >> number of details. Some things will probably become more clear during the >> prototype implementation process, and I'm hoping to get some input here as >> well. I will be implementing both a standalone application and support in >> OpenKeychain as part of my thesis. > > I really think that a user attribute is overkill -- a User ID should be > sufficient, and existing implementations won't need to be modified to > support it directly or to expose it to the user. No but they would need to be modified anyway to take full advantage of the mutual proof of control. -Sam
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
