On 30 September 2014 20:37, John Bradley <ve7jtb(_at_)ve7jtb(_dot_)com> 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.