If a PKCS#11 library/token doesn't provide one or more attributes via
C_GetAttributeValue(), we get back CKR_ATTRIBUTE_TYPE_INVALID (similar
for protected attributes where CKR_ATTRIBUTE_SENSITIVE is returned).
This is not an error as the spec demands that all attributes have been
processed with the unavailable attributes having set their length
field to CK_UNAVAILABLE_INFORMATION.
We use this to handle the CKA_TRUSTED attribute, which some tokens
apparently don't support. We previously used a version check to remove
the attribute from the call but even the latest spec doesn't make the
attribute mandatory (it's just in a list of "common" attributes for
CKO_CERTIFICATE objects, without a default value), so there are current
tokens that don't support it and prevent us from enumerating certificates.
If cards/libraries don't support signature mechanisms with hashing, we fall
back to do it ourselves in software and pass the PKCS#1 digestInfo ASN.1
structure to sign via CKM_RSA_PKCS mechanism.
Closesstrongswan/strongswan#168.
Some tokens/libraries seem to prefix all numbers with zero bytes even
if not necessary (e.g. the default exponent 0x010001). If we don't fix
that, the fingerprints calculated based on the retrieved values will be
incorrect.
Even if the pkcs1 plugin can properly handle numbers that are not in
two's complement since a81bd670b0 ("Added PUBKEY_RSA_MODULUS
encoding type") we prefix them with zero if necessary as other encoders
might expect them in two's complement.
Fixes#1012.
Some tokens might not fail when creating EC public keys in the incorrect
format, but they will later not be able to use them to verify signatures.
References #872.
Currently this only works if a public key object with the same ID is
available, if there isn't one we could search for a certificate with the
same ID and extract the key from there.
Tobias Brunner