OK. I think we have all facts. Thanks.
On Thu, Jun 16, 2011 at 1:14 PM, Martin Paljak <mar...@martinpaljak.net> wrote: > > 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
