[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] XRD trusted discovery workflow
Dirk Balfanz wrote: > > > On Wed, Dec 10, 2008 at 5:54 PM, Brian Eaton <beaton@google.com > <mailto:beaton@google.com>> wrote: > > On Tue, Dec 9, 2008 at 8:35 PM, Dirk Balfanz <balfanz@google.com > <mailto:balfanz@google.com>> wrote: > > - Both in the PKI and in the out-of-band versions the basic > verification > > step seems to go like this: you already have a canonical_id, and > you do the > > following: (1) check that the canonical_id in the XRD document > is the same > > as the canonical_id you're already holding, (2) verify the > signature on the > > document, (3) verify that the key used to sign the document > matches the > > canonical_id in the document. Why bother with the canonical_id > in the > > document in the first place? Why not just (1) verify the > signature, and (2) > > verify that the key used to sign the document matches the > canonical_id > > you're already holding? > > The canonical id in the document is important because it prevents > someone from replaying a document in a different context. For > example, imagine two users with two different XRDs: > > http://www.example.com/good has a signon URL of > http://some-trusted-idp > > http://www.example.com/evil has a signon URL of http://some-evil-idp > > Both XRDs are signed by www.example.com <http://www.example.com> > (which is what you'd expect > since they are authoritative for www.example.com > <http://www.example.com> URLs...). > > Now imagine that some RP is looking for the XRD for > http://www.example.com/good, but an attacker substitutes the XRD for > http://www.example.com/evil. > > Without a canonical ID in the XRD, there's no way for the RP to tell. > OK. I am starting to get it. You want to support a scenario where www.example.com is acting as proxy/delegated signing authority for each user (e.g. good, evil). In this case, there has to be a proof that these users actually delegated the signing task to www.example.com. How do you propose to solve this? I do not quite see how it is done in the current documentation. > > > (If this is coherent/accurate we need to write it down somewhere, > because the attack is kind of subtle.) > > > Ah, I see. > > So I think what's going on here is the following: Since we don't have > keys for http://www.example.com/good vs. http://www.example.com/evil > (we only have one key for www.example.com <http://www.example.com>), > www.example.com <http://www.example.com>'s key is authoritative for > both. If we had two different keys, then this attack wouldn't be > possible, right? Indeed. And that is what I have been promoting. With it, you can rely on PKI chain and it's done. > > But since we only have one key (the one for www.example.com > <http://www.example.com>), that key needs to play both roles, and it > needs to be able to tell us whether its used as the .../good signing > key or the .../evil signing key. That makes sense. Is the CanonicalID > the appropriate field to say that convey that information, or are you > piggy-backing new semantics on an otherwise-defined field? I do not think <CanonicalID> is the right one. There needs to be an explict statement that the Subject identified by CanonicalID has delegated the signing to www.example.com. =nat > > Dirk. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]