Fail to sign artifacts when ExtendedKeyUsage claim is absent from issuer certificate

[mayaCostantini]

Description

Signing an artifact against a private instance of Fulcio deployed with a password-protected private key backend raises an ExtensionNotFound error. After investigation, it seems like when verifying the SCT, the _is_preissuer internal method fails if it cannot find the ExtendedKeyUsage extension in the issuer certificate.

However I did not observe this behavior when signing with Cosign against the same instances.
The issue is also absent when signing with sigstore-python against another private instance of Sigstore deployed with a Google CA backend, which seems to provide the correct extensions.

Version

sigstore-python v1.1.1

[woodruffw]

Hmm, could you say more about the expected behavior here? From this:

Signing an artifact against a private instance of Fulcio deployed with a password-protected private key backend raises an ExtensionNotFound error. After investigation, it seems like when verifying the SCT, the _is_preissuer internal method fails if it cannot find the ExtendedKeyUsage extension in the issuer certificate.

-- it sounds like your backing CA isn't using a Precertificate Signing Certificate per RFC 6962.

My read of the RFC is that the CA is required to do one of two things:

• Either use a Precertificate Signing Certificate (which MUST have an EKU extension);
• Or sign the TBSCert with the CA certificate that will sign the final certificate.

We haven't seen the latter in practice with Sigstore, but maybe that's what's happening here 🙂

[ccordoui]

Yes indeed, we are hitting the second case with the TBS that need to be signed by the same Authority than the final one.

As such the CA doesn't need to have the CT EKU, in fact it does not need to have an EKU at all.
That being said, the first line of _is_preissuer:

ext_key_usage = issuer.extensions.get_extension_for_class(ExtendedKeyUsage)

Assumes that we have at least one EKU and only checks whether or not CT is one of them, wich doesn't comply with the RFC which only require EKU for the Precertificate Signing Certificate.

One last thing, I might be wrong but the Precertificate Signing Certificate and the certificate signing the final certificate should both be trusted CA, I couldn't found the part of the code that is verify the CA:true extension and I think that we are also missing the verification of the chain, I can only see a comment here that is stating that Cryptography do not do it (yet).

[woodruffw]

Cool, thanks for confirming.

One last thing, I might be wrong but the Precertificate Signing Certificate and the certificate signing the final certificate should both be trusted CA, I couldn't found the part of the code that is verify the CA:true extension and I think that we are also missing the verification of the chain, I can only see a comment here that is stating that Cryptography do not do it (yet).

I believe that's right, concerningly -- I don't remember why we don't do the full chain verification here. I'll have some more time to look into this later today.

CC @asraa and @haydentherapper -- I figure one or both of you might have some more context here, including what other clients do w/r/t SCT chain validation 🙂

[woodruffw]

I believe that's right, concerningly -- I don't remember why we don't do the full chain verification here. I'll have some more time to look into this later today.

Answering my question: we don't do chain verification in the precertificate case because we're doing plain-old public key cryptography here, with the ctfe.pub (or equivalent) that's embedded in our root of trust (via TUF).

[haydentherapper]

+1 to @woodruffw. Agreed that we should ideally support all of RFC6962, but given that we'll have to do a bit of work to support that (it's going to differ by language, golang has good SCT support but other languages don't), are you open to signing with a separate key rather than the CA?

[ccordoui]

I think I see the reasoning behind not verifying the chain (we blindly trust that TUF is providing us the right CA cert for the CT), even though it would be better to do it just to prevent edge cases in a perfect world.

If I've read correctly, the RFC 6962 states that in the precertificate case, we should have the CA:true extension and the CT EKU, if one is verified, it would be logical to verify the other, wouldn't it?

Anyway the problem of @mayaCostantini isn't with the precertificate case but in the case where the CT CA is the same for both, the TBS and the final certificate.
In that case there is no need for any EKU, and _is_preissuer shouln't assume that an EKU is present here:

ext_key_usage = issuer.extensions.get_extension_for_class(ExtendedKeyUsage)

It should be at least catch cryptography.x509.ExtensionNotFound exception and return False.

[woodruffw]

If I've read correctly, the RFC 6962 states that in the precertificate case, we should have the CA:true extension and the CT EKU, if one is verified, it would be logical to verify the other, wouldn't it?

Agreed; I'll add that check 🙂

It should be at least catch cryptography.x509.ExtensionNotFound exception and return False.

Makes sense to me, I'll add that as well.