Hello,
On Tue, May 10, 2011 at 17:29, Giuliano Bertoletti <g...@symbolic.it> wrote:
> Despite the fact that slots can (in certain tokens) be added or removed
> by the administrator, such person is supposed to have complete control
> over what happens.
I would remind that PKCS#11 is a software API. I don't think that an
out of context administrator makes sense, PKCS#11 does not care what
the administrator does or does not, it is an API to describe and
access "what is there".
PKCS#11 tries to be a universal abstraction. It does not address
everything, as can be read from the specification itself (".. is
outside the scope of Cryptoki ...").
I thus agree with Nikos, that applications making use of cryptography
and using PKCS#11 for implementation should not expose API
implementation details in an ideal world. It should either present
"meaningful" keys/certificates or "containers" for storing new things.
The fact that those containers or keys come from a "token" in a "slot"
in PKCS#11 terms is secondary.
As long as PKCS#11 couples a single slot with a single labelled
authentication mechanism (admin token slot on an HSM or a PIN code for
smart cards) the relation between a slot and a device is even more
weird, IMHO.
> In other words, slots are something that both, pkcs#11 and hardware
> token expose and, most importantly, are something the user understands
> (practically speaking they're the model upon which the pkcs#11 is built).
>
> On the contrary, Slot_IDs are meant to be used only internally by the
> application and pkcs#11 library.
> They should never be exposed externally to the user much the same as you
> wouldn't present to the user the value of a pointer or expect him to set it.
>
> However you're absolutely right when you say that finding the slot by
> slot description (or better the token by token description) is the
> safest way to locate the proper container where crypto material is held.
Thus both slot indexes are wrong and slot ID-s are wrong. But indexes
seem to be "less wrong" than plain ID-s.
A patch that improves, documents and cleans up related engine_pkcs11
code is as always most welcome.
Cheers,
Martin
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
