Wrong certificate usage attributes handling or documentation issue in 7.1.1.1. Certificate Key Usage Attributes

[mdelete]

Describe the bug
If you have a certificate with (non-critical) extended key usage code signing and do not enable check-purpose=codesign in the config, the verification fails. If check-purpose=codesign is set, verification is successful.

I would expect, that if check-purpose is not set, certificates regardless of having extended key usage codesigning or not would verify successfully, as it is stated in the documentation:

By default (for backwards compatibility reasons), RAUC does not check the certificate’s key usage attributes.

Background information
Yocto Kirkstone, Linux, iMX8, RAUC 1.11.1

To Reproduce

• Have a certificate with non-critical extended key usage codesigning:

X509v3 extensions:
  X509v3 Key Usage: critical
    Digital Signature, Key Agreement
  X509v3 Extended Key Usage: 
    Code Signing

• Have check-purpose=codesign not set.

Expected behavior
Image installation succeeds, as the certificate is valid but no check for extended purposes is done.

Logs
0% Installing
0% Determining slot states
10% Determining slot states done.
10% Checking bundle
10% Verifying signature
20% Verifying signature failed.
20% Checking bundle failed.
100% Installing failed.
LastError: signature verification failed: Verify error: unsuitable certificate purpose

Additional context
In my opinion, it is debatable if the check should fail if check-purpose in not set and the extended key usage is marked critical in the certificate, as according to the standard, a verification of a certificate should fail if the checking system does not recognise a critical extension, but should ignore a non-critical extension. So in my opinion, at least a certificate that has the non-critical extended key usage codesigning should be verified ok, if the check-purpose option is omitted, but this might as well be extend to the ones marked critical, as rauc obviously recognises the extension. Also see the section in the RFC (4.2.1.12).