Re: [jose] Gen-ART review of draft-ietf-jose-json-web-signature-33

[Dave Cridland <[e-mail]>]

On 30 September 2014 20:37, John Bradley <[e-mail]> wrote:

> I agree, the likelihood of the application correctly walking the path and
> validating the chain is very small.
>
>
I think the likelihood of the application being *able* to is small given
the scope - however if it can, we should assume that it will.


> I strongly prefer leaving it a MUST use TLS and validate the server per
> RFC 6125.
>
> The other thing to note is that the CN of the cert is not in the header.
> If TLS is not used an attacker could simply modify the DNS to retrieve any
> valid certificate and use that to sign.
>
>
Whilst I agree there's a range of attacks possible against non-validating
clients - although "the CN of the cert" sets my teeth on edge - an attacker
cannot do these if the application performs path validation and checks the
key matches.

"SHOULD" and "MUST" are not a stick to beat the unthinking implementer, and
if there exist perfectly reasonable cases where this particular MUST can be
ignored, then by insisting on a MUST here we are simply weakening the
emphasis that all other RFC 2119 language has in this document.

"MUST unless you do X" is a compromise I'd be happy with, although that is
basically what "SHOULD" means.

Certainly this does require the rationale be documented in any case.

Dave.