Hello, On Wed, Jun 15, 2011 at 14:28, Alon Bar-Lev <alon.bar...@gmail.com> wrote: > 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.
Yes and no. OpenSC does a lot of translation. It translates non-ISO7816-4-ish commands to generic functions that are expected to "behave like ISO7816-X" to enable the PKCS#15 support (card drivers). It translates non-PKCS#15 cards into PKCS#15 terms (PKCS#15 emulation code), because that's what is used internally by OpenSC (whether it is the best or most optional abstraction is another question). It translates PKCS#15 into PKCS#11, because that is what applications want. It also translates PKCS#15 to Tokend/CDSA or CryptoAPI. Because there are so many layer in the real life PKI world, it is a nightmare. As always with translation - something gets lost and something gets added by the translator. But the goal of the translator is to be as exact and as close to the original as possible, but adopt the sentence so that it makes sense to the target audience. Like proverbs - you either translate them word by word (like I did) or you use an equivalent which is known to the native speakers of the target language in the given locality. PKCS#11 and CryptoAPI are not "just another interfaces", they have different design philosophies and goals. It does not make sense to try to extend the PKCS#15 world to CryptoAPI or implement everything in PKCS#15 layer with only CryptoAPI usage in mind. Rather the best effort to translate in the spirit of target audience should be done (both directions) CKA_ALWAYS_AUTHENTICATE is a property of PKCS#11 which is most similar to userConsent property in PKCS#15. Disregarding the properties, eventually the actual card should behave like advertised. Do all card drivers support (and enforce) "authentication before signature" feature? I doubt it. Does OpenSC currently allow setting a configured userConsent value when generating keys? Will it be transferred to the card and enforced by the card? AFAIK not (at least not easily). What about userConsent > 1? Will we disregard CKA_ALWAYS_AUTHENTICATE, which implies userConsent==1? Yes, some of them are shortcomings in OpenSC (and drivers and cards) and some could be improved (like using userConsent value for PIN cache TTL) and having explicit attributes would be more precise, but it would often only support a low value corner case for maybe a few but maybe zero users. Current CKA_ALWAYS_AUTHENTICATE (and related userConsent==1) relation comes from real life and has proven to be useful. DWIM is a powerful concept ;) >> 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. I don't think that libopensc was actually used (publicly) for personalization. The reason for removing libopensc-dev was to eliminate the "I need access to smart cards... google & find OpenSC, think 'this is some smart card think, I'll link against it'" habit. Up to the point of removing public headers, all users of libopensc should have either used PKCS#11, had already implemented PKCS#11 support or had the code to use libopensc long abandoned/not updated. The main reason of ditching development packages was to draw attention to the fact that libopensc is not the most appropriate interface for adding smart card support to enduser applications. Also, to get rid of the necessity to maintain a kitchen sink API and related ABI issues and focus on published API-s (PKCS#11, Minidriver, Tokend). If there was to become a new application which would focus on card *personalization* through libopensc, would help to sanitize the exported API of libopensc and work with that, it would be most welcome. But I don't know of any such effort or people who would be interested in it. Personalization is often a closed-group hobby or eagerly kept in house. > 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. True. Which means that pkcs15-init should be used. Or something comparable. > 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. True. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
