x509: allow AnyExtendedKeyUsage for CA

[furmur]

Resolves #5308

• add new OID 2.5.29.37.0 = X509v3.AnyExtendedKeyUsage
• consider X509v3.AnyExtendedKeyUsage as certificate signing compatible purpose

[coveralls]

coverage: 90.049% (-0.005%) from 90.054%
when pulling f50701d on furmur:improvement/x509/any_eku_for_CA
into 6d81b0c on randombit:master.

[reneme]

Generally this looks good to me, but I'm wondering if we should consider this new "any usage" in X509_Certificate::allowed_extended_usage() as well:

botan/src/lib/x509/x509cert.cpp

Lines 481 to 492 in f97d7db

	bool X509_Certificate::allowed_extended_usage(const OID& usage) const {
	const std::vector<OID>& ex = extended_key_usage();
	if(ex.empty()) {
	return true;
	}
	if(std::find(ex.begin(), ex.end(), usage) != ex.end()) {
	return true;
	}
	return false;
	}

... essentially, if ex contains "X509v3.AnyExtendedKeyUsage" we may immediately return true and don't even bother checking the vector.

However, RFC 5280 Section 4.2.1.12 quite vaguely states:

Applications that require the presence of a particular purpose MAY reject certificates that include the anyExtendedKeyUsage OID but not the particular OID expected for the application.

However, in my opinion, if we consider "any usage" good enough for specifying a CA, we might as well consider it for other usages as well.

[furmur]

@reneme changed X509_Certificate::allowed_extended_usage() as well.

as for RFC vagueness, that's why i was asking in the issue #5308 whether this behavior should be covered by policy but as randombit said it already tolerates omitted extension so no big changes here.

[reneme]

Changes look fine to me.

Do you happen to have a certificate handy that we could place in the test suite to exercise those new checks? (Edit: just recalled that you had in fact already posted some, sorry.) Perhaps along those lines. I.e. a CA certificate that doesn't have any specific EKUs but just "any". Just place it in "src/tests/data/x509/misc" and add a test ensuring that it recognized as 1) "a CA" and 2) capable of signing CRLs, OCSPs or similar.

[furmur]

2. capable of signing CRLs, OCSPs or similar.

added test. but cert is considered as not capable for OCSP because X509_Certificate::allowed_usage() uses
has_ex_constraint() instead of modified allowed_extended_usage().

maybe it's ok to leave it this way (otherwise should to modify has_ex_constraint() as well)

testing cert ku/eku:

X509v3 extensions:
    X509v3 Extended Key Usage: 
        Any Extended Key Usage
    X509v3 Key Usage: critical
        Digital Signature, Certificate Sign, CRL Sign

[reneme]

added test. but cert is considered as not capable for OCSP because X509_Certificate::allowed_usage() uses
has_ex_constraint() instead of modified allowed_extended_usage().

I found it surprising that "PKIX.ServerAuth" and "PKIX.ClientAuth" is checked with allowed_extended_usage but "PKIX.OCSPSigning" uses has_ex_constraint. I did some digging, and that was changed in #3067 as a fix for CVE-2022-43705. I'm not 100% sure anymore but this was probably meant to enforce the existence of the extended key usage and fail when no EKU-extension is available instead of just letting it pass.

maybe it's ok to leave it this way (otherwise should to modify has_ex_constraint() as well)

I think, has_ex_constraint() should also say "yes" if the new "any" EKU is present.

[furmur]

changed:

• has_ex_constraint() to return true on X509v3.AnyExtendedKeyUsage in extended key usage oids
• allowed_extended_usage() to use has_ex_constraint()

allowed_usage(Usage_Type::OCSP_RESPONDER) for certs with X509v3.AnyExtendedKeyUsage and without PKIX.OCSPSigning now returns true.