proposal: amend extended key usage of CPPKI Root and CA certificates

[oncilla]

Currently, the specification of the root and ca mandate that in the Extended key usage extension, id-kp-serverAuth and id-kp-clientAuth must not be present.

This leads to a problem when trying to use CPPKI certificates in TLS handshake, as most implementation will only have a valid verification path from leaf to root certificate, if the extended key usages of the leaf are a subset of the extended key usage of the certificates in the chain. In other words, because CA and Root certificates do not have id-kp-serverAuth set, they cannot really be used for standard TLS without additional work arounds.

This is an oversight and makes CPPKI certificates less ergonomic to use than they could be.

My proposal would be to first adjust the implementation to not validate the absence anymore, and once that has found wide adoption in the network, to adjust the specification accordingly. This needs a phased roll out, because simply starting to create Root and CA certificates with id-kp-*Auth set would lead to verification errors on all relying parties that have not been adjusted yet.

[JordiSubira]

IIUC, most of the TLS implementations mandate that the Extended Key Usage fields on the leaf certificate are also present in the Extended Key Usage field for every certificate in the chain?

How does this work with the RFC?

In general, this extension will appear only in end entity certificates

If this is a common practice in most of the TLS implementations, do they provide some justification for this?

[oncilla]

I think you are right. Roots do not have these extend key usages, I will need to dig in more.

Current problem that I'm facing is that Go stdlib does not find a valid verification path if we use our CPPKI as a regular WebPKI root certificate

[nicorusti]

Please let us know if we should update the PKI IETF draft. Right now we might still be in time

[oncilla]

I think the key part is in:

If the extension is present, then the certificate MUST only be used
for one of the purposes indicated. If multiple purposes are
indicated the application need not recognize all purposes indicated,
as long as the intended purpose is present. Certificate using
applications MAY require that the extended key usage extension be
present and that a particular purpose be indicated in order for the
certificate to be acceptable to that application.

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.

If I understand correctly, because we have the extended key usage cppki-root-key, we cannot use the certificate for regular client/server auth, unless we specify anyExtendedKeyUsage too.

I am currently debating what is better:

1. Not having extended key usage at all
2. Having extended key usage + any

I would need to double check how the Go std library deals with this.

[oncilla]

Based on a small test: https://gist.github.com/oncilla/7584759ca580ad644d3fd876677592e1

        --- FAIL: TestRoot/no_id-kp-root/verify (0.00s)
                	Error:      	Received unexpected error:
                	            	x509: certificate specifies an incompatible key usage
        --- FAIL: TestRoot/no_id-kp-root/validate (0.00s)
                	Error:      	Not equal: 
                	            	expected: "cp-root"
                	            	actual  : "cp-ca"
                	Error:      	Received unexpected error:
                	            	[ [ basic constraints not valid ]; authorityKeyId must be present ]
        --- FAIL: TestRoot/no_id-kp-root,_with_any/validate (0.00s)
                	Error:      	Not equal: 
                	            	expected: "cp-root"
                	            	actual  : "cp-ca"
                	Error:      	Received unexpected error:
                	            	[ [ basic constraints not valid ]; authorityKeyId must be present ]
        --- FAIL: TestRoot/current/verify (0.00s)
                	Error:      	Received unexpected error:
                	            	x509: certificate specifies an incompatible key usage

Key Usage	TLS verification out-of-the-box	Old TRC compliant
id-kp-root (current)	❌	✅
no id-kp-root	❌	❌
no id-kp-root, no id-kp-timeStamping	✅	❌
no id-kp-root, any	✅	❌
id-kp-root, any	✅	✅

I would say the best option is to also include the ExtKeyUsageAny alongside the existing key usages.
We will require ExtKeyUsageAny unless we also drop the ExtKeyUsageTimeStamping, which we have for the CMS signatures.

The good thing is that this does not really deviate from the existing spec. If we change the spec to recommend including this extended key usage, all previous TRCs are still spec compliant.

[oncilla]

TL;DR: I think it would be good to change https://docs.scion.org/en/latest/cryptography/certificates.html#extension-constraints to state:

Extended key usage. This extension must present. The id-kp-serverAuth and id-kp-clientAuth purposes must not be set. The id-kp-root and id-kp-timeStamping purpose must be set. The anyExtendedKeyUsage SHOULD be set.

[nicorusti]

Would this also apply to the PKI draft? Right now we describe this in 2.2.2.4. extKeyUsage Extension and we currently don't say anything about anyExtendedKeyUsage

[JordiSubira]

Thank you @oncilla for checking this, it is now more clear how the verification process works and I may be able to understand the RFC a bit better. I do have some questions/doubts on this (aligned with your internal debate between 1 and 2).

• Do we really need "id-kp-root"? It seems somehow a "gratuitous" artificact that we are adding to the trust anchor. If all we want to indicate is that this shouldn't be the "voting" certificate, it is perhaps enough not having any EKU.
• As you said, if we remove this, we still have the "id-kp-timeStamping". Tbh, I also do not understand completely why we need this. If one looks for the main use-case "A time-stamping service supports assertions of proof that a datum existed before a particular time", the question is: how relevant this is to sign CMS (for certificate renewals, if I understand correctly). Especially, how important is this for the CP root?

So, conceptually, in my non-expert opinion, I would argue in favor of dropping those EKUs, if we can (i.e., your option 1.). Of course, I understand that from a practical point of view, adding the "anyExtendedKeyUsage" will make the regular TLS verification work, while not having to "deviate too much" from the spec, but perhaps now is the best moment to change the spec, or better said, it's "the least bad time" to do this.

[oncilla]

I appreciate that right now you have the opportunity to amend the spec, but you need to consider that all the existing productive deployments will then be no-longer spec compliant. So I would push for backwards compatible amendments.

I think we took inspiration from https://github.com/github/smimesign/blob/dbf59be7e92556ee5a9be731611ad96299219629/ietf-cms/verify.go#L65, but I agree that in hindsight, this might not have been a good choice.