On Wed, Jun 15, 2011 at 2:05 PM, Martin Paljak <mar...@martinpaljak.net> wrote: > Given that in practice, CKA_ALWAYS_AUTHENTICATE is almost exclusively used > with nonrepudiation signature keys and the fact that the usual creation of > such keys through PKCS#11 is not a common operation, it sounds like a useful > signaling channel.
I disagree of the above statement. "practice" is not related to this. I use my authentication certificate as always authenticate... And I guess people also use this for decryption... It has nothing to do with legal, but for people customization and paranoia. So a much cleaner solution would be to use vendor provided attribute. >> Anyway, as there is no 1:1 PKCS#11->PKCS#15 we just defer the problem >> to the next missing attribute. > Which one do you see could be the next one? > > >> Dropping the PKCS#15 interface (libopensc) in favor of PKCS#11 limits >> the functionality (enroll process). >> >> In order to make it simpler, maybe single vendor attribute of >> CKA_OPENSC_PKCS15_ATTRS should be added, with name=value;name=value; >> format, so without changing the interface people will be able to >> specify PKCS#15 attributes during enroll process. > > You mean admitting that PKCS#11 is limited and making the PKCS#11 > personalization mechanism more flexible by endorsing more properties to > templates? I don't think it fixes the fundamental issue, that personalization > really does not seem to be in the focus of PKCS#11... Right... so either we open libopensc again to allow personalization directly with PKCS#15 as it was before, or we provide some bridge between the two. As most enrollment applications are card specific, A good enrollment application should be in control of every aspect of the card. Making sure that every byte on card is in place. So if you have PKCS#15 card, you probably need to create proper PKCS#15 filesystem directly. Using PKCS#11 for generic type card is good enough as long as you can bear the limitation of abstraction. And OpenSC has few of them... PKCS#11->PKCS#15->proprietary So if it is important that OpenSC's PKCS#11 interface enables to be used for card specific enrollments, we need to expose the PKCS#15 filesystem via the PKCS#11, this is a different ball game. Alon. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
