> From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> On Behalf Of Jakob > Bohm via openssl-users > Sent: Tuesday, 1 June, 2021 09:58 > > 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. Makes sense. It would be nice if this were standardized as an update to RFC 5280. > 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). Yeah, I suspected that, but I wanted to see if other people more familiar with this area of the code were going to comment. > 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. Agreed. I refer our customers to the CA/BF Basic Requirements when they're dealing with browsers and mainstream web servers -- since those programs are often written to follow the CA/BF rules -- but try to make it clear that the CA/BF doesn't control PKIX. -- Michael Wojcik
