Jan Iven wrote:
> A generic 'command line
> interface' to the reader over tty would be broken at the first program that
> doesn't understand the special tty stuff.
Good point...
> Right. However, I believe that a resource manager with only local entry points
> is still needed. Any kind of connectivity by net opens up a lot of attack
> possibilities; if really needed, these could be put into some userland
> process.
On the system diagram in the specs, it shows that applications can
access the
resource manager directly. So in a network environment a resource
manager with
only local connections does not match the spec. However, they do
reserve the
use of App/Resource Manager communication to "very specific uses of IFDs
or ICCs,
such as personalization systems", which is vague at best.
On reading the brief paragraph in 2.2 of part 7, which explains the
intent of the design, about the generality of IFDs from different
manufacturers
and their interchangability, etc, I don't see a clean way to put the
resource
manager directly into the kernel, i.e. you add an IFD and it will work
*without*
resource manager changes. Keep in mind I said "clean way". I'm not
saying it
couldn't be done, and I'm certainly not saying it shouldn't be done, but
I still
tend to favor a daemon resource manager as a cleaner way to accomplish
the same
thing.
I also can envision situations where a single resource manager might
want to
control access to multiple IFDs which are not necessarily on the same
machine.
Granted, you would want to make *darn* sure you have a secure network
for this.
But applications like smart card-aware shopping mall kiosks would likely
fit
into this category. The PC/SC spec gives one "resource manager" per
"system".
The question would then be, "does the term system refer to a single
machine,
or does it refer to an entire network"?
I would venture to say if a strong case could be made for having a
resource
manager with only local connections, then we would have grounds for
asking the
PC/SC Workgroup to address this in their spec with a component in their
diagram which functions as a "forwarder" between the resource manager
and the
application in cases where it would be necessary... This forwarder
would then
add the necessary authentication and encryption of sensitive data which
you
were talking about. After all, they claim that the spec is an "enabling
technology for network commerce" in "a very diverse set of markets" in
their
intro document...
Another question I have is has anyone seen how Microsoft implemented the
resource
manager for NT? If it is network-aware, then I would venture to say
that so
should this one be. Since then it would be conceivable for a Linux box
to
operate as a "client" under an MS resource manager running on NT, or
vice-versa.
It would also be nice to spend the most time on code that would be
portable to
other Unixes. Not necessary, but definately nice... Does anyone know
whether
Sun is on the member roster for Java reasons or because they will be
supporting
PC/SC on their OS? Also, HP... I wonder how they've done the
implementation,
if that's indeed what they're doing...
Sorry about the length here... I didn't mean to spend so much time on
this
since I've got some chores to catch up on tonight. I hope I'm not
repeating
discussion that's already been discussed. Let me know what you all
think...
Regards,
Mark
***************************************************************
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***************************************************************
