On 25/03/2019 22:29, Matthew Hardeman wrote:
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?
I wonder (but can't be sure) if the GRCA requirements analysis is simply
incomplete. Specifically, I see no claim they have actually found a
client tool having all these properties at the same time:
1. That tool fails to accept certificates containing more EKUs than that
tool needs (example, the tool rejects certs with exampleRandomEKUoid,
but accepts certs without it). Yet it accepts certs with no EKU
extension. The rejection happens even if the EKU extension is not
marked critical.
2. It is absolutely necessary for the object/document signing EE certs
to work with that tool.
3. The tool cannot be easily fixed/upgraded to remove the problem.
If there is no such problematic tool in the target environment, GRCA
could (like other CAs in the Mozilla root program) make a list of needed
specific EKU oids and include them all in their certificate template.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
