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?
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.
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.
Adding Nikos to CC, since he can also add some insight.
Regards,
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.
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.
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.
regards, Nikos
On Mon, Dec 5, 2016 at 3:00 AM, Nikos Mavrogiannopoulos nmav@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.
On Mon, 2016-12-05 at 10:23 -0500, Nathaniel McCallum wrote:
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.
You forgot to attach it :)
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.
opensc-pkcs11 is an alternative driver for the same hardware, the same as ykcs11. As it is now, it seems that opensc misses only the generation part, and I think it would be preferable to pointing yubico in adding that functionality in opensc, rather than shipping a separate driver in fedora.
regards, Nikos
On Mon, Dec 5, 2016 at 10:35 AM, Nikos Mavrogiannopoulos nmav@redhat.com wrote:
On Mon, 2016-12-05 at 10:23 -0500, Nathaniel McCallum wrote:
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.
You forgot to attach it :)
Let's try again. :)
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.
opensc-pkcs11 is an alternative driver for the same hardware, the same as ykcs11. As it is now, it seems that opensc misses only the generation part, and I think it would be preferable to pointing yubico in adding that functionality in opensc, rather than shipping a separate driver in fedora.
I agree. However, I suspect that the two drivers are using two different hardware interfaces. And I suspect that YubiKeys may not implement key creation through the SC hardware interface. I may misunderstand this. Corrections are welcome.
If key creation is only supported by a proprietary YubiKey interface, then I'm not sure we have much choice but to support two drivers (one for the SC interface, one for the YK interface).
We should note that we are already shipping two drivers and what we need to do now is define the relationship between them.
On 12/05/2016 04:44 PM, Nathaniel McCallum wrote:
On Mon, Dec 5, 2016 at 10:35 AM, Nikos Mavrogiannopoulos nmav@redhat.com wrote:
On Mon, 2016-12-05 at 10:23 -0500, Nathaniel McCallum wrote:
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.
You forgot to attach it :)
Let's try again. :)
I suspect the problem is related to the issue #98 on github [1] already fixed in git, but not yet released. The PKCS#11 module returns a very weird results at this point:
239: C_GetSlotList 2016-12-06 13:15:19.158 [in] tokenPresent = 0x1 [out] pSlotList: Slot 0 Slot -1 [...garbage values ...] [out] *pulCount = 0x30 Returned: 0 CKR_OK
I would pull the module to p11-kit no earlier than this will get fixed.
Also the duplicate keys might be related to the issue #101 [2]. The returned values might be really different objects, bug Yubico is unable to get the serial from them. This module might be good enough for yubico-piv-tool, but I am not sure if for other use cases (p11-kit and system-wide querying).
[1] https://github.com/Yubico/yubico-piv-tool/issues/98 [2] https://github.com/Yubico/yubico-piv-tool/issues/101
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.
opensc-pkcs11 is an alternative driver for the same hardware, the same as ykcs11. As it is now, it seems that opensc misses only the generation part, and I think it would be preferable to pointing yubico in adding that functionality in opensc, rather than shipping a separate driver in fedora.
I agree. However, I suspect that the two drivers are using two different hardware interfaces. And I suspect that YubiKeys may not implement key creation through the SC hardware interface. I may misunderstand this. Corrections are welcome.
This is a good point. I am not so knowledgable about the details, but it is possible that it might not be possible using SC.
About the OpenSC and key generation with PIV, I checked the OpenSC source and this method is really not implemented. Asking yubico for clarification would certainly make sense. Do you have some good contacts, or should I just drop a mail/issue on github?
Kind regards,
On Tue, 2016-12-06 at 13:44 +0100, Jakub Jelen wrote:
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.
You forgot to attach it :)
Let's try again. :)
I suspect the problem is related to the issue #98 on github [1] already fixed in git, but not yet released. The PKCS#11 module returns a very weird results at this point:
239: C_GetSlotList 2016-12-06 13:15:19.158 [in] tokenPresent = 0x1 [out] pSlotList: Slot 0 Slot -1 [...garbage values ...] [out] *pulCount = 0x30 Returned: 0 CKR_OK
I would pull the module to p11-kit no earlier than this will get fixed.
Also the duplicate keys might be related to the issue #101 [2]. The returned values might be really different objects, bug Yubico is unable to get the serial from them. This module might be good enough for yubico-piv-tool, but I am not sure if for other use cases (p11-kit and system-wide querying).
It makes sense not to register incomplete or modules applicable to a single application (internal) system-wide. I've updated the proposed guidelines to say: "Any package in Fedora containing a PKCS#11 provider module, intended to be used outside this package, must be registered with p11-kit. " [0].
regards, Nikos
[0]. https://fedoraproject.org/wiki/PackagingDrafts/Pkcs11Support
On Mon, Dec 5, 2016 at 2:41 AM, Jakub Jelen jjelen@redhat.com 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.
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.
$ pkcs11-tool --module /usr/lib64/libykcs11.so.1 -l --login-type so -k --key-type EC:prime256v1 -d 1 --usage-sign Using slot 0 with a present token (0x0) Logging in to "YubiKey PIV". Please enter SO PIN: Key pair generated: Private Key Object; EC label: Private key for Card Authentication ID: 01 Usage: sign Public Key Object; EC EC_POINT 256 bits EC_POINT: 04410434d393db4a9ba3ca022404e3f887fa98d3b1d9e35c2d4b901bf62b31bfecd3beee4919b310c02677edac6eef482fd2881f5fae0ac61d3765ef5b6c390221a4ab EC_PARAMS: 06082a8648ce3d030107 label: Public key for Card Authentication ID: 01 Usage: verify
$ pkcs11-tool --module /usr/lib64/opensc-pkcs11.so -l --login-type so -k --key-type EC:prime256v1 -d 1 --usage-sign Using slot 0 with a present token (0x0) Logging in to "PIV_II (PIV Card Holder pin)". Please enter SO PIN: error: PKCS11 function C_Login failed: rv = CKR_ARGUMENTS_BAD (0x7)
$ pkcs11-tool --module /usr/lib64/opensc-pkcs11.so -l --login-type so -k Using slot 0 with a present token (0x0) Logging in to "PIV_II (PIV Card Holder pin)". Please enter SO PIN: error: PKCS11 function C_Login failed: rv = CKR_ARGUMENTS_BAD (0x7)
$ pkcs11-tool --module /usr/lib64/opensc-pkcs11.so -l -k --key-type EC:prime256v1 -d 1 --usage-sign Using slot 0 with a present token (0x0) Logging in to "PIV_II (PIV Card Holder pin)". Please enter User PIN: error: Generate EC key mechanism not supported
$ pkcs11-tool --module /usr/lib64/opensc-pkcs11.so -l -k Using slot 0 with a present token (0x0) Logging in to "PIV_II (PIV Card Holder pin)". Please enter User PIN: error: PKCS11 function C_GenerateKeyPair failed: rv = CKR_FUNCTION_NOT_SUPPORTED (0x54)
On 03.12.2016 13:50, 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?
p11-kit doesn't look hopefully across the whole system looking for possible PKCS#11 modules :D
There's a drop in file that helps p11-kit find it:
https://p11-glue.freedesktop.org/doc/p11-kit/pkcs11-conf.html
Typically these drop in files are distributed along with the module in an RPM or Deb file. So that may be your first stop for filing a bug: The package in the distro you're using that shipped the above .so file.
Hope that makes sense,
Stef