[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Trust (was: Re: [xri] Re: The elements formerly known as TargetAuthority and TargetSubject)
Nat Sakimura wrote on 2009-07-15: >> 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? It relates to the answer you gave at the end about representing ownership of keys. I was not under the impression that the only signer for an XRD was supposed to be the Subject itself. So what I was saying was that I was envisioning the ability to rely on third party registration authorities to sign XRDs, because there are ways to create trust in those authorities that don't presume PKIX validation, and don't rely on the use of DNs as the only means of connecting things together. The problem with DNs is that they don't work. They've been misused and turned into meaningless garbage and at this point they do more harm than good anywhere they show up. Look at the craziness of subjectAltName and SSL server name validation, just to get around the fact that certificates are wedded to DNs. > 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. That was not at all clear to me, but it essentially says that XRDs have to be signed by their Subject. That seems questionable to me. One reason being that in general, authentication of the XRD should be interchanageable at the transport or message layers. If I host something unsigned at an SSL-protected site, the "signer" of the XRD is the owner of the SSL certificate, and that doesn't seem to make sense to me in light of what you're saying above. You also have the problem that a Signature can only carry a single key, and as we discussed, supporting multiple keys is important for key management. But it is certainly true that recognizing that the signer and the subject don't have to be the same introduces a much more complex set of scenarios. That's why I've been asking all the questions, because I was proceeding from that assumption. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]