X509v3 keyusage mandatory ?

[sbernard31]

Currently in Scandium, X509v3 keyusage is mandatory for some type of certificate. I mean if the certificate does not include this extension with the digitalSignature value there is no way to do an handshake.

(see CertificateRequest#isSupportedKeyType)

I don't know if this is the right behavior ? I can not find any clear answer but I would say that if the X509v3 usage is present we should check that digitalSignature is present but if the extension is not present we could accept the certificate.

The Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile says : "The key usage extension defines the purpose (e.g., encipherment, signature, certificate signing) of the key contained in the certificate.The usage restriction might be employed when a key that could be used for more than one operation is to be restricted..."

[boaks]

For the 1. analysis, this seems to be only relevant for the client handshaker. So do you expect someone using java on the client but will not be able to present a certificate with that key usage set?

[sbernard31]

To be totally honest, I face this "issue" creating a certificate with simple openssl command. I also see that certificates (which was not created by me) in leshan-integration-test don't have any keyusage extension.

So this makes me search if this is normal that scandium does not accept this kid of certificate.

[boaks]

These extensions are available for openssl

https://access.redhat.com/solutions/28965

But, if you prefer to investigate, if they are really proper used, don't hesitate to do so. May be the "extended key usage" should be also considered, and/or a method is added to the CertificateVerifier which makes the checks of "meetsSigningRequirements" customizable.

[sbernard31]

Thx @boaks, I already found a way to add this kind of extension using openssl. :) I just explained how I came to this question.

Searching I found this : https://stackoverflow.com/questions/15353595/is-it-mandatory-to-have-keyusage-in-certificate-if-using-jdk7/18071857#18071857 Which seems to go in a way that this should be present but not mandatory.

I thing checking only if the extension is present could make sense. Especially in case where you are using domain-issued certificate which is the only supported case in LWM2M 1.0.

But clearly this question is not a critical or urgent one.

[sbernard31]

(I would like to keep this issue open for now as I want to investigate this a bit more)

[sbernard31]

In CertificateRequest#isSupportedKeyType, I change the line like this :

boolean meetsSigningRequirements = !type.requiresSigningCapability() ||
                      (type.requiresSigningCapability() && 
                                 (cert.getKeyUsage() == null || cert.getKeyUsage()[0]));

As expected, the handshake succeed as the check is only done at client side. (This is the client which stop the handshake thinking that its certificate will not be accepted, but currently the server accept it)

FMOV, we should integrate this "fix" as the spec seems to say that this extension is optional and see later if we want to add some constraint about keyusage and extendedKeyUsage?

[boaks]

OK.

[sbernard31]

I pushed this fix in 2.0.x We can just close this issue or keep it open if we want to trace the keyusage feature.

[sbernard31]

I remove my commit from 2.0.x as I missed that it breaks 1 test. I pushed a PR with a fix for this test : #753

[sbernard31]

The fix is pushed again in 2.0.x. (#753)

We can just close this issue or keep it open if we want to trace the keyusage feature.

[boaks]

I stumbled over

https://github.com/wolfSSL/wolfssl/blob/master/src/ssl.c#L4101

Seems, that the key usage is more important for CA then for the server- or client-certificate.

[sbernard31]

A recent thread about this : http://ietf.10.n7.nabble.com/Certificate-keyUsage-enforcement-question-new-in-RFC8446-Appendix-E-8-tp577849p578071.html