Andreas Jellinghaus wrote:
> Am Dienstag 02 Februar 2010 14:04:57 schrieb Viktor TARASOV:
>
>> I guess not only consolidation -- one day 'pkcs15', 'pkcs15init' and
>> 'pkcs11' frameworks in OpenSC should be really 'multi-application'.
>> 'Sc_pkcs15_bind' should accept the AID of the application;
Am Dienstag 02 Februar 2010 14:04:57 schrieb Viktor TARASOV:
> I guess not only consolidation -- one day 'pkcs15', 'pkcs15init' and
> 'pkcs11' frameworks in OpenSC should be really 'multi-application'.
> 'Sc_pkcs15_bind' should accept the AID of the application;
> 'framework-pkcs15' should make the
Am Dienstag 02 Februar 2010 12:50:29 schrieb Martin Paljak:
> Two separate frameworks in the pkcs#11 module, as they exist now, don't
> make sense (separate pkcs15init and pkcs15)
so what do we need to do to clean this up and keep only the used code?
> the same way separated pkcs15init library
Martin Paljak wrote:
> On Feb 1, 2010, at 18:54 , Viktor TARASOV wrote:
>
>> Martin Paljak wrote:
>>
>>> On Feb 1, 2010, at 17:07 , Andreas Jellinghaus wrote:
>>>
>>>
Am Montag 01 Februar 2010 15:10:05 schrieb Viktor TARASOV:
fine with me.
btw: if you need to
On Feb 1, 2010, at 18:54 , Viktor TARASOV wrote:
> Martin Paljak wrote:
>> On Feb 1, 2010, at 17:07 , Andreas Jellinghaus wrote:
>>
>>> Am Montag 01 Februar 2010 15:10:05 schrieb Viktor TARASOV:
>>>
>>> fine with me.
>>>
>>> btw: if you need to touch pkcs11/ for that, maybe you know the
>>> code
Am Montag 01 Februar 2010 17:51:28 schrieb Viktor TARASOV:
> As for alternative to pkcs#15 -- I don't feel what for.
>
> (One can say that the alternative to pkcs#15 is already realized by the
> OpenSC itself -- with its emulators for the non-pkcs15 cards . )
>
> Maybe someone else can give the u
Martin Paljak wrote:
> On Feb 1, 2010, at 17:07 , Andreas Jellinghaus wrote:
>
>> Am Montag 01 Februar 2010 15:10:05 schrieb Viktor TARASOV:
>>
>>> Sure, one can tell that card specific part can access the sc_pkcs15_card
>>> through the profile->p15_spec,
>>> but, imho, direct manner looks
Andreas Jellinghaus wrote:
> Am Montag 01 Februar 2010 15:10:05 schrieb Viktor TARASOV:
>
>> Sure, one can tell that card specific part can access the sc_pkcs15_card
>> through the profile->p15_spec,
>> but, imho, direct manner looks better.
>>
>
> fine with me.
>
> btw: if you need to touc
Am Montag 01 Februar 2010 16:26:09 schrieb Martin Paljak:
> In real life the two frameworks are deeply interconnected and
> interdependent for now.
>
> It looks like a logical move to me.
so is this something that needs to be kept that way,
to support both read-only/emulated cards and cards wit
On Feb 1, 2010, at 17:07 , Andreas Jellinghaus wrote:
> Am Montag 01 Februar 2010 15:10:05 schrieb Viktor TARASOV:
>> Sure, one can tell that card specific part can access the sc_pkcs15_card
>> through the profile->p15_spec,
>> but, imho, direct manner looks better.
>
> fine with me.
>
> btw: if
Am Montag 01 Februar 2010 15:10:05 schrieb Viktor TARASOV:
> Sure, one can tell that card specific part can access the sc_pkcs15_card
> through the profile->p15_spec,
> but, imho, direct manner looks better.
fine with me.
btw: if you need to touch pkcs11/ for that, maybe you know the
code best: I
Hi,
I propose to change slightly the prototypes of the
sc_pkcs15init_operations procedures,
(excluding maybe 'erase_card', 'init_card', ),
and to pass the 'sc_pkcs15_card' argument instead of 'sc_card' .
For ex. to change
int (*create_key)(sc_profile_t *, sc_card_t *, sc_pkcs15_object_t *)
fo
12 matches
Mail list logo
