Do not return CKR_OK with CK_UNAVAILABLE_INFORMATION - #436

Would you be willing to add a small test that ensure this new code branch works correctly ?

Judging by how the CI went red, the code path was covered. cae37fe adjusts the tests

Not clear to me why, but this is making pkcs11-provider fail, this means there are pkcs#11 application that depends on not getting an error when an attribute is simply missing ...

The tls test failure is with the RSA-PSS key. The last log line is:

## Run sanity test with default values (RSA-PSS)

The tls test failure is with the RSA-PSS key. The last log line is:

## Run sanity test with default values (RSA-PSS)

I wonder if the issue here is trying to get a CKA_ALLOWED_MECHANISM attribute that is not present.

But the point is, i seem this commit makes use behave differently than the other tokens, is this a step too far in being "too much" spec compliant?

I wonder if the issue here is trying to get a CKA_ALLOWED_MECHANISM attribute that is not present.

most likely yes as this does not demonstrate in the kryoptic.nss, but only in kryoptic now. NSS does not have a support for this attribute at all and softhsm has the support broken with a workaround in pkcs11-provider so I would not say this necessarily mean that we would be bad at merging this. But we need to dig into what is going on there in pkcs11-provider to be able to catch this.

But we need to dig into what is going on there in pkcs11-provider to be able to catch this.

Well what is going on, I think, is that I was convinced a missing attribute would just show up as an impossible length but the get attribute would still return CKR_OK ?

So I think we first need to fix pkcs11-provider to properly handle the case of a missing attribute by not blowing up the whole search when the attribute is simply missing, if that is what is happening here.

Then once pkcs11-provider is "fixed" we can merge this.

I managed to reproduce this locally. The error on the server is now:

spawn openssl s_server -accept 23456 -groups ?x25519_mlkem768:?x25519:?x448_mlkem1024:?x448:secp256r1:secp521r1:secp384r1:ffdhe2048:ffdhe3072:ffdhe4096:ffdhe6144:ffdhe8192 -naccept 1 -key pkcs11:type=private;id=%00%0d -cert pkcs11:type=cert;object=testRsaPssCert
Using default temp DH parameters                                                 
Private key does not match the certificate public key                            

(for the RSA-PSS key)

Going through the log of this particular test does not show any issue. but printing the certificate on token through openssl shows:

$ openssl x509 -in $RSAPSSCRTURI -text
[...]
       Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
[...]

Which looks like the certificate is already generated wrong (and written to the token).

In the setup log I can see the query for this attribute on private key fails for unknown reason to me

35: C_GetAttributeValue                                     
P:1095989; T:0x139709991121600 2026-04-08 14:55:47.547      
[in] hSession = 0x3                                         
[in] hObject = 0xa5                                         
[in] pTemplate[1]:                                          
    CKA_ALLOWED_MECHANISMS  0000000000000000 / 0            
[out] pTemplate[1]:                                         
    CKA_ALLOWED_MECHANISMS  0000000000000000 / -1           
Returned:  18 CKR_ATTRIBUTE_TYPE_INVALID                    

(while on the previous commands, I clearly see that the keys were generated with this attribute and query for this attribute worked just ok on both public and private keys).

The current kryoptic version 1.5.0 (without this patch) dumps the following in the log but somehow manages to get the allowed mechanisms list:

[2026-04-08 15:27:58.050] [../src/sig/rsasig.c:264] p11prov_sig_pss_restrictions(): Buggy CKA_ALLOWED_MECHANISMS implementation

But this looks like we were getting UNAVAILABLE Information from the CKA_ALLOWED_MECHANISMS attribute on private key before too (the only difference here is the RV):

  35: C_GetAttributeValue                                                                                                                    |  35: C_GetAttributeValue
  P:1106911; T:0x140164596515520 2026-04-08 15:40:47.049                                                                                     |  P:1106177; T:0x140245212603072 2026-04-08 15:37:43.327                                                                                    
  [in] hSession = 0x3                                                                                                                        |  [in] hSession = 0x3
  [in] hObject = 0xa5                                                                                                                        |  [in] hObject = 0xa5
  [in] pTemplate[1]:                                                                                                                         |  [in] pTemplate[1]:        
      CKA_ALLOWED_MECHANISMS  0000000000000000 / 0                                                                                           |      CKA_ALLOWED_MECHANISMS  0000000000000000 / 0
  [out] pTemplate[1]:                                                                                                                        |  [out] pTemplate[1]: 
      CKA_ALLOWED_MECHANISMS  0000000000000000 / -1                                                                                          |      CKA_ALLOWED_MECHANISMS  0000000000000000 / -1 
  Returned:  0 CKR_OK                                                                                                                        |  Returned:  18 CKR_ATTRIBUTE_TYPE_INVALID                                                                                                  

