Hello, On Jun 15, 2011, at 12:22 , Alon Bar-Lev wrote: > On Wed, Jun 15, 2011 at 12:14 PM, Viktor Tarasov > <viktor.tara...@gmail.com> wrote: >> Douglas proposed to associate the CKA_ALWAYS_AUTHENTICATE together with >> CKA_SIGN attributes on the PKCS#11 side, >> with the 'nonRepudiation' flags on the PKCS#15 side. >> Imho, it's legitimate solution -- 'ALWAYS_AUTHENTICATE' is quite close to >> the 'nonRepudiation'. > > It is not the same. Better is the vendor attribute, no guessing or > ugly mapping is required. I feel this is a suitable "church in the middle of the village" solution (a rough translation of an Estonian proverb about the selection process for the church location).
The problem as I see it is how a certain proprietary application is talking to a proprietary PKCS#11 module to direct a process in case of a previously known piece of hardware (the card driver that will interpret the input from the application when generating the key). 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 see it as a point-to-point communication issue, where the target is to enable understanding each other to the finest detail without modifying the protocol. This solution seems to fix it. Card capabilities and corresponding drivers anyway vary in features and capabilities, making sure that templates are strictly checked, actually written to the card and "bad ones" get rejected would probably be an additional task... > 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... Best, Martin -- @MartinPaljak.net +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
