Hi Scott,
--------------------------------------------------
From: "Scott Cantor" <>
Sent: Thursday, July 16, 2009 2:48 AM
To: "Sakimura Nat" <>
Cc: "'Drummond Reed'" <>; "'Breno de Medeiros'"
<>; "'XRI TC'" <>
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
>
>
>
