Re: [stir] Canonicalization vs. Comparison

[Hadriel Kaplan <[e-mail]>]

On Mar 3, 2014, at 9:50 AM, Michael Hammer <[e-mail]> wrote:

> Richard,
> 
> The inclusion of the golden object in the message is a waste, since the
> receiver must re-generate it anyway.
> The receiver cannot rely on just the golden object, since that could be
> spoofed.
> It can rely only on the one it generates itself, and can pretty much ignore
> the one in the message.
> So, this really devolves to just one case.

Actually there were three benefits to it, identified in draft-kaplan-stir-ikes-out-00:

1) It lets the verifier perform a very quick fail check using just strcmp(). In other words, if the golden object it generates from the To/From don't string-match the one in the Identity-X header, then it can go ahead and fail the verification immediately without bothering to get the cert, do the crypto, etc.  IF the strings match, then it has to keep doing the rest of the work to verify it.

2) It helps debug problems for the folks running the systems.

3) It provides a way to do a "if-then-else" conditional, in case there are multiple potential golden objects. I raised that at the mic today, but kinda forgot when exactly that might happen; I just re-read the IKES draft and it points out that in call-forwarding scenarios the verifier may well have multiple To/From canonical numbers to choose from.


> Also, there is a danger that someone takes a short cut and does not validate
> the included golden object.

Yup.  The implementor has to follow the MUSTs.  Not much we can do about them not doing so. :(

-hadriel