Hi Viktor,
I like the idea of adding secure messagin!
but in general: I think it would be nice to be able to
encrypt all communication. think of contactless smart
cards, I don't want data like the certificate go over
the air unencrypted for privacy reasons.
about the code: why add it as loadable module?
if you have cards where the secure messaging details are
under NDA that is ok. still it might be easier for all
of us if you had a private opensc version with that patched
in, rather than us loading modules.
also the patch adds a "sm" subdirectory, but does not include
any files in that dir. so we can't compile/test it. personally
I would prefer to keep all files in one directory (the
libopensc/ libpkcs15init split for example is something we now
regret, didn't get us much except complexity).
- secured APDUs are generated by some external SM_server (in my case
it's HTTPS server).
OpenSC access SM_server via the SM_module. SM_module to be used is
defined in opensc.conf
and is loaded during the sc_context initialization.
why that? if you want a server to send commands to the card, that could
be done much easier without using opensc on the client at all - a simple
openct or pcsc app could do that.
it is ok for you to do that, but I wonder if other people will want that
as well - whether it makes sence to have this in the generic code we ship?
Current trunk version of libopensc/card-oberthur.c contains (in comments)
the SM specific procedures.
Full patch (too voluminous for this mail)
contains SM_server tool to generate secured APDUs, and SM_module
implementations.
I guess for the general use it might be nicer to have everything build
into opensc, without external modules and external server. still if we
find a scenario where other people will want that too, we can think
of adding it. but normal users will not want to install a webserver
to initialized a oberthur card with secure messaging ...
we could merge a generic secure messaging into opensc, and offer the
webserver / rpc / ... code as patch in the contrib directory and see
if people want to use it? sure, would be extra work to maintain, but
I would prefer not to merge it till we get feedback (adds a lot of
complexity most people won't need).
can you put up a full diff somewhere? either post it to the list,
attach it to a new bug, or commit it to
https://www.opensc-project.org/svn/files/trunk/contrib
?
Thanks, Andreas
p.s. sorry for answering this late. currently I have next to no time for
opensc.
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
