Trust (was: Re: [xri] Re: The elements formerly known as TargetAuthority and TargetSubject)

[Nat Sakimura <n-sakimura@nri.co.jp>]

Comments inline:

--------------------------------------------------
From: "Scott Cantor" <cantor.2@osu.edu>
Sent: Monday, July 06, 2009 10:57 PM
To: "Sakimura Nat" <n-sakimura@nri.co.jp>
Cc: "'Drummond Reed'" <drummond.reed@cordance.net>; "'Breno de Medeiros'" 
<breno@google.com>; "'XRI TC'" <xri@lists.oasis-open.org>
Subject: RE: [xri] Re: The elements formerly known as TargetAuthority and 
TargetSubject

> Nat Sakimura wrote on 2009-07-06:
>> Right. When I was writing "exact match", I was murmuring
>> "whatever is 'exact match'?". Anyways, none the less,
>> the point is that we probably have a profile and places
>> to reference for this case.
>
> Not so much, in my experience. Most standards always leave trust out of
> scope, and there are reasons for that, but with very few exceptions nobody
> tends to pick up that slack, and we're left with sloppy half-solutions 
> based
> on perceptions of how PKIX works and a bunch of broken PKI libraries that
> don't even correctly implement what they attempt to.
>
>> In case of the "1. Root ID Trust"/"Case B) : Third Party X.509
> Certificate"
>> there probably is no place to reference to, and this is
>> even bigger a problem... That's what I wanted to especially express.
>>
>> Do you have any suggestions?
>
> I would need to understand the motivating use case(s) better to say 
> whether
> the work that I'm involved in has applicability or not.

It is a rather basic use case.

Suppose I host my own XRD on my host: sakimura.org, including my OpenID,
sakimura.org/nat. I am not providing OpenID Authentication Service however.
So, I am delegating to exampleop.com. So, it would look like:

<xrd>
   <Subject>http://sakimura.org/nat#1324</subject>
   <Alias>http://sakimura.org/nat</Alias>
   <link>
       <rel>http://spec.example.net/auth/1.0</re>
       <URI>http://exampleop.com/authn</URI>
       <Subject>http://exampleop.com/</Subject>
   <link>
   <ds:Signature ...>
          ...
   </ds:Signature>
   <ds:KeyInfo>
        <ds:X509Data>
             ...
        </ds:X509Data>
   <ds:KeyInfo>
</xrd>

This XRD has to be able to establish its authenticity through its signature.
Otherwise, linking to another XRD as above may not be authoritative either.

>
> But I would say that any place you can devolve the processing rules to
> public key comparisons, you're better off doing that, or at least 
> codifying
> it as a profile option. That is the only well-defined (and not insanely
> complex) processing model that exists when it comes to anything involving
> certificates.

I agree. I have discussed that back in iiw2008b as well.
We could have put the public key in the <Subject>.
As long as the user secret key is not compromised, this looks good.
The problem is the key rotation. You might want to change the
key-pair for one reason or another. This would imply changing the
cannonical ID (<Subject>), and has adverse effect in terms of
OpenID etc. that you would have to transition the ID on RPs as well.

>
> That can be done pretty easily be restricting the "required to support"
> KeyInfo content to types that can directly provide a public key (i.e.
> KeyValue and X509Certificate).
>
> -- Scott
>
>
>