-- Forwarded message --
From: Carlos Lima
Date: 2010/3/19
Subject: RE: FW: PT eID middleware license violations
To: Ludovic Rousseau
Ludovic,
We made a custom implementation of the OpenSC, for the PT e-ID
middleware. Very little functionality is in there.
In the right time, we
Hello Carlos,
2010/3/19 Carlos Lima :
> From: Carlos Lima
> Sent: sexta-feira, 19 de Março de 2010 1:31
> To: 'opensc-internal-ow...@lists.opensc-project.org'
> Subject: PT eID middleware license violations
>
>
>
> Dear All
>
> Following this issue found on your internal forum, I hereby informing
Rickard Bellgrim wrote:
>>
>> Definately my recommendation. I'm also working with all the big HSM
>> vendors and you don't have to save space on any of them, at a minimum
>> you can store about one hundred objects in a single slot. So for PKI
>> purposes there is vast space available. None of the
Hi,
I would like to start to submit the support for the cards IAS/ECC as it
defined in 'Gixel' specification [1] .
File system of this card is based on PKCS#15.
This support should include multi-applications, secure messaging (SM),
external authentication (EA), qualified signature, ...
Support
Martin Paljak wrote:
> On Mar 19, 2010, at 09:39 , Viktor TARASOV wrote:
>
>> Andreas Jellinghaus wrote:
>>
>>> I like the change with "struct foo" vs. "foo_t", but also I prefer
>>> variable names in function definitions. but I'm not sure if
>>> that results in problems, if people want to
On Mar 19, 2010, at 09:39 , Viktor TARASOV wrote:
> Andreas Jellinghaus wrote:
>> I like the change with "struct foo" vs. "foo_t", but also I prefer
>> variable names in function definitions. but I'm not sure if
>> that results in problems, if people want to use different names.
>>
>> (no need to
Hi,
the support of the Oberthur card in OpenSC has been re-implemented and
now it uses the emulation of the pkcs15 and pkcs15init.
Card initialized with OpenSC do not contains the on-card PKCS#15 file
system,
but only the Oberthur's 'native' file system.
Card initialized with OpenSC and crypto
Andreas Jellinghaus wrote:
> I like the change with "struct foo" vs. "foo_t", but also I prefer
> variable names in function definitions. but I'm not sure if
> that results in problems, if people want to use different names.
>
> (no need to change, only meant as feedback...)
>
My intention was
Definately my recommendation. I'm also working with all the big HSM
vendors and you don't have to save space on any of them, at a minimum
you can store about one hundred objects in a single slot. So for PKI
purposes there is vast space available. None of the big HSM vendors
license per storage, it
