[messaging] Affirmations

[Daniel Kahn Gillmor]

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