On Mon, Mar 25, 2019 at 3:03 PM Ryan Hurst via dev-security-policy < [email protected]> wrote:
> While it may be true that the certificates in question do not contain > SANs, unfortunately, the certificates may still be trusted for SSL since > they do not have EKUs. > > For an example see "The most dangerous code in the world: validating SSL > certificates in non-browser software" which is available at > https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html > > What you will see that hostname verification is one of the most common > areas applications have a problem getting right. Often times they silently > skip hostname verification, use libraries provide options to disable host > name verifications that are either off by default, or turned off for > testing and never enabled in production. > > One of the few checks you can count on being right with any level of > predictability in my experience is the server EKU check where absence is > interpreted as an entitlement. > My ultimate intent was to try to formulate a way in which GRCA could provide certificates for the applications that they're having to support for their clients today without having to essentially plan to be non-compliant for a multi-year period. It sounds like there's one or more relying-party applications that perform strict validation of EKU if provided, but would appear not to have a single standard EKU that they want to see (except perhaps the AnyPurpose.) I'm confused as to why these certificates, which seem to be utilized in applications outside the usual WebPKI scope, need to be issued in a trust hierarchy that chains up to a root in the Mozilla store. It would seem like the easiest path forward would be to have the necessary applications include a new trust anchor and issue these certificates outside the context of the broader WebPKI. In essence, if there are applications in which these GRCA end-entity certificates are being utilized where the Mozilla trust store is utilized as a trust anchor set and for which the validation logic is clearly quite different from the modern WebPKI validation logic and where that validation logic effectively requires non-compliance with Mozilla root store policy, is this even a use case that the program and/or community want to support? _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
