Using the EС algorithm in Nss provider gives an error when creating the CSR

[OlhaPeculiar]

[OleksandrSPV]

There is an error.
I use createPKCS10 method from @peculiar/fortify-client-core

@microshine @donskov Do you have any ideas?

[donskov]

@OleksandrSPV Try on the current tools. Maybe this provider doesn't support EС algorithm.

[OleksandrSPV]

@OleksandrSPV Try on the current tools. Maybe this provider doesn't support EС algorithm.

You are right @donskov

The same error there.
What we should do? @OlhaPeculiar

[microshine]

I conducted some research on the issue of saving CSR to a token, and here is what I found:

When we copy a CSR to the token using provider.certificateStorage.setItem, we use the C_CopyObject function on the PKCS#11 module. According to the implementation code of the NSS softoken, this function is implemented by sftk_CopyTokenObject.

https://github.com/servo/nss/blob/master/lib/softoken/pkcs11u.c#L1544C1-L1552

This function, in turn, uses sftk_CopyTokenAttributes, which is likely causing the CKR_ATTRIBUTE_INVALID error.

https://github.com/servo/nss/blob/master/lib/softoken/pkcs11u.c#L1489-L1536

Interestingly, even if we find and fix the erroneous attribute, we will encounter another error, CKR_DEVICE_ERROR, because sftk_CopyTokenObject does not support CKO_DATA.

Here is the switch..case statement indicating the supported object types:

https://github.com/servo/nss/blob/master/lib/softoken/pkcs11u.c#L1504-L1533

Therefore, it appears that we should not allow saving CSR to the token for the NSS provider.

Ideally, to avoid such issues across different providers and applications, we need to extend the Fortify API to provide more information about the provider's capabilities. However, this is a significant task that requires careful planning and implementation. For now, I suggest implementing a check at the client level. Currently, the client can obtain a relatively consistent provider name, which offers a high probability of identifying the provider. For example, MacOS Crypto for macOS and Firefox NSS for NSS. We can add a configuration at the client level to restrict provider capabilities by name. For instance, we can add Firefox NSS with an indication that it does not support saving CSR to the token.

Something like this:

const PROVIDER_LIMIT = {
  'Firefox NSS': ['csr:save'],
}

This approach will help us manage provider-specific limitations until we can implement a more comprehensive solution in the Fortify API.