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