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

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

Hi Scott,

--------------------------------------------------
From: "Scott Cantor" <cantor.2@osu.edu>
Sent: Thursday, July 16, 2009 2:48 AM
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-15:
>> 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.
>
> I think it's saying you want to delegate to a XRD2 which is *signed* by 
> that
> key. That's different than saying it means that the key *belongs* to the
> subject of XRD2.

You are right.

>
> But with respect to the question of key management, that use of KeyInfo
> suggests it should be 0-many inside the Link element so you can anticipate
> key changes by the signer of XRD2.

That's reasonable.

>
>> Alternatively, we could use XRD1/Link/Subject and check the
>> match with XRD2/Subject. This probably is simpler and yet
>> serves the same purpose...
>
> It's simpler for everybody but the person who has to come up with a way to
> verify the signature on XRD2. ;-)

This is the point in the second topic below.

>
> But broadly, this is the two set of cases you worked up with Drummond, I
> guess. I think the conclusion I would have is that the linking KeyInfo
> should be multiply occurring, and that the spec could define public key
> matching as one example profile of how to do the matching without 
> precluding
> others.

It looks good.
Any comment from others?

>
> Where I get worried is when people try to create sort of "mini" versions 
> of
> PKIX that try and leverage X.509 matching without realizing all the things
> that would have to be nailed down to make that work, let alone find code
> that would work the way people think it should.

This is the topic that belongs to "Re: Signing of XRD itself" below, I 
think.

>
> In other words, key matching isn't perfect, but it works and there are 
> some
> tweaks that can make some of the key management issues somewhat more
> tractable, while not being a perfect answer.

Right. We are not looking for a scientific truth, but for an engineering 
that works.

>
>> 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 don't think we're going to define a set of trust anchors, are we? It 
> comes
> out of where you want to root the management of the trust decisions and
> whether various approaches to that are viable against the "publishing" 
> model
> for the XRDs themselves.
>
> Truly distributing signing authority essentially requires a PKI of some
> kind. That's one of the reasons I'm not a big fan of discovery based on
> endpoints signing their own information. It's basically making trust
> somebody else's problem. Instead, I would prefer to rely on "XRD (or SAML
> metadata) signing services" that essentially work like CAs but can be
> implemented more flexibly and don't rely on DN naming and other vestiges
> that simply haven't been deployed.

I have not fully grasped this. Could you elaborate a little more please?

>
> There's nothing invalid about the notion of a CA, only the way they've
> behaved and the use of a lot of very brittle technology to implement it.
>
>> Are you suggesting that there is another "stand alone" ds:KeyInfo element
>> outside of the ds:Signature block?
>
> I could have sworn I saw that in at least one of these drafts, but no, 
> there
> isn't one at the moment (other than via extension). I recalled some
> discussion about using the XRD to express the keys controlled by the
> Subject. I may have been confused about that.

Well, yes, there has been, and it still is, as far as I know.

XRD/ds:Signature/ds:KeyInfo is supposed to be expressing the
keys controlled by the Subject.

>
> In light of that, it's also very important to note that signing an XRD 
> says
> nothing about how to authenticate the Subject of the XRD.
>
> -- Scott
>
>
>