Extension criticality in EE certificates

[TaaviE]

The current implementation in extensions.rs seems to apply the BR a bit inconsistent. I personally stumbled upon it erroring when EKU was marked as critical, which is allowed by RFC 5280 but N in the BR and marked as Criticality:NonCritical. At the same time subjectKeyIdentifier is N (and NOT RECOMMENDED) but marked as Criticality::Agnostic.

It's a bit unclear to me if N in the BR should mean Criticality::NonCritical or Criticality:Agnostic? What's the interpretation of pyca/cryptography?

It seems more reasonable to be Agnostic of criticality if it's allowed by RFC 5280 (and has a purpose) and NonCritical when an extension has been widely considered non-critical.

References

The tables in CA/B Forum TLS Server certificate BR currently specifies the following:

CA-Browser-Forum TLS BR 2.2.2:

7.1.2.7.6 Subscriber Certificate Extensions:

Extension	Presence	Critical	Description
authorityInformationAccess	MUST	N	See Section 7.1.2.7.7
authorityKeyIdentifier	MUST	N	See Section 7.1.2.11.1
certificatePolicies	MUST	N	See Section 7.1.2.7.9
extKeyUsage	MUST	N	See Section 7.1.2.7.10
subjectAltName	MUST	*	See Section 7.1.2.7.12
nameConstraints	MUST NOT	‐	-
keyUsage	SHOULD	Y	See Section 7.1.2.7.11
basicConstraints	MAY	Y	See Section 7.1.2.7.8
crlDistributionPoints	*	N	See Section 7.1.2.11.2
Signed Certificate Timestamp List	MAY	N	See Section 7.1.2.11.3
subjectKeyIdentifier	NOT RECOMMENDED	N	See Section 7.1.2.11.4
Any other extension	NOT RECOMMENDED	‐	See Section 7.1.2.11.5

CA-Browser-Forum TLS BR 2.2.2:

7.1.2 Certificate Content and Extensions

If the CA asserts compliance with these Baseline Requirements, all certificates that it issues MUST
comply with one of the following certificate profiles, which incorporate, and are derived from RFC
5280.

RFC 5280:

   If a CA includes extended key usages to satisfy such applications,
   but does not wish to restrict usages of the key, the CA can include
   the special KeyPurposeId anyExtendedKeyUsage in addition to the
   particular key purposes required by the applications.  Conforming CAs
   SHOULD NOT mark this extension as critical if the anyExtendedKeyUsage
   KeyPurposeId is present.  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.

extensions.rs:

            subject_key_identifier: ExtensionValidator::maybe_present(
                SUBJECT_KEY_IDENTIFIER_OID,
                Criticality::Agnostic,
                None,
            ),
[...]
            // CA/B: 7.1.2.7.10: Subscriber Certificate Extended Key Usage
            // NOTE: CABF requires EKUs in EE certs, while RFC 5280 does not.
            extended_key_usage: ExtensionValidator::maybe_present(
                EXTENDED_KEY_USAGE_OID,
                Criticality::NonCritical,
                Some(Arc::new(ee::extended_key_usage)),
            ),

[alex]

cc: @woodruffw

[woodruffw]

It's a bit unclear to me if N in the BR should mean Criticality::NonCritical or Criticality:Agnostic? What's the interpretation of pyca/cryptography?

My interpretation of the CABF tables is that the symbols have the following meanings for criticality:

• - means "not applicable," usually because another requirement forbids the relevance of the criticality bit. For example, 7.1.2.7.6 says that Name Constrains MUST NOT appear in an EE cert, so criticality is -.
• * means agnostic. For example, 7.1.2.7.6 says that the SAN MUST appear, but can be either critical or non-critical.
• Y and N mean MUST and MUST NOT be critical, respectively.

So yeah, I believe N in the BRs should mean Criticality::NonCritical, and for the Subject Key Identifier in particular NOT RECOMMENDED doesn't have a bearing on the criticality constraint (we accept it either way, but we don't accept it as critical because that specific state is forbidden rather than NOT RECOMMENDED).

[woodruffw]

With that said, I think PyCA Cryptography's general position with respect to BR conformance is that the validator should reflect real-world (i.e. Web PKI) behavior. Are you aware of publicly issued EEs that exhibit a critical SKI, or is this something you've hit on non-Web PKI issuances?

[TaaviE]

So yeah, I believe N in the BRs should mean Criticality::NonCritical, and for the Subject Key Identifier in particular NOT RECOMMENDED doesn't have a bearing on the criticality constraint (we accept it either way, but we don't accept it as critical because that specific state is forbidden rather than NOT RECOMMENDED).

SKI is Agnostic right now though? Is it actually not accepted as critical?

Are you aware of publicly issued EEs that exhibit a critical SKI, or is this something you've hit on non-Web PKI issuances?

Neither, nor have I searched for Web PKI issuances. I encountered a critical EKU in non-Web PKI and started looking into why it was being restricted.

Right now it seems that:

• SKI is Agnostic when it should be NonCritical
• KU is Agnostic when it should be Critical
• BC is Agnostic when it should be Critical

(and EKU is NonCritical when Agnostic would make a bit more sense to require usage enforcement)

I can make a PR to align the checks with the BR.

[alex]

I'm almost positive that in all cases we are less strict than the BRs, it's because there is no security value in it and there was enough ecosystem breakage that it didn't make sense to strictly enforce. If there are cases we're more strict than the specs we should probably fix that!

[woodruffw]

Oh, my bad -- I thought you were saying that we weren't already agnostic. I agree that's a bit inconsistent at the moment.

I'm kind of surprised we don't have an x509-limbo testcase for this 🙂 -- that would be a good guidepost for whether we can/should restrict criticality.

[TaaviE]

Should I make a PR to change EKU to Agnostic to match the enforcement of other extensions' criticality? Or do you wish to first create a test-case in x509-limbo to figure out which extensions' criticality can be enforced according to the BR?

Maybe it would be better to follow the BR unless specifically overridden by the user (or code using the crate/library)? That way any deviations from BR would be explicit.

[alex]

Unless there's a pressing reason, our preference is to match the BRs. It looks like we already have a testcase for this: https://x509-limbo.com/testcases/webpki/#webpkiekuee-critical-eku

(Though it shows as skipped, which is surprising to me.)

[woodruffw]

It looks like we already have a testcase for this

That one is for critical EKU in EEs, not critical SKI. I think we could indeed use a new limbo testcase for this!

Though it shows as skipped, which is surprising to me.

I don't remember exactly, but I think we skipped some of these because none of the other validators checked them. So the idea was that the breakage risk was too high, although now that there's a custom policy API that's probably moot.

[alex]

Unless I misread, @TaaviE's last Q was about EKU specifically.

[woodruffw]

Oh yeah, sorry.

[github-actions]

This issue has been waiting for a reporter response for 3 days. It will be auto-closed if no activity occurs in the next 5 days.