[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] XRD Signing (and SAML)
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]