[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] XRD trusted discovery workflow
Dirk Balfanz wrote:
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.
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 XRDs are signed by www.example.com <http://www.example.com> <http://www.example.com> URLs...).
> - 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
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.
Indeed. And that is what I have been promoting. With it, you can rely on PKI chain and it's done.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?
(If this is coherent/accurate we need to write it down somewhere,
because the attack is kind of subtle.)
Ah, I see.
I do not think <CanonicalID> is the right one.
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?
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]