[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] Trust
Scott Cantor wrote:
As I have expressed in the telecon, I did not mean that the signer must be the Subject himself, but I meant that it is the designated signatory.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.
It is like XRI authorities signing XRD for the next segment, I suppose.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.
Yeah. It is rather unfortunate. I still think that a community can set up a CA with restricted use of SubjectAltName to solve the problem, but it is not something that should be in a spec., but community rule.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.
As I said above, I did not mean that it had to be signed by the Subject. See my blog post on OpenID use case. The Discovery service is the designated signatory. By "controlled by", I meant "designated by". Sorry for the bad choice of the word.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
Do you think a third party signature service will help ease the problem?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.