RE: [xri] XRD Signing (and SAML)

["Drummond Reed" <drummond.reed@cordance.net>]

See inline at the end.

> -----Original Message-----
> From: Will Norris [mailto:will@willnorris.com]
> Sent: Monday, June 22, 2009 5:41 PM
> To: OASIS XRI TC
> Subject: Re: [xri] XRD Signing (and SAML)
> 
> 
> On Jun 22, 2009, at 5:09 PM, Will Norris wrote:
> 
> >
> > On Jun 22, 2009, at 3:08 PM, Will Norris wrote:
> >
> >> ## My Proposed Action
> >>
> >> Unless someone points out something I'm overlooking, I'm fairly
> >> confident our current solution covers the use cases previously
> >> addressed with embedded SAML assertions.  I believe that this
> >> renders <TargetSubject /> and <TargetAuthority /> unnecessary.  I
> >> believe that most use cases involving the XRD chaining model of
> >> trust will only need a single <ds:KeyInfo /> (in fact that's all
> >> they've had to date).  For those use cases that need multiple
> >> <KeyInfo /> elements, I believe most will be limited to a period of
> >> time while transitioning off of a soon-to-be-expiring certificate.
> >> So I propose allowing for 0 or more <ds:KeyInfo /> elements
> >> underneath <Link /> (no wrapper element necessary), and doing away
> >> with the XRD Trust namespace and Target* elements.
> >
> > okay, hold off on the suggestion to remove <TargetAuthority />...
> > rethinking that.
> 
> nope, we're still good.  I was thinking about the use case where
> you're using PKI-based trust, but the subject of the certificate used
> to sign the XRD doesn't match anything anywhere in the document or in
> the URI used to retrieve the XRD.  For example (to borrow a little
> from Google's example):
> 
> % curl
> http://www.google.com/accounts/o8/xrd?uri=http%3A%2F%2Fmycompany.biz%2Fjoe
> 
> <XRD>
>    <Subject>http://mycompany.biz/joe</Subject>
> 
> <Alias>http://google.com/accounts/o8/xrd?uri=http%3A%2F%2Fmycompany.biz%2F
> joe
> </Alias>
>    <ds:Signature>
>      <ds:KeyName>hosted-id.google.com</ds:KeyName>
>    </ds:Signature>
>    <Link>
>      <Rel>http://specs.openid.net/auth/2.0</Rel>
>      <!-- ... -->
>    </Link>
> </XRD>
> 
> How else would an XRD consuming application know that "hosted-
> id.google.com" is a valid KeyName to use for signing this XRD unless
> the delegating XRD asserted that?  That was why we added
> TargetAuthority in the first place.
> 
> You do it the same way you would if you were doing the XRD-chaining
> model of trust, with <ds:KeyInfo />.  Only instead of embedding the
> entire certificate using <ds:X509Data />, you include the subject with
> <ds:KeyName />.  This is absolutely the right way to be doing this,
> rather than making up new elements like TargetAuthority.  So the
> delegating XRD would have:
> 
> <XRD>
>    <Subject>http://mycompany.biz/joe</Subject>
>    <ds:Signature>
>      <ds:KeyName>mycompany.biz</ds:KeyName>
>    </ds:Signature>
>    <Link>
>      <Rel>http://specs.openid.net/role/provider</Rel>
> 
> <URI>http://google.com/accounts/o8/xrd?uri=http%3A%2F%2Fmycompany.biz%2Fjo
> e
> </URI>
>      <ds:KeyInfo>
>        <ds:KeyName>hosted-id.google.com</ds:KeyName>
>      </ds:KeyInfo>
>    </Link>
> </XRD>
> 
> yep, no need for TargetSubject or TargetAuthority that I can think of.

Will, I had dinner with John Bradley tonight and we discussed this at some
length. Your points forced us to go back and remember the rationale behind
some of the design decisions in the SAML trusted resolution model in XRI
Resolution 2.0.

You are correct that TargetSubject and TargetAuthority are not /required/
for trust verification using conventional certificates. And that using the
ds:KeyName element helps increase the trust level because it allows the XRD
author to specify the target authority (that should be signing the linked
XRD) using conventional domain names.

However we believe TargetSubject and TargetAuthority should still be
included in XRD 1.0 because they are very useful for two reasons:

a) Further increasing trust, i.e., reducing the attack surface more.

b) Referencing key material rather than including it directly.

In the first case, the protection is against an "XRD substitution attack",
where the attacker is able, through DNS subversion or other means, to have a
link from XRD A to XRD B at Target Authority B return a different XRD (XRD
B1) from the same Target Authority. XRD B1 will still be signed by the
Target Authority B, so it will look legit, but it is not the correct XRD
referenced by XRD A.

This attack can be guarded against if the Link in XRD A uses the
TargetSubject element to specify the Subject in XRD B, and if so, the XRD
verifier must verify that it matches. This rule means target authorities can
to implement a policy in their own domain regarding the Subject value
required in an XRD they will sign (for example, Target Authority B will only
sign XRDs with Subjects in Target Authority B's domain, because it can
verify that the Subject controls the XRD file).

If Target Authority B has such a policy, then the author of XRD A can safely
link from XRD A to XRD B in Target Authority B's domain knowing that if the
Link uses a TargetSubject element to specify the author's legitimate Subject
identifier in XRD B, it should not be subject to a substitution attack.

In the second case, the TargetAuthority element is useful when you want to
reference an XRD that contains the ds:KeyInfo element(s) for a Target
Authority rather than include them directly in the XRD. For example, say a
blog owner wants to publish an XRD that delegates to another XRD at Foo
Authority, but does not want to publish Foo Authority's key material in her
XRD because: a) she might not know it, b) she doesn't want to have to update
it when it changes. So instead she just puts a TargetAuthority element in
the link whose value is the identifier of the XRD for Foo Authority. That
way an XRD processor knows that instead of looking for the key material for
Foo Authority in a ds:KeyInfo element in the link, it needs to look at the
XRD obtained from the value of the TargetAuthority element.

Hope this helps. I'll put this on the agenda for tomorrow's TC call, which
hopefully both John and I can attend from London.

=Drummond