Accept empty token fields

It's a limitation of the core pkcs11-helper token matching code that we
need to specify *all* of model=, token=, manufacturer= and serial=. This
was true of the legacy serialization format, so it isn't a regression.

At least it *wouldn't* have been, if we it had distinguished between an
*explicit* "model=" parameter, and the model not being specified at all.
Thus https://bugzilla.redhat.com/show_bug.cgi?id=2298882

The requirement for all four token fields to be specified does mean that
applications using pkcs11-helper aren't *quite* as versatile and user
friendly as something which implements the full search algorithm shown in
§8 of http://david.woodhou.se/draft-woodhouse-cert-best-practice.html by
first searching for the specified certificate in all tokens without a login,
then only logging into the token in which the *certificate* was found, to
access the key. But that's OK, and something we can improve on later. It's
not a barrier to using the RFC7512 URI format in place of the legacy
serialization format.

Author: dwmw2

lib/pkcs11h-serialization.c

@@ -261,6 +261,7 @@ __parse_pkcs11_uri (
 ) {
 	const char *end, *p;
 	CK_RV rv = CKR_OK;
+	unsigned int token_fields_found = 0;
 
 	_PKCS11H_ASSERT (token_id!=NULL);
 	_PKCS11H_ASSERT (sz!=NULL);
@@ -290,6 +291,7 @@ __parse_pkcs11_uri (
 					goto cleanup;
 				}
 
+				token_fields_found |= (1 << i);
 				goto matched;
 			}
 		}
@@ -327,8 +329,7 @@ __parse_pkcs11_uri (
 	 * *all* of manufacturer, model, serial and label attributes to be
 	 * defined. So reject partial URIs early instead of letting it do the
 	 * wrong thing. We can maybe improve this later. */
-	if (!token_id->model[0] || !token_id->label[0] ||
-	    !token_id->manufacturerID[0] || !token_id->serialNumber[0]) {
+	if (token_fields_found != 0xf) {
 		return CKR_ATTRIBUTE_VALUE_INVALID;
 	}