On Mon, Dec 5, 2016 at 3:00 AM, Nikos Mavrogiannopoulos <n...@redhat.com> wrote: > On Mon, 2016-12-05 at 08:41 +0100, Jakub Jelen wrote: >> On 12/03/2016 01:50 PM, Nathaniel McCallum wrote: >> > So apparently yubico-piv-tool ships $libdir/libykpkcs11.so*, but >> > this >> > doesn't get picked up by p11-kit by default. I suspect it has gone >> > unnoticed largely because for most crucial operations the opensc >> > module also works with Yubikeys. However, this is not true for all >> > operations (in particular, in my case, key creation). >> > >> > How can we make this happen? Is there some intentional reason >> > Yubico's >> > PKCS#11 module has been excluded? >> Hello, >> In case of the modules accessing the same hardware tokens, there is >> a problem that they shows up more times while listed by p11-kit. We >> had similar problem with opensc && coolkey once both of them worked >> with PIV cards. > > Indeed, in the case where one has both ykcs11 and opensc, he would have > to supply --detailed-urls to p11tool to be able to distinguish between > objects. That is, because they will have identical URLs except for the > library-description and library-manufacturer fields, which are not > normally printed. > > That would be a bit more than just inconvenience because of the > duplicate listings, it would be that if you don't specify the library > fields on the URL, you wouldn't know which module was used for the > operation.
They don't, in fact, have different URIs. If I add a .module file for ykcs11.so, I get the attached output for p11tool --list-tokens. Strangely, this shows the same yubikey 7 times (perhaps a bug?). Notice that token 6 and tokens 7-13 are in fact the same token. > On the other hand, if we have another pkcs11 module for yubikeys > shipped on a package, it seems natural to be included in the p11-kit > listings, and maybe it makes sense to make p11tool print the long URL > versions by default. I'd like to include ykcs11.so in the listings, but I don't think we need to enable the long URI versions since there is no overlap between opensc and ykcs11. >> Ideal solution would be to implement the PIV key creation in OpenSC >> (what exactly does not work with which yubikey?). We can't use only >> yubico module, since PIV is not only the yubico one. > > We should ping yubico on that. Is there some reason they didn't > implement the key generation on opensc? Ideally we won't ship that > additional module. I don't know. But I suspect it would require hardware change. There are a lot of existing YubiKeys out there. We should give our best effort to support them. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org