feat: Key selection using PKCS #11 URI

Signed-off-by: Marcel Guzik <marcel.guzik@cumulocity.com>

Signed-off-by: Marcel Guzik <marcel.guzik@cumulocity.com>

Parse "pin-value" query attribute if it's present in a PKCS 11 URI.

RFC7512 specifies a "pin-value" query attribute that can be used to
provide the PIN value, which we can use to pass it in the request.

Because it is sensitive, there are security considerations, of interest
to us being this part of the RFC:

> Section 7.5 of [RFC3986] applies since a PKCS #11 URI may be used in
> world-readable command-line arguments to run applications, stored in
> public configuration files, or otherwise used in clear text.  For
> that reason, the "pin-value" attribute should only be used if the URI
> string itself is protected with the same level of security as the
> token PIN itself otherwise is.

In our case, the challenge is in not showing up these values in the
logs. On tedge-p11-server side as soon as we're parsing URI we can put
in in a secrecy wrapper, to not be able to print it from then on, but
there's nothing preventing printing the value before it's parsed on the
server, or on the client making the request.

Signed-off-by: Marcel Guzik <marcel.guzik@cumulocity.com>

Allows the user to provide a PIN value to be used when logging into
PKCS11 token as a query attribute in the URI, e.g. when the following
value is set as `device.key_uri`:

pkcs11:token=mytoken;object=mykey?pin-value=my-pin

tedge-p11-server will attempt to login to the token using `my-pin`
instead of the default PIN tedge-p11-server was started with.

Because it is sensitive, there are security considerations, of interest
to us being this part of the RFC:

> Section 7.5 of [RFC3986] applies since a PKCS #11 URI may be used in
> world-readable command-line arguments to run applications, stored in
> public configuration files, or otherwise used in clear text.  For
> that reason, the "pin-value" attribute should only be used if the URI
> string itself is protected with the same level of security as the
> token PIN itself otherwise is.

In our case, the challenge is in not showing up these values in the
logs. On tedge-p11-server side as soon as we're parsing URI we can put
in in a secrecy wrapper, to not be able to print it from then on, but
there's nothing preventing printing the value before it's parsed on the
server, or on the client making the request.

Signed-off-by: Marcel Guzik <marcel.guzik@cumulocity.com>

Parse "pin-value" query attribute if it's present in a PKCS 11 URI.

RFC7512 specifies a "pin-value" query attribute that can be used to
provide the PIN value, which we can use to pass it in the request.

Because it is sensitive, there are security considerations, of interest
to us being this part of the RFC:

> Section 7.5 of [RFC3986] applies since a PKCS #11 URI may be used in
> world-readable command-line arguments to run applications, stored in
> public configuration files, or otherwise used in clear text.  For
> that reason, the "pin-value" attribute should only be used if the URI
> string itself is protected with the same level of security as the
> token PIN itself otherwise is.

In our case, the challenge is in not showing up these values in the
logs. On tedge-p11-server side as soon as we're parsing URI we can put
in in a secrecy wrapper, to not be able to print it from then on, but
there's nothing preventing printing the value before it's parsed on the
server, or on the client making the request.

Signed-off-by: Marcel Guzik <marcel.guzik@cumulocity.com>

Allows the user to provide a PIN value to be used when logging into
PKCS11 token as a query attribute in the URI, e.g. when the following
value is set as `device.key_uri`:

pkcs11:token=mytoken;object=mykey?pin-value=my-pin

tedge-p11-server will attempt to login to the token using `my-pin`
instead of the default PIN tedge-p11-server was started with.

Because it is sensitive, there are security considerations, of interest
to us being this part of the RFC:

> Section 7.5 of [RFC3986] applies since a PKCS #11 URI may be used in
> world-readable command-line arguments to run applications, stored in
> public configuration files, or otherwise used in clear text.  For
> that reason, the "pin-value" attribute should only be used if the URI
> string itself is protected with the same level of security as the
> token PIN itself otherwise is.

In our case, the challenge is in not showing up these values in the
logs. On tedge-p11-server side as soon as we're parsing URI we can put
in in a secrecy wrapper, to not be able to print it from then on, but
there's nothing preventing printing the value before it's parsed on the
server, or on the client making the request.

Signed-off-by: Marcel Guzik <marcel.guzik@cumulocity.com>

Parse "pin-value" query attribute if it's present in a PKCS 11 URI.

RFC7512 specifies a "pin-value" query attribute that can be used to
provide the PIN value, which we can use to pass it in the request.

Because it is sensitive, there are security considerations, of interest
to us being this part of the RFC:

> Section 7.5 of [RFC3986] applies since a PKCS #11 URI may be used in
> world-readable command-line arguments to run applications, stored in
> public configuration files, or otherwise used in clear text.  For
> that reason, the "pin-value" attribute should only be used if the URI
> string itself is protected with the same level of security as the
> token PIN itself otherwise is.

In our case, the challenge is in not showing up these values in the
logs. On tedge-p11-server side as soon as we're parsing URI we can put
in in a secrecy wrapper, to not be able to print it from then on, but
there's nothing preventing printing the value before it's parsed on the
server, or on the client making the request.

Signed-off-by: Marcel Guzik <marcel.guzik@cumulocity.com>

Allows the user to provide a PIN value to be used when logging into
PKCS11 token as a query attribute in the URI, e.g. when the following
value is set as `device.key_uri`:

pkcs11:token=mytoken;object=mykey?pin-value=my-pin

tedge-p11-server will attempt to login to the token using `my-pin`
instead of the default PIN tedge-p11-server was started with.

Because it is sensitive, there are security considerations, of interest
to us being this part of the RFC:

> Section 7.5 of [RFC3986] applies since a PKCS #11 URI may be used in
> world-readable command-line arguments to run applications, stored in
> public configuration files, or otherwise used in clear text.  For
> that reason, the "pin-value" attribute should only be used if the URI
> string itself is protected with the same level of security as the
> token PIN itself otherwise is.

In our case, the challenge is in not showing up these values in the
logs. On tedge-p11-server side as soon as we're parsing URI we can put
in in a secrecy wrapper, to not be able to print it from then on, but
there's nothing preventing printing the value before it's parsed on the
server, or on the client making the request.

Signed-off-by: Marcel Guzik <marcel.guzik@cumulocity.com>