> 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
