On 8/11/2011 11:19 AM, Viktor Tarasov wrote:
> Le 11/08/2011 16:49, Douglas E. Engert a écrit :
>> Victor,
>> Martin points out that both your branch and my ecdh branch
>> at dengert/OpenSC define a struct sc_pkcs15_skey_info.
>> https://github.com/viktorTarasov/OpenSC/commit/819bd829563020c2abad7537a245d57604951aec
>
> I will look it more carefully a little bit later.
>
>
> But the first impression that the intersection of our codes if quite limited.
> My code mainly concerns the 'secretKey' pkcs15 object as it defined by 
> standard and it's using as 'authenticationKey'.
> Afais, you don't need it and intersection is limited by the definition of 
> 'secret_key_info' data type.

In my ecdh branch, there is a hook to call a sc_pkcs15init_store_secret_key
routine that should allow for storing a secret key on a card.
I did not address the generation of a secret key other then via derive.

I believe my skey_info contains all the fields that your version needs.

>
> Your definition is wider and en-globes the mine, so I propose to go ahead 
> with your patches,
> and I will later update my branch.

Thanks. That's up to Martin.

>
>
>> See my note of 8/5 "Mods to add C_DeriveKey and Session
>> based Secret Key Objects at GitHub"
>>
>> In order to support C_DeriveKey, PKCS#11 session based secret
>> key objects, are needed, even if the card can not support
>> secret keys or even if the card is not a PKCS#15 card.
>> An skey_info structure is needed, and it also needs to
>> store the value, key-type and length.
>>
>> Much of the code needed for session based objects, is provided
>> by the code controlled by #ifdef USE_PKCS15_INIT. (I only
>> needed secret key objects, so did not attempt to provide
>> support of other session based objects, but in the future
>> someone may want these too.
>>
>> This code then assumes that a profile is required but a
>> session based object does not need a profile and the object
>> is never written to the card. For example in framework-pkcs15.c
>> pkcs15_create_objects it checks for a profile:
>> rc = sc_pkcs15init_bind(p11card->card, "pkcs15", NULL,&profile);
>> then goes on to create the object calling one of the
>> pkcs15_create_* functions, assuming the object will be on
>> created on the card.
>>
>> I have added a pkcs15_create_secret_key function, that
>> will create session based objects, and has the hooks to
>> allow one to write a sc_pkcs15init_store_secret_key.
>>
>> Note that in my pkcs15_create_secret_key function, I have
>> initialized a skey_info structure, which in all the other
>> objects are initialized in the sc_pkcs15init_store_* functions.
>> The creation of the *_info structures for the other objects
>> could also be moved up a level.
>>
>> This is what I found I needed in libopensc/pkcs15.h
>>
>>
>> struct sc_pkcs15_skey_info {
>> struct sc_pkcs15_id id;
>> unsigned int usage, access_flags;
>> int native, key_reference;
>> size_t value_len;
>> unsigned long key_type;
>> int algo_refs[SC_MAX_SUPPORTED_ALGORITHMS];
>> struct sc_path path; /* if on card */
>> struct sc_pkcs15_der data;
>> };
>> typedef struct sc_pkcs15_skey_info sc_pkcs15_skey_info_t;
>>
>> #define sc_pkcs15_skey sc_pkcs15_data
>> #define sc_pkcs15_skey_t sc_pkcs15_data_t
>>
>
>

-- 

  Douglas E. Engert  <deeng...@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Reply via email to