Paul Wouters via dev-security-policy <[email protected]> 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"? 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. In theory there's the anyExtendedKeyUsage that seems to do something like this: If a CA includes extended key usages to satisfy such applications, but does not wish to restrict usages of the key, the CA can include the special KeyPurposeId anyExtendedKeyUsage in addition to the particular key purposes required by the applications. but thats vague enough, and little-supported enough, that expecting existing implementations to handle it correctly out of the box seems pretty risky. 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. Peter. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
