Hello,
On Sun, May 27, 2012 at 11:18 PM, Peter Marschall <pe...@adpm.de> wrote:
> Hi,
>
> On Friday, 25. May 2012, Martin Paljak wrote:
>
>> In the long run, I don't think that it helps to emulate a filesystem
>> on top of non-filesystem cards (like OpenPGP or Muscle). Or to try to
>> make it fit into the filesystem-oriented stack of OpenSC.
> Why?
> If it works (even in a limited/restricted way), it is better than not having
> any support at all.
Sure. If this can be accomplished without changing the underlying
mechanics/assumptions, perfect.
I'm just trying to point out that it could be useful and more
straightforward to change some of the assumptions in OpenSC, like the
fact that there *must* be a filesystem or that key-generation *must*
go through pkcs#15 data structure generation layer.
>> It is nice to be able to poke around with opensc-explorer, but the
>> notion of a file and a path should mean that the file is actually
>> selectable with ISO SELECT command. Which is not true (a plain APDU,
>> outside of the libopensc emulation layer, would fail).
> I do not understand that argument, especially if we're talking about
> an emulation within the opensc software stack.
> Why should it matter that the emulation does not exist outside opensc?
> When it works (even only partiallly) with opensc, it works.
> When it does not work with opensc it works nowhere.
This not a problem for OpenPGP, really, as nothing is written to the
card that would actually contain the fake paths. But more of a problem
of Muscle applet (that does pump PKCS#15 data back to the card)
The common (related) traits are:
- emulating a filesystem that doesn't actually exist (OK if the
emulation is only present to "please" existing OpenSC design)
- wanting to "write something" to the card, with pkcs15-init, even if
that's probably not the best option (as no PKCS#15 ASN.1 is
generated/written)
Which brings the two thoughts:
- emulating a filesystem should not be a requirement if possible, as
it leaves a false assumption to some users (who expect a file to also
be present on the card). But of course, it is a nice to have feature
(opensc-explorer etc).
- re-generating/importing keys and re-loading certificates must not
be made under the "pkcs15init" section, as this may not result in
PKCS#15 related updates in the card.
So, instead of requiring an additional mapper in src/pkcs15init, I'd
propose to extend the pkcs15-ish API in src/libopensc to include
"generate object" and/or "put object" calls, to (re-)generate keys,
import keys and reload certificates.
Something like:
sc_pkcs15_change_object(card, object_type, object_id, new_object, flags)
and related callback in sc_pkcs15_operations.
Which could be implemented entirely in src/libopensc/(card/pkcs15) name.c
>> In case of OpenPGP, where no files or PKCS#15 data structures are
>> written to the card (the card already has a fixed profile, with fixed
>> data slots), it makes no sense. The main utility of pkcs15-init is
>> creating (and storing) PKCS#15 ASN.1 structures to the card, when such
>> slots for keys or certificates are created as a side-product. If ASN.
>> shall not be created, pcks15-init should IMHO not be used.
> Well, pkcs15-init might not be the tool suitable for the job.
> But please, let Quân continue trying - maybe he can make the emulation work.
That's not my intention, of course :)
> If his approach ("try to make the emulation so good that it allows using the
> standard tools") does not work out, extending the new openpgp-tool to do what
> he wants, should be even easier.
Probably. Some operations (like setting the account names and other
data objects) do not fit nicely anywhere else.
Martin
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
