aboutsummaryrefslogtreecommitdiff
path: root/src/tool_getparam.c
diff options
context:
space:
mode:
authorDavid Woodhouse <dwmw2@infradead.org>2016-08-17 11:30:21 +0200
committerDaniel Stenberg <daniel@haxx.se>2016-08-17 11:35:16 +0200
commit01f69232b09edd118a238119a3294686d07a74b3 (patch)
tree6226ef9a9aa18e079b15bfb124958783cd3f195a /src/tool_getparam.c
parent667fcb04a6385f9e398d64f2073a76a6e0ad3ad6 (diff)
curl: allow "pkcs11:" prefix for client certificates
RFC7512 provides a standard method to reference certificates in PKCS#11 tokens, by means of a URI starting 'pkcs11:'. We're working on fixing various applications so that whenever they would have been able to use certificates from a file, users can simply insert a PKCS#11 URI instead and expect it to work. This expectation is now a part of the Fedora packaging guidelines, for example. This doesn't work with cURL because of the way that the colon is used to separate the certificate argument from the passphrase. So instead of curl -E 'pkcs11:manufacturer=piv_II;id=%01' … I instead need to invoke cURL with the colon escaped, like this: curl -E 'pkcs11\:manufacturer=piv_II;id=%01' … This is suboptimal because we want *consistency* — the URI should be usable in place of a filename anywhere, without having strange differences for different applications. This patch therefore disables the processing in parse_cert_parameter() when the string starts with 'pkcs11:'. It means you can't pass a passphrase with an unescaped PKCS#11 URI, but there's no need to do so because RFC7512 allows a PIN to be given as a 'pin-value' attribute in the URI itself. Also, if users are already using RFC7512 URIs with the colon escaped as in the above example — even providing a passphrase for cURL to handling instead of using a pin-value attribute, that will continue to work because their string will start 'pkcs11\:' and won't match the check. What *does* break with this patch is the extremely unlikely case that a user has a file which is in the local directory and literally named just "pkcs11", and they have a passphrase on it. If that ever happened, the user would need to refer to it as './pkcs11:<passphrase>' instead.
Diffstat (limited to 'src/tool_getparam.c')
-rw-r--r--src/tool_getparam.c7
1 files changed, 5 insertions, 2 deletions
diff --git a/src/tool_getparam.c b/src/tool_getparam.c
index d60e04c82..e49acf803 100644
--- a/src/tool_getparam.c
+++ b/src/tool_getparam.c
@@ -301,9 +301,12 @@ void parse_cert_parameter(const char *cert_parameter,
if(param_length == 0)
return;
- /* next less trivial: cert_parameter contains no colon nor backslash; this
+ /* next less trivial: cert_parameter starts 'pkcs11:' and thus
+ * looks like a RFC7512 PKCS#11 URI which can be used as-is.
+ * Also if cert_parameter contains no colon nor backslash, this
* means no passphrase was given and no characters escaped */
- if(!strpbrk(cert_parameter, ":\\")) {
+ if(!strncmp(cert_parameter, "pkcs11:", 7) ||
+ !strpbrk(cert_parameter, ":\\")) {
*certname = strdup(cert_parameter);
return;
}