Hello, On 08.01.2011 13:55, Martin Paljak wrote: > On Jan 2, 2011, at 6:24 PM, Viktor TARASOV wrote: >> Martin Paljak wrote: >>> 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 . > No other driver has the need to use card specific data structures to keep the > extra copy of the key.
It's not completely true. Look MyEID and (sorry) Oberthur. Many of the cards are encoding the key material into the 'key-import' data buffer directly in the pkcs15init handles. IMHO, it's not a good practice -- this operation is not related to the pkcs15init aspects and has to be done by the lower card specific level. > This is the API in src/pkcs15init/pkcs15-init.h > > int (*store_key)(struct sc_profile *, struct sc_pkcs15_card *, > struct sc_pkcs15_object *, > struct sc_pkcs15_prkey *); > > Why using the incoming sc_pkcs15_prkey is not enough? It's used to transfer the key data to the card specific 'store-key' CTL call. >>> 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. > OK, reasonable. > > -- 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
