On Thu, 31 Jan 2019, Michael Richardson wrote:
If it arrives via a protocol, and must be validated, then all sorts of checks are reasonable, but in general, I dislike checks that reject certificates because they contain *more* than is expected.
The trouble seems to be that IKE implementations did accept more (like serverAuth) and some did accept weird things like critical bit with EKU's unrelated to IKE/IPsec.
I don't think it helps anyone, not even the lawyers, and contributes to widespread (weak) PSK usage.
I think that was more openssl being the only crappy tool that there was fault :P It's entertaining to see WireGuard go through the same. Certificates are too complex and annoying, lets only support raw keys. We tried that 25 years ago :) So the issue we have now is that we have an RFC with requirements and the real world not following these requirements at all. For example, do you accept a subjectAltName of type dNSName with an IP address in text form. If you are strict on the CA flag, then self-signed certs have to be rejected. And the other issue is that if you want to use a certificate for IKE and TLS (eg an SSL VPN), then you have two PKIX profiles that might actually have contractory constrains or requirements. Additionally, whether you like it or not such a combined certificate will be forced to comply to CAB/forum. As an expale, loading your LetsEncrypt certificate into IKE to use it for SSL-VPN and IPsec VPNs. I think actual deployment, and what is specified in RFCs, at least in RFC 4945, has diverted quite a bit. I think 4945 needs to be updated. But that update would almost have to be "TLS compliant", so it basically comes down to "ignore all the 4945 stuff". Paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
