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). 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.
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? 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?
> 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.
> we already have a function to concatenate to paths
> (sc_concatenate_path()) and it should be used here
sc_concatenate_path has/had slightly different semantics: it zeroized
index and count of the resultant path, which would lead to errors if
the PKCS#15 structure specified an offset.
I see that you recently changed this, so ok, sc_concatenate_path might
now be used.
--
Henryk Plötz
Grüße aus Berlin
~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~
~ Help Microsoft fight software piracy: Give Linux to a friend today! ~
pgpwku84ls6Yy.pgp
Description: PGP signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
