Nils Larsch wrote:
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).
we would need to store two values instead of one: the non-absolute value
and from where we got it, so we can combine this to create an absolute
path. storing two values instead of one will break at least our ABI
compatibility I guess, as we need extra fields in data structures and
maybe more parameters to functions?
so sanitizing a path as soon as we got it from parsing some data looks
like a better way to me - from a very distant look I must admit.
also I wonder whan do we write something back to the card? ever?
99% of card usage is read only, so I wouldn't know any code outside
pkcs15init that changes data structures. pkcs15-init is currently
limited to cards initialized by opensc, right?
and if we want to have full read&write compatibility with other pkcs15
based software, then I wonder: if it is allowed to both have relative
and solute paths in some structure, wouldn't the other software be
required to work with what we write, too?
sure, of course the other software migh be buggy and in reality we
would need to work with it. but I seriously wonder if we want to try
this at all - haven't heard of anyone working towards that aim - and
if we wouldn't run into far bigger problems then absolute vs. relative
paths.
What's still missing is signing. Andreas suggested that using the
decryption routine for signing might be a common enough workaround to
be implemented in the general, non-cardos-specific code. Any opinions
on where the best place would be?
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. As we know that HiPath cards use the
decryption operation for signing (always ?) we could try to
utilize the pkcs15 emulation driver for this ...
henryks initial suggestion was to use the pkcs15 emulation too, so that
is ok for me too. or we can hack card-cardos sign function, which seems
to already try several different ways to sign some data anyway. but
rather than blindly try several options, if we have any good layer that
knows what kind of card / key we have, it might be much better to invoke
the right function right from the start.
no idea if other card operating systems will ever need a similar hack
like, if yes then some generic code might me good. if not, any specific
code is fine, too.
Index: src/libopensc/pkcs15.c
===================================================================
--- src/libopensc/pkcs15.c (revision 2789)
+++ src/libopensc/pkcs15.c (working copy)
...
+ if (r <= 2)
+ break;
+ memmove(head,head+2,r-2);
+ head += (r-2);
+ }
we might want to check here if the first two bytes
are the number of the record and the (length -2).
that is a tag/length that isn't needed as far as I know
and needs to be stripped so our internal code works.
but other implementation will maybe not have such an
tl-header before the real content.
if (head[0] == n && head[1] == (r-2)) {
/* strip extra siemens hipath header */
...
} else {
head+=r;
}
or something should work.
anyway, thanks a lot for all the work henryk. compatibility with other
pkcs#15 libs is very important I think, and this issue has been unsolved
for a long time. so working on a fix is a step into the right direction.
Regards, Andreas
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
