Henryk Plötz wrote:
Moin,
Am Sun, 24 Sep 2006 17:38:58 +0200 schrieb Nils Larsch:
this is certainly not a fix, more a workaround around a problem in
our pkcs15 handling. I'm not really happy with it as our internal
representation of the on-card pkcs15 structure doesn't reflect what's
actually on the card (with the consequence that if we read something
from the card and write it back the new object will be different).
It might be better to make the path absolute just before it's actually
used (if this is doable).
I doubt that it's possible to find and fix every single usage of these
paths (if this was an object oriented programming language with getter
methods instead that would have been easy).
well it would have been easy if every pkcs15 function would leave
the card in well defined state (for example: the selected DF is
always the application DF) but with the current code I agree that
it would be challenging (btw: I didn't veto the approach of making
all path absolute after parsing, I just wanted to ask whether the
other approach has been tried).
Instead we would need to
store two different values: the absolute path for our own usage, and the
original path for writing. There are only few places in the code that
actually write path information, so that would be possible.
using two path variables adds some complexity and I'm not sure if
we really want this. I think as a temporary solution it's ok to
make the paths absolute after parsing.
But then again: We don't have code to write to these cards anyway. I'm
not sure: Is there any support for writing cards that were not
formatted with opensc at all?
currently not
Paths written by opensc are always
absolute.
if we do this in a not cardos (or HiPath) specific code section
we would need to test everytime we try to generate a signature,
not really elegant.
I thought about having a flag somewhere. First try the regular approach
and if that did not work try the encrypt-workaround. If that worked
then set the flag and go straight to the encrypt-workaround in the
future.
As we know that HiPath cards use the
decryption operation for signing (always ?) we could try to
utilize the pkcs15 emulation driver for this ...
I'm not too familiar with that code. Would that be easier?
As I've just learned that there's an even better way: pkcs15
offers the possibility to specify which mechanism should be
used for a specific key but and the Siemens software sets this
information. Unfortunately opensc currently doesn't support parsing
this information (and afaik the asn.1 code needs to be extended to
support parsing this). I will look at it to find out what needs
to be changed.
what about replacing the "do {] while();" loop with a "while() {}"
loop ?
I just assumed that there must have been a reason to do {} while(); in
the first place and did not want to mess with it.
from a quick look I don't see a reason why we shouldn't use
a simple while loop
Cheers,
Nils
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
