Hi Vincent-- (sorry for the delay)
Thanks for raising this idea. I've been working on certification schemes using OpenPGP and X.509 as part of the monkeysphere project, which uses keys to identify ssh hosts and ssh users (and https hosts, though that part of monkeysphere is bitrotting at the moment due to lack of time), so i've thought about this space a bit too. Hopefully my comments below will be useful. On Mon 2015-01-05 14:44:30 +0000, Vincent Breitmoser wrote: > Short version: An affirmation is a user attribute packet in a pgp keyring > which > associates that keyring with a resource on the internet. By "a resource on the internet", i'm assuming you mean "the thing referred to by a URL". For example, i control the "dkg" account on github, so you could argue that i am associated with "https://github.com/dkg"; If you mean something else, it's probably worth being more specific :) If you're talking about a URL, that has the handy feature that it's already a UTF-8-encoded string, which is all a User ID is, actually: https://tools.ietf.org/html/rfc4880#section-5.11 Most current User IDs are e-mail-style addresses, but that's just a convention: you can use any UTF-8 string, including a URL. Avoiding the use of UAT if you don't need it seems like it would be a good thing; plus, the user IDs will display clearly and cleanly and intelligibly to any user without any code modification. That said, it's worth thinking through the different certifications that people might want to see (or to make) under the scheme you're proposing. Let's assume we're talking about a Social Network hosted at https://social.example, where user account foo is referred to as https://social.example/foo. 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? > 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. All that's needed is for someone to think through the various UI puzzles that this presents -- for example: how can you integrate an OpenPGP implementation with a web-based social media platform so that there is automatic end-to-end encryption for the messages? --dkg _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
