used rather for the debug -- allows to refuse, for example,
'key-import' create container mechanism and to compel the application (IE)
to generate key on card (rather then generate key by soft and then import it onto card).
to prepare future enhancements and in the sake of uniformity
in 'struct sc_pkcs11_framework_ops'
the 'struct sc_pkcs11_card' argument of 'init_token' handler is changed for 'struct sc_pkcs11_slot'
coding style issues
C_Login returns CKR_USER_PIN_NOT_INITIALIZED error when token info flags do not
contains CKF_USER_PIN_INITIALIZED and CKU_USER login type is asked.
This flag is not consulted when CKU_SO or CKU_CONTEXT_SPECIFIC login type is needed
New data are used to support the card specific minidriver on-card files.
Beeing included into internal pkcs15 data type,
these new data are accessible at the all frameworks: emulation of pkcs15 and pkcs15init, minidriver.
the proprietary on-card data can contain the GUIDs created by proprietary MW,
these data are parsed by card driver and put into the internal pkcs15 private key data
to be accesible in the different OpenSC frameworks
existing 'guid' obejct's data replaced by the one in private-key info
New CMAP record data used by pkcs15init emulator for the cards that have
the MD specific on-card data
The name implies what the format of the returned value, a SPKI.
The support for spki as a pkcs15 format of a pubkey, is extended to
work for any algorithm not just EC pubkeys. PKCS#15 appears to allow this.
sc_pkcs15_decode_pubkey_with_param will look for a SPKI
and attempt to use it for any algorithm, including RSA.
(RSA is the null case, as there are no algorithm parameters.)
sc_pkcs15_encode_pubkey_as_spki is exported from libopensc.
pkcs15-piv.c will use sc_pkcs15_encode_pubkey_as_spki to load public keys
as SPKI for RSA and EC.
The pubkey->data is never a SPKI, it is the DER encoding of the
pubkey without the parameters. If an spki is needed, use the
sc_pkcs15_encode_pubkey_as_spki to get the DER encoding of the spki.
As in the previous set of patches, pkcs15-tool.c will output both
sc_pkcs15_decode_pubkey_with_param and its internal.
This was left for testing, and the pubkey_pem_encode should be deleted
The original ECC code in OpenSC stored the ecpointQ as a DER encoded OCTET STRING.
Shortly before 0.13.0, code changes where made to store the ecpointQ as raw data
without the DER encoding.
Only some of the code was changed to support this but not all, and the comments
that said the ecpointQ was in DER where not changed either.
Some card drivers continued to work, using the original code in all place,
while some cards failed, as they where using a mixture of original code and
0.13.0 code.
This commit fixes these problems.
The ecpointQ is stored in raw format
A new structure type sc_pkcs15_u8 is defined.
The ecpointQ are changed to use the struct sc_pkcs15_u8. This was done to avoid
the confusion of using struct sc_pkcs15_der to hold non-DER encoded data.
(There may be other uses for this too...)
Comments are change is many places.
sc_pkcs15_decode_pubkey_ec was fixed to store the raw ecpointQ correctly.
sc_pkcs15_pubkey_from_spki was change to get the sc_ec_params from the alg_id
and fix up u.ec.params. Unfortunately the OpenSC code has two places EC parameters
are stored. They can get out of sync, or there may still be code
that looks in the wrng oplace. o(TODO get it to only only place.)
The u.ec.params.field_length is now set in a number of places, as this is need
in many of the PKCS#11 routines.
framework-pkcs15.c will now correctly return the DER encode ecpointQ,
for the CKA_EC_POINT attribute using pubkey->data which has the DER encoding
for the ecpointQ.
framework-pkcs15.c will look for the EC parameters in either the u.ec.params.der,
or in the alg_id->params. (TODO get it to only only place.)
pkcs15-myeid.c has some comments, as it looks like the code is storing a TLV
rather then a DER encoding of the ecpointQ. With the wrong encoding PKCS#11 will
return the wrong attribute for CKA_ECDSA_PARAMS.
pkcs15-piv.c is changed so emulation of a pubkey taken from a certificate will
work correctly.
The original ECC code in OpenSC stored the ecpointQ as a DER encoded OCTET STRING.
Shortly before 0.13.0, code changes where made to store the ecpointQ as raw data
without the DER encoding.
Only some of the code was changed to support this but not all, and the comments
that said the ecpointQ was in DER where not changed either.
Some card drivers continued to work, using the original code in all place,
while some cards failed, as they where using a mixture of original code and
0.13.0 code.
This commit fixes these problems.
The ecpointQ is stored in raw format
A new structure type sc_pkcs15_u8 is defined.
The ecpointQ are changed to use the struct sc_pkcs15_u8. This was done to avoid
the confusion of using struct sc_pkcs15_der to hold non-DER encoded data.
(There may be other uses for this too...)
Comments are change is many places.
sc_pkcs15_decode_pubkey_ec was fixed to store the raw ecpointQ correctly.
sc_pkcs15_pubkey_from_spki was change to get the sc_ec_params from the alg_id
and fix up u.ec.params. Unfortunately the OpenSC code has two places EC parameters
are stored. They can get out of sync, or there may still be code
that looks in the wrng oplace. o(TODO get it to only only place.)
The u.ec.params.field_length is now set in a number of places, as this is need
in many of the PKCS#11 routines.
framework-pkcs15.c will now correctly return the DER encode ecpointQ,
for the CKA_EC_POINT attribute using pubkey->data which has the DER encoding
for the ecpointQ.
framework-pkcs15.c will look for the EC parameters in either the u.ec.params.der,
or in the alg_id->params. (TODO get it to only only place.)
pkcs15-myeid.c has some comments, as it looks like the code is storing a TLV
rather then a DER encoding of the ecpointQ. With the wrong encoding PKCS#11 will
return the wrong attribute for CKA_ECDSA_PARAMS.
pkcs15-piv.c is changed so emulation of a pubkey taken from a certificate will
work correctly.