Martin Paljak wrote:
>> Added: trunk/src/libopensc/authentic.h
>> ===================================================================
>> --- trunk/src/libopensc/authentic.h (rev 0)
>> +++ trunk/src/libopensc/authentic.h 2010-12-30 14:40:28 UTC (rev 5006)
>>
>> +#define AUTHENTIC_V3_TITLE "AuthentIC.v3"
>> +
>> +#define PAN_ISO7812_SN_TAG 0x5A
>> +#define PAN_ISO7812_LENGTH 0x0C
>>
> These are not used anywhere?
>
Removed.
>> +
>> +#ifndef CKM_RSA_PKCS
>> + #define CKM_RSA_PKCS 0x00000001
>> + #define CKM_SHA1_RSA_PKCS 0x00000006
>> + #define CKM_SHA256_RSA_PKCS 0x00000040
>> + #define CKM_SHA_1 0x00000220
>> + #define CKM_SHA256 0x00000250
>> +#endif
>>
> Why not include src/pkcs11/pkcs11.h ?
>
I would like to avoid something like "include ../pkcs11/ ..." .
>> +#define AUTHENTIC_SDO_MAGIC_UPDATE _MAKE_AUTHENTIC_MAGIC('A', 'W',
>> 'U', 'D')
>> +#define AUTHENTIC_SDO_MAGIC_UPDATE_RSA _MAKE_AUTHENTIC_MAGIC('A', 'W',
>> 'U', 'R')
>>
> These seem to be unused as well?
>
Ok,
utility of 'magic' members has to be reconsidered.
>> +#define AUTHENTIC_MECH_CREDENTIAL_PIN 0x00
>> +#define AUTHENTIC_MECH_CREDENTIAL_BIO 0x01
>> +#define AUTHENTIC_MECH_CREDENTIAL_DES 0x02
>> +#define AUTHENTIC_MECH_CREDENTIAL_2DES 0x03
>> +#define AUTHENTIC_MECH_CREDENTIAL_3DES 0x04
>> +#define AUTHENTIC_MECH_CREDENTIAL_AES128 0x05
>> +#define AUTHENTIC_MECH_CREDENTIAL_AES192 0x06
>> +#define AUTHENTIC_MECH_CREDENTIAL_AES256 0x07
>> +
>> +#define AUTHENTIC_MECH_CRYPTO_DES 0x02
>> +#define AUTHENTIC_MECH_CRYPTO_2DES 0x03
>> +#define AUTHENTIC_MECH_CRYPTO_3DES 0x04
>> +#define AUTHENTIC_MECH_CRYPTO_AES128 0x05
>> +#define AUTHENTIC_MECH_CRYPTO_AES192 0x06
>> +#define AUTHENTIC_MECH_CRYPTO_AES256 0x07
>>
> Seem to be unused?
>
>
>> +#define AUTHENTIC_ACL_NUM_PIN_VERIFY 0
>> +#define AUTHENTIC_ACL_NUM_PIN_RESET 1
>> +#define AUTHENTIC_ACL_NUM_PIN_CHANGE 2
>> +#define AUTHENTIC_ACL_NUM_PIN_MODIFY 3
>> +#define AUTHENTIC_ACL_NUM_PIN_DELETE 4
>>
> Only AUTHENTIC_ACL_NUM_PIN_RESET is used?
>
These definitions come from the card specification.
I prefer to keep them during the time needed for stabilization of the
AuthentIC card support.
>> +struct sc_authentic_tlv {
>> + unsigned tag;
>> + size_t size;
>> + unsigned char *value;
>> +};
>>
> TLV handling should be implemented somewhere centrally.
> Mental note: locate the different incarnations of tlv objects and code in
> OpenSC/src.
>
Ok, I'll look.
> Could you add some comments to the structures? Without having documentation
> around, it is really hard to understand what exactly should "sdo_docp" refer
> to?
>
Ok, will do it gradually.
>> +struct sc_authentic_sdo {
>> + unsigned char sdo_class;
>> + unsigned char sdo_ref;
>> +
>> + unsigned int usage;
>> +
>> + struct sc_authentic_sdo_docp docp;
>> +
>> + union {
>> + struct sc_pkcs15_prkey *prvkey;
>> + } data;
>>
> This will hold plaintext RSA private key parameters. Why? When importing a
> private key, the key object should already come from pkcs15-init (or
> equivalent)?
>
'data.prvkey' is used to pass the key material from 'pkcs15init' to
'libopensc' when importing RSA key .
DOCP (Data Object Control Parameters) used to pass ACLs, usage, etc.
parameters to the low level card handles .
>> +
>> + struct sc_file *file;
>> +
>> + unsigned magic;
>> +};
>>
> Do we really need magic numbers for internally created and in-memory only
> objects?
> This relates to the similar assert-s in src/libopensc which IMHO are 99.9%
> redundant. Compilers and the warning they give should be used for checking
> programming errors and memory corruption and such should be checked and
> fought against on the OS layer.
>
Agree,
usage of 'magic' has to be reevaluated.
> Also, why are there authentic_pkcs15_fix* functions in pkcs15-authentic.c?
> Why the caller or the driver can't do the "right" think from the start?
>
It's difficult to do for 'caller', better do it at the level that have
an access to PKCS#15 -- 'pkcs15init' or 'pkcs15' in libopensc.
Fix* functions is used when creating new file or SDO, and so, it seems
natural to implement them in the pkcs15init part.
Example:
in card profile the 'CHV' method for the ACLs codes is used.
To encode 'accessControlRules' we need the Pkcs#15 ID of authentication
object that contains the reference to CHV PIN.
(For Ias/Ecc card, that is comming soon, to encode ACLs of file or SDO
the SE number has to be deduced from the CHV number.)
Probably it also could be done at the libopensc level, but for a while I
would not like to avoid the massive usage of the sc-pkcs15-* functions
in the card libopensc driver.
--
Viktor Tarasov <viktor.tara...@opentrust.com>
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
