Allow binary PIN values for PKCS11 providers

[ionut-arm]

As mentioned here and here, some PKCS11 tokens allow (or even require) PINs that do not conform to the spec, e.g., containing null bytes. The functionality has already been added (but not released, as of writing this) in the Cryptoki crate to allow such PINs, however this needs to be plumbed up into Parsec.

The authentication value config options for the TPM provider can stand as examples of how this could be implemented, namely by allowing the passed value to take the form hex:..., and to default to treating it as a string otherwise.

Any implementation should be accompanied by configuration tests.

[wiktor-k]

The authentication value config options for the TPM provider can stand as examples of how this could be implemented, namely by allowing the passed value to take the form hex:..., and to default to treating it as a string otherwise.

IIRC TPM also has a str: prefix escape-hatch just in case your password literally starts with hex:... (you'd then input it as str:hex:...).

[mohamedasaker-arm]

Hi all, I think the suggested approach is fine. However, there is an unlikely corner case when the pin of the token is, for example:
"str:hex:normal_string".
The pin is a normal string that has str:hex: as a prefix
The alternative is to have a flag which indicates the type of pin provided

What do you think? Is it okay to ignore this unlikely corner case or go with the other approach?
@ionut-arm @wiktor-k

[ionut-arm]

However, there is an unlikely corner case when the pin of the token is, for example:
"str:hex:normal_string".
The pin is a normal string that has str:hex: as a prefix

I don't think there's a problem there, the value you'd put in would be str:str:hex:... - basically, everything after the first str: is considered as a string PIN. Am I getting this right?

[mohamedasaker-arm]

Yea true, I mean it might get confusing a bit in this case. but indeed it's not a problem with the implementation