On Fri, Apr 23, 2010 at 10:25:41AM +0100, Darren J Moffat wrote: > >Why should metaslot pretend to have a token with a token label that's > >different from the metslot keystore's token label?? > > It hides the real name of the token because it isn't that token it > is a merge of other things, take the example of the metaslot token > being the SCA-6000 card, we don't want metaslot to lie and say it is > the SCA-6000 card because then it would be saying it is a hardware > slot which it isn't (it is a combination of things).
I can understand changing the manufacturer label, but changing the token label is much more disruptive. Some multi-slot aware applications may want to match tokens by token label (e.g., pam_pkcs11, the PKINIT pre-auth plugin), but if the token they are looking for is the metaslot token, and its label has been replaced, then they can't match it. > Metaslot is not actually don't anything a PKCS#11 app can't do for > itself (it does it with exactly the same APIs too). Right. > We could have done things differently and had alternate designs > about where the software token object key store were "attached". But this is not just about softtoken. What I have in mind though is specifically about softtoken: one that maps multiple distinct softtokens to slot IDs and sets the token label of each token to be the path of the actual softtoken. If we had such a feature then the metaslot's clobbering of the token label string would get obnoxious. Nico -- _______________________________________________ crypto-discuss mailing list crypto-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/crypto-discuss
