Code change:
empty "valueString" are included with an empty string as the component value. <del> If a parameter name occurs multiple times in a request, all parameter values of that name MUST be included in separate signature input lines in the order in which the parameters occur in the target URI. </del> <ins> If a query parameter is named as a covered component but it does not occur in the query parameters, this MUST cause an error in the signature input string generation. </ins> For example for the following request: Indicating the "baz", "qux" and "param" named query parameters in would result in the following "@query-param" value: <ins> If a parameter name occurs multiple times in a request, all parameter values of that name MUST be included in separate signature input lines in the order in which the parameters occur in the target URI. Note that in some implementations, the order of parsed query parameters is not stable, and this situation could lead to unexpected results.  If multiple parameters are common within an application, it is RECOMMENDED to sign the entire query string using the "@query" component identifier defined in content-request-query. </ins> If used in a related-response, the "@query-params" component identifier refers to the associated component value of the request that triggered the response message being signed.

Related discussion:
text: To support PKCS1 the developer has to depend on further less well tested libraries and add additional code (as I ) leading possibly to new bugs. Furthermore, I will need to go through the same process for JavaScript now, doubling the work. Since PKCS8 is as expressive as PKCS1 ( and see ), it would make life easier for devs if the keys were all in PKCS8 format. Unless there really is something that PKCS1 offers that PKCS8 does not? I will try doing this using the Web Crypto API next. But there we find that supports the PKCS format.
While I am at it. I am having trouble with verifying the signature for 3 out of 4 examples from the spec that I tried out in . Currently the only one that works is the . I am able to produce and verify a signature for , and examples, but the signatures don't correspond to what is in the spec. That may very well be a mistake in my code, which I am working on as a to bobcats scala and scala-js crypto library. But I just wanted to check how confident you were in your examples. I am going to re-implement next in JS, so that will give me another reference point.
I am working my way through this with JS. I was able to parse the and keys after translating them to pkcs8 format with openssl, but am having trouble importing in the console of Chrome, Chrome-beta, Chrome-Dev and Safari. I guess that is in pkcs8 format already. I don't have trouble parsing that key with BouncyCastle... I guess this is a little config problem, but it's difficult to work out what that could be... Perhaps someone has an idea?
NAME Since this all has to do with the examples in the text and not the spec itself, I think we'd be fine with having the keys in multiple formats if it's useful for developers. However I'll note that in many code libraries you need to add the PEM headers of and for their compliant parsers to parse an EC key in PEM format, for example. I've been able to parse these keys in both Java and Python, and in fact all the examples are generated using a python script: URL Also, note that RSA-PSS and ECDSA are non-deterministic signatures that incorporate a source of randomness into the signature calculation.