Dear Emanuele,
attached is the patch I had written about. It works if the following
three conditions a met:
1. If on the pkcs15 level a key is known as usable for signing and
decryption, it must be generated in a way that:
* the card can use it to perform PSO_DEC
* the card doesn'
Dear Andre,
> it would be nice, if you could provide some more information about the
> card you are working on. What I'm interested in is: If there are keys on
> the card which are usable for signing but not for decrypting or vice
> versa (in context of pkcs11/15)? And if so, is the pkcs1 padding
Dear Emanuele,
it would be nice, if you could provide some more information about the
card you are working on. What I'm interested in is: If there are keys on
the card which are usable for signing but not for decrypting or vice
versa (in context of pkcs11/15)? And if so, is the pkcs1 padding for
t
On Wed, Jul 21, 2010 at 13:44, Martin Paljak wrote:
> Reading the code it all feels hairy, the patchwork that sets the flags in
> pkcs15.c and the try-and-fail approach in card-cardos.c
> Stricter mapping of actual card and its capabilities to something like card
> flags and proper failing with
Hello,
On Jul 20, 2010, at 10:34 PM, Emanuele Pucciarelli wrote:
> here's a patch for Italian CNS support against the current trunk, this
> time without secure messaging. The plan is to reach a consensus on
> this version, then add Secure Messaging, building on Viktor's work.
OK.
> - in card-card
Hello,
here's a patch for Italian CNS support against the current trunk, this
time without secure messaging. The plan is to reach a consensus on
this version, then add Secure Messaging, building on Viktor's work.
There shouldn't be any thorny issues to deal with. The two outstanding
discussion po
