Re: [xri] XRD trusted discovery workflow

[Dirk Balfanz <balfanz@google.com>]

On Wed, Dec 10, 2008 at 5:54 PM, Brian Eaton <beaton@google.com> wrote:

On Tue, Dec 9, 2008 at 8:35 PM, Dirk Balfanz <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 (which is what you'd expect
since they are authoritative for 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.

(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), www.example.com's key is authoritative for both. If we had two different keys, then this attack wouldn't be possible, right? 

But since we only have one key (the one for 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?

Dirk.