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

["Scott Cantor" <cantor.2@osu.edu>]

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.

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.

> 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. ;-)

But broadly, this is the two set of cases you worked up woth 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.

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.

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.

> 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.

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.

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