ssl: Set engine implicitly when a PKCS#11 URI is provided #2333
This allows the use of PKCS#11 URI (RFC 7512) for certificates and keys without setting the corresponding type as "ENG" explicitly. If a PKCS#11 URI is provided for certificate, key, proxy_certificate, or proxy_key, the corresponding type is set as "ENG" when not provided explicitly.
If OpenSSL is used as the cryptographic library and a PKCS#11 URI is provided, the engine is set to "pkcs11" when not provided explicitly. This uses the engine_pkcs11 engine (https://github.com/OpenSC/libp11).
A test script can be found here:
The test uses GnuTLS as the test server and SoftHSM as the PKCS#11 device.
This is related with #974
I don't like how this code adds 6(!) (separate) string comparisons for "pkcs11:". It adds multiple code chunks that look almost identical but they are not. I'm not sure what the fix for this is, but can we think of a nicer way to do this?
Also, should the string check really require the string to be lowercase or should it be done case insensitively?
Sure, we can try to find the best way. It is possible to write a function to check if a given string is a PKCS#11 URI and at least make a single base code. But it will do the string comparison in the same way. And since different parameters can be independently provided as PKCS#11 URI, I believe that there is no other way than doing it many times in the almost identical way. That would result in substituting the lines:
But the other lines will remain the same. This would (potentially) add a function call overhead in exchange for the unified location for the check. Do you have any suggestion to improve this?
According to RFC 7512, yes, it must be lowercase.
Where does it say that? It refers to the string being a URI and "pkcs11" being a URI scheme. URIs are defined by RFC 3986 which says:
RFC 4395 in turn defines how to register URI schemes and it says:
You are right, I was not aware about it. Thank you, I will be more careful with my affirmations.
It seems it have to be fixed in tool_getparam.c, line 340, too.
I will use the functions provided in
And I do not like the way I did, duplicating the
referenced this pull request
Mar 16, 2018
That patch looks like a good way forward in two aspects
Bottom line, it would be great if that would be merged!