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

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

Hi Scot.

Re: ds:KeyInfo in <Link>. (Linking of XRDs)
==========================================

I host my own domain and XRD. It is a static file, so it is easy to.
For Authentication Service I want to delegate.

Let XRD1 be my own XRD and XRD2 be that of the AuthN Service.

There are two modes of authority establishment of this delegation.

First is the case where authoritative delegation of the
service is done through PKI.

[XRD1]
<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>
       <ds:KeyInfo>
            <ds:X509Data>
             ... X509 public certs of exampleop.com
            </ds:X509Data>
        <ds:KeyInfo>
   </link>
   <ds:Signature ...>
       <ds:SignedInfo>
           ....
       </ds:SignedInfo>
       <ds:SignatureValue>
            ....
       </ds:SignatureValue>
       <ds:KeyInfo>
            <ds:X509Data>
             ... X509 certs of me. ...
            </ds:X509Data>
       </ds:KeyInfo>
   </ds:Signature>
</xrd>

This is specifying that its authentication service is
http://exampleop.com/authn.

You get the XRD from exampleop.com such as:

[XRD2]

<xrd>
   <Subject>http://sakimura.org/nat#1324</subject>
   <Alias>http://sakimura.org/nat</Alias>
   <link>
       <rel>http://specs.openid.net/auth/2.0</re>
       <URI>http://exampleop.com/authn</URI>
   </link>
   <ds:Signature ...>
       <ds:SignedInfo>
           ....
       </ds:SignedInfo>
       <ds:SignatureValue>
            ....
       </ds:SignatureValue>
       <ds:KeyInfo>
            <ds:X509Data>
             ... X509 certs of exampleop.com. ...
            </ds:X509Data>
       </ds:KeyInfo>
   </ds:Signature>
</xrd>

Public Key of XRD1/Link/ds:KeyInfo must match public key of XRD2/ds:KeyInfo
for this delegation to be authoritative. XRD1/Link/ds:KeyInfo is announcing 
that
I have intended to delegate authentication service to XRD2 with this public 
key.

Alternatively, we could use XRD1/Link/Subject and check the
match with XRD2/Subject. This probably is simpler and yet
serves the same purpose...

Another type of linking is the XRI Resolution.

For "=nat", "=" is the community root authority, and "nat" is the
second level authority. By doing resolution on "=", you get a
signed XRD, which is signed by a priori known Certs. Let us call it
XRD-A.

XRD-A specifies the authority for "nat" and and the endpoint.
One can get another XRD, XRD-B from this endpoint. XRD-B is
also signed but by another cert, which was specified in the XRD-A.

It is more or less the same as in the OpenID case.

Re: Signing of XRD itself
=========================
Scott Cantor wrote:
> Right, but that XRD signature itself is more of a classic problem. I'm not
> saying there's some easy answer there, and I don't really think this spec
> needs to say much about it one way or the other.

I think we should. Otherwise, we do not get to the linking.

>
> I'd also note that there's no connection between the Signature (any any
> KeyInfo that might be inside it) and the KeyInfo in the XRD. If they 
> "match"
> in some sense, you have a self-signed document of course. If not, you can 
> I
> suppose say that the signer is claiming that the KeyInfo in the XRD 
> "belongs
> to" the Subject. At least I assume that's the intended semantic.

Are you suggesting that there is another "stand alone" ds:KeyInfo element
outside of the ds:Signature block?

=nat

--------------------------------------------------
From: "Scott Cantor" <cantor.2@osu.edu>
Sent: Wednesday, July 15, 2009 12:35 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] Trust (was: Re: [xri] Re: The elements formerly known as 
TargetAuthority and TargetSubject)

> Nat Sakimura wrote on 2009-07-14:
>> 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:
>
> That part I get. What I don't understand is the intended meaning of the
> KeyInfo within the XRD, or what else, if anything, is needed within the
> <Link> block to accomplish whatever is needed to make OpenID work.
>
>> 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.
>
> Right, but that XRD signature itself is more of a classic problem. I'm not
> saying there's some easy answer there, and I don't really think this spec
> needs to say much about it one way or the other.
>
> I'd also note that there's no connection between the Signature (any any
> KeyInfo that might be inside it) and the KeyInfo in the XRD. If they 
> "match"
> in some sense, you have a self-signed document of course. If not, you can 
> I
> suppose say that the signer is claiming that the KeyInfo in the XRD 
> "belongs
> to" the Subject. At least I assume that's the intended semantic.
>
> But there's this intended notion of linking XRDs and somehow tying that to
> trust evaluation, and that's where I was focusing my comments.
>
>> 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.
>
> This is where I would have to understand the use case better, but in
> general, if you're trying to use the XRD to represent the key(s) 
> controlled
> by the Subject, you can make it multi-valued to handle key rotation.
>
> -- Scott
>
>
>