On Thu, 6 Dec 2018, Peter Gutmann via dev-security-policy wrote:
Paul Wouters via dev-security-policy <dev-security-policy@lists.mozilla.org>
writes:
Usually X509 is validated using standard libraries that only think of the TLS
usage. So most certificates for VPN usage still add EKUs like serverAuth or
clientAuth, or there will be interop problems.
So just to make sure I've got this right, implementations are needing to add
dummy TLS EKUs to non-TLS certs in order for them to "work"?
You understanding is correct.
In that case why
not add a signalling EKU or policy value, a bit like Microsoft's
systemHealthLoophole EKU (I don't know what its official name is, 1 3 6 1 4 1
311 47 1 3) where the normal systemHealth key usage is meant to indicate
compliance with a system or corporate security policy and the
systemHealthLoophole key usage is for systems that don't comply with the
policy but that need a systemHealth certificate anyway.
I'm not sure how that is helpful for those crypto libraries who
mistakenly believe a certificate is a TLS certificate and thus if the
EKU is not empty it should have serverAuth or clientAuth.
Better to define a new EKU, "tlsCompabitility", telling the relying party that
the TLS EKUs are present for compatibility purposes and can be ignored if it's
a non-TLS use.
As I stated earier, since often these certificates are re-used for the
VPN server's TLS (openvpn, openconnect, etc) protocols or for their
webgui's provisioning API, they will most likely want serverAuth anyway.
btw for nss this got fixed recently:
https://bugzilla.mozilla.org/show_bug.cgi?id=1252891
Paul
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
