[messaging] Affirmations

[nymble]

Interesting thread .. 
> On Jan 20, 2015, at 8:27 PM, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
> 
> 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.
X.509 has so many problems … 

SDSI/SPKI has not been mentioned here yet.  While not well adopted and having a few warts, it’s notion of the key ‘speaking’ for a namespace is a very powerful concept.  

I’ve been working on repackaging and extending the use of SDSI/SPKI like naming for ‘home’ applications.  In a home environment, you are never able to have a central CA, every mobile device might be an ‘authority’.

Current baseline approach is:
- key identifiers are the principal for policy and authorization statments  ( id = f(cipher suite identifier | public key) )
- Attribute Bassed Access Control Framework (ABAC - all policy enforcement is based on the attributes associated with the principal 
 - attributes have a ‘source’ .. the speaker in the SDSI/SPKI sense
   if Alice and Bob are keys you have assignments of the form
   e.g.  Alice says Bob has ‘foo'
- SDSI/SPKI was too slim on semantics an typing.  Everything needs typing and strict semantic usage
    all attributes are  tag: value   with strict constrains on value based on the tag, so an attribute expression is of the form
        Alice says Bob has group: foo
- XACL, SDSI have unfriendly human readable syntax … a subset of YAML seems more readable.
  You need tags for the ‘speaker’/authority and target (Alice and Bob), but ca and target are a little techie
   In trying to map closely to english it becomes:
—
says: *alice
this: *bob
has:
    group: foo
signed: 64e5f1506840684457cb04a25214fbea

YAML defines ‘*’ as a macro-like replacement, so the *alice refers to a previous shared public key and cipher suite ….

Hidden in the mechanism is that group or any other tag is not global…  the actual attribute name is  *alice|group:foo
Every key then implicitly defines it’s own namespace of attribute … 

Of course you need a canonical serialization …
Delegation is a different type of statement giving trust to another key to ‘speak about’ a range of one or more attributes
SDSI/SPKI provides binary delegation.  With tag:value pairs you can get better granularity of authorization.



Paul


> 
> 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
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging