On 2021-05-28 22:50, Michael Wojcik wrote:
Just realized I sent this directly to Graham instead of to the list.
-Original Message-
From: Michael Wojcik
Sent: Friday, 28 May, 2021 09:37
To: 'Graham Leggett'
Subject: RE: X509_verify_cert() rejects all trusted certs with "default"
X509_VERIFY_PARAM
From: openssl-users On Behalf Of Graham
Leggett via openssl-users
Sent: Friday, 28 May, 2021 06:30
I am lost - I can fully understand what the code is doing, but I can’t see
why openssl only trusts certs with “anyExtendedKeyUsage”.
Interesting. I wondered if this might be enforcing some RFC 5280 or CA /
Browser Forum Baseline Requirements rule.
5280 4.2.1.12 says:
In general, this
extension will appear only in end entity certificates.
and
If the extension is present, then the certificate MUST only be used
for one of the purposes indicated.
Your certificate has serverAuth and emailProtection, yes? So it cannot be used to sign
other certificates, and OpenSSL is correct as far as that goes. 5280 doesn't define an
EKU for signing certificates; so perhaps the intent of the OpenSSL code is "if EKU
is present, this probably can't be used as a CA cert without violating 5280, but I'll
look for this 'any' usage just in case and allow that".
The errata for 5280 and the RFCs which update it do not appear to affect this
section.
There is a very common extension to the validation of X.509
certificates (which should ideally be available as an option
parameter to OpenSSL validation APIs): The EKU in a CA:True
certificate limits the end cert EKU values that are acceptable.
The rule is NOT applied to ocspSigning due to a conflict with
that EKU authorizing the CA public key to sign OCSP responses
for the parent CA.
For example a CA with EKU=emailProtection,clientAuth cannot be
used to issue valid EKU=serverAuth certificates, however it can
still issue a delegated EKU=ocspSigning delegated OCSP signing
certificate.
In this filtering anyExtendedKeyUsage acts as a wildcard
indicating a universal CA, and In practice, the complete
absence of the EKU extension acts as an equivalent wildcard.
The OpenSSL 3 code discussed, as described by Graham, appears
to incorrectly apply the wildcard check without ORing it with
the normal check for inclusion of the usage for which the chain
is built and validated. (I recommend that where such filtering
is done, it is part of chain building as different chains may
succeed for different usages).
The CA/BF BR 7.1.2.1, the part of the certificate profile that covers root
certificates, says:
d. extKeyUsage
This extension MUST NOT be present.
Now, there's no particular reason for OpenSSL to enforce CA/BF BR, and good reason for it
not to (the "CA" part refers to commercial CAs, and not all clients are
browsers). But it's more evidence that root certificates, at least, should not have
extKeyUsage because browsers can correctly reject those.
The CA/BF profile is more complicated regarding what it calls "subordinate" certificates,
aka intermediates, so for non-root trust anchors there are cases where you can get away with
extKeyUsage. But a good rule is "only put extKeyUsage on entity [leaf] certificates".
So that really leaves us with the question "do we want OpenSSL enforcing the
extKeyUsage rules of RFC 5280?". And I'm tempted to say yes. In principle, the
basicConstraints CA flag and the keyUsage keyCertSign option should suffice for this, but
defense in depth, and in cryptographic protocols consistency is extremely important.
The CAB/F "guidelines" tend to include arbitrary restrictions above and
beyond what good X.509 software libraries should do, such as limiting
validity to 1 year, requiring end certificate holders to be magically
able to respond to sudden revocations for bureaucratic reasons etc. Or
as quoted by Michael, a rule that all roots must be universal roots with
the no-EKU implicit wildcard.
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