After further inspection, this is the query for the caCert on the token, which does not have ALLOWED_MECHANISM at the moment.

And this return value is contributing to ignoring the ALLOWED_MECHANISMS entirely (on all objects in the session). The follow-up query on the key with ALLOWED_MECHANISM would work, but is not tried by pkcs11-provider due to this failure blocking further queries.

So I guess we will have to formalize what is the expected return value (and if this is it) adjust pkcs11 provider to not consider missing attribute (CKR_ATTRIBUTE_TYPE_INVALID) on one object as not working at all for any other object (even for the price of querying it repetitively on tokens that do not support this). I think this is not explicitly described in the specs so it might be something @simo5 could bring up to the PKCS#11 WG (I think we discussed this before, but not sure if we came up with sufficient outcome).

The hackish "fix" for pkcs11-provider confirming this issue and verifying this is the problem:

diff --git a/src/obj/fetch.c b/src/obj/fetch.c
index bf7c40d..66df983 100644
--- a/src/obj/fetch.c
+++ b/src/obj/fetch.c
@@ -444,10 +447,10 @@ CK_RV p11prov_obj_from_handle(P11PROV_CTX *ctx, P11PROV_SESSION *session,
                 obj->attrs[obj->numattrs] = a[0].attr;
                 obj->numattrs++;
             } else if (ret == CKR_ATTRIBUTE_TYPE_INVALID) {
-                token_supports_allowed_mechs = CK_FALSE;
-                (void)p11prov_token_sup_attr(ctx, obj->slotid, SET_ATTR,
-                                             CKA_ALLOWED_MECHANISMS,
-                                             &token_supports_allowed_mechs);
+                //token_supports_allowed_mechs = CK_FALSE;
+                //(void)p11prov_token_sup_attr(ctx, obj->slotid, SET_ATTR,
+                //                             CKA_ALLOWED_MECHANISMS,
+                //                             &token_supports_allowed_mechs);
             }
         }
         break;

The other option would be defining what "empty" CKA_ALLOWED_MECHANISMS attribute looks like (something else than empty value?) and using that to differentiate from token that does not support this attribute at all and the object not having this attribute explicitly set (that would be for a fix in kryoptic).

The other option would be defining what "empty" CKA_ALLOWED_MECHANISMS attribute looks like (something else than empty value?) and using that to differentiate from token that does not support this attribute at all and the object not having this attribute explicitly set (that would be for a fix in kryoptic).

We need to make sure that the mere presence, w/o any value does not cause pkcs11-provider to reject all mechanisms, ie, present but empty must mean 'all mechanism are allowed'.

I think this would basically require kryoptic to always synthesize empty attributes if they are requested and allowed by the object type, but are not stored in the token.

We need to make sure that the mere presence, w/o any value does not cause pkcs11-provider to reject all mechanisms, ie, present but empty must mean 'all mechanism are allowed'.

That was my naive understanding when I firstly implemented this in softhsm, but at the time when we looked into this in pkcs11-provider, you were not that convinced that this is the right approach. I can not find notes about that anymore. There is also no discussion about this in the TC.

I think this would basically require kryoptic to always synthesize empty attributes if they are requested and allowed by the object type, but are not stored in the token.

Or ignore these failures on pkcs11-provder and not expect missing attribute means no support. For buggy pkcs11 tokens, there is a quirk no-allowed-mechanisms which sounds to me better suitable than the current logic we have in the code. I can draft a PR for that.

Or ignore these failures on pkcs11-provder and not expect missing attribute means no support. For buggy pkcs11 tokens, there is a quirk no-allowed-mechanisms which sounds to me better suitable than the current logic we have in the code. I can draft a PR for that.

Ok let's start with this part.
I still need to figure out if the semantics proposed in this PR are actually correct.

To reiterate, that yes upon Nth reading the semantics are correct, we really ought to return CKR_ATTRIBUTE_TYPE_INVALID if any attribute is not available ... therefore we definitely need to fix pkcs11-provider to deal with it appropriately.