> 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.

Any thoughts on this?

-- 
dwmw2
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html