Re: [xri] Trust

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

Inline:

Scott Cantor wrote:

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.
  

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.

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.
  

It is like XRI authorities signing XRD for the next segment, I suppose.

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.

  

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.

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
  

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.

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.
  

Do you think a third party signature service will help ease the problem?

-- Scott