Closed dwmw2 closed 9 years ago
Hi,
Supporting both format is nice, but adding dependency of p11-kit is not something I agree to.
The pkcs11-helper should be minimal wrapper.
So if we can parse this within our code it will be great.
Thanks, Alon
I did consider that, as p11-kit is overkill for just parsing the URIs. However, p11-kit also offers another function — it allows co-ordination of loaded modules by multiple users in the same process, as described at http://p11-glue.freedesktop.org/doc/p11-kit/p11-kit-Modules.html
So although we're only using p11-kit for the URI parsing functionality at the moment, we probably do want to end up using it for loading modules (and for finding the system-configured modules so that the application doesn't have to specify them manually). That's why I was happy to add the p11-kit dependency.
Not at all, I do not want p11-kit dependency at all. If you find it useful, please use it instead.
As far as I understand pkcs11-helper can load p11-kit that proxy to multiple provider if so required, but this is not required as pkcs11-helper already capable of doing so.
pkcs11-helper is much simpler and comfort to minimal low level PKCS#11 operation.
Ok, I'll look at reimplementing the PKCS#11 URI parsing internally instead of using p11-kit for that.
I don't seem to be able to reopen this having rebased the tree; I'll open a new pull request.
This migrates the serialization format to conform to the PKCS#11 URI scheme as described at https://tools.ietf.org/html/draft-pechanec-pkcs11uri-16
The old form is still recognised for compatibility, but standard PKCS#11 URIs are now generated and accepted. Testing with OpenVPN now gives me the following output:
... and the PKCS#11 URI thus generated is also usable with the
--pkcs11-id
option.