On 30 September 2014 20:37, John Bradley <[email protected]> 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.
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
