Key Algorithm issues

[mariusor]

Hi again, :)

I'm having trouble deciding programmatically in the KeyResolver.ResolveKey() which Algorithm to use when the retrieved public key is RSA. The confusion likes between the signing methods PSS and PKCS#1 v1.5, as key sizes can be extracted from the key itself.

Currently most of the applications I interact with and send me signatures to verify, use PKCS#1 v1.5, but I would like to avoid making that assumption in code.

So here I am not being able to wrap my head around the why does the implementor need to explicitly decide which Algorithm needs to be used, when that information is usually available in the signature parameters found in Signature-Input, and especially when the two are not the same the signer returns an error.

So I'm wondering if there should be a way for the calling code to tell the verifier to try whichever algorithm is specified in the Signature-Input, and fail only if there wasn't one specified in both the signature parameters and Key.Algorithm?

Does this make sense to you?

[dadrus]

Hi. Sorry for the belated answer. I'm giving a training from yesterday until tomorrow eob, so not able to answer in time. Yeah, I know what you mean. Frankly speaking, this is a part of a project, I don't know how to address properly. An option, which I imagine could work, would making the Algorithm SignatureAlgorithm in the Key struct optional or kind of a hint. And internally, when it comes to signature verification, the implementation could derive the possible SignatureAlgorithm from the supplied key and use that. So, something like that:

func (v *verifier) verifySignature(
	msg *Message,
	signature []byte,
	params *signatureParameters,
	exp *expectations,
) error {
	base, err := params.toSignatureBase(msg)
	if err != nil {
		return err
	}

	key, err := v.keyResolver.ResolveKey(msg.Context, params.keyID)
	if err != nil {
		return err
	}

        // derive the key algorithms here. For RSA it would be pkcs1 v1.5 or pkcs1 v2.x, 
        // check whether key.Algorithm is in the list of the derived algorithms
        // if not, it would be an error. There will be a need for a helper function taking `key any` 
        // as input and returning `([]SignatureAlgorithm, error)`

        // pass the list of algorithms here to assert and update the assert function accordingly
	if err = exp.assert(params, msg, key.Algorithm, v.nonceChecker); err != nil {
		return err
	}

        // instead of passing key.Algorithm to newPayloadVerifier below
        // do the following. The check above would ensure the algorithm can be used with the key
        algorithm := params.alg
        if len(algorithm) == 0 {
          algorithm = key.Algorithm
        }

	verifier, err := newPayloadVerifier(key.Key, key.KeyID, algorithm)
	if err != nil {
		return err
	}

	return verifier.verifyPayload(base, signature)
}

What do you think?

Beyond that - I've been once involved into a government project back in 2011 which was mainly about switching from RSA PKCS1 v1.5 to PKCS1 v2.0 as PKCS1 v1.5 was considered not secure any more. We're now in 2026 ;) Btw., I mean the go project has marked pkcs1 v1.5 as insecure meanwhile. At least, I mean I've read about it somewhere beginning of this year.

[dadrus]

One thing, which I forgot to mention. In principle, one can also solve the issue by making use of different key Ids for the same key, but with different algorithms. You have to configure or resolve the key anyway somehow. The HMS rfc does not address that topic, but Web Bot Auth, or WIMSE do - just in case you wanna use a standard.

[mariusor]

What do you think?

Sure. That sounds reasonable.

I was hoping we could modify key.Algorithm into an interface { Matches(SignatureAlgorithm) }, which can get implemented by both the SignatureAlgorithm and []SignatureAlgorithm types. And this call to Matches replaces the current algorithm check logic in exp.assert().

So from ResolveKey() I can now return a composite:

key.Algorithm = []SignatureAlgorithm{RsaPkcs1v15Sha256, RsaPssSha256}

As for sending different key ids, I can't do that because on my side the KeyResolver has no control on the key whatsoever. It fetches it over HTTP as part of a JSON-LD object.

---

Of course another way for me to solve this, is to allow the extraction of the request parameters from the header independent of the verifier (as far as I can tell, there's no reason why getSignatureReferences() is not exported). So, this way I can prep my key resolver with the algorithm specified in the parameters before initializing the verifier itself with the resolver.

Frankly, I like this better, because one, it would be the smallest backwards compatible change (one new exported function and type), and two, it probably allows library callers to make more decisions about how to initialize the verifier based on what's in the Signature-Input header.

But it kinda makes obsolete - or at least offers a way around - some of the verifier validation behaviour (specifying tag, verifying creation and expiration, etc).

[dadrus]

As you know, I'm open for breaking changes as long as it makes the lib more usable :). It should however not open ways around the existing checks which would allow circumventing existing security measures. This is also the reason, why I'm not in favor of the "other way" you described.

Regarding the approach, you described first: The Key type is used for both signature creation and verification. In case of the signature creation, the user of the library expresses which algorithm it wants to use - though this can be derived from the actual key, but not always. In case of symmetric keys, this is not possible and in case of RSA, there are those two options. And in case of verification it is used to check the alg tag - the issue you run into.

While I like the approach you describe for verification of the signatures/macs, I wonder, how it would fit, respectively what is required for the signature creation.

[mariusor]

Yes, you're right, I didn't consider the signing aspect, sorry.

Would the Matcher() interface work better on the AcceptSignatureBuilder.keyAlgorithm?

And where the []SignatureAlgorithm (or SignatureAlgorithm) can be passed down using the helper initializer function you mention in your first reply?

And then the KeyResolver returns an empty or const Unknown SignatureAlgorithm?

---

[edit] it looks like it's the same problem: AcceptSignatureBuilder gets used for signing also... :(

[mariusor]

I've created a branch with a similar solution to what I described above, however set the expected algorithms directly on the expectations struct, not on the AcceptSignatureBuilder

It feels a little unhygienic to have two very similar elements in such close proximity, but I can't understand what the use of the AcceptSignatureBuilder.Build() is exactly and if it can be used to select from multiple Algorithms.

Please have a look and let me know if I'm heading in the right direction, at least.

[dadrus]

Sorry again for the silence. Actually, I wanted to approach you in the morning, but my wife got a flat, so I had to jump in and deal with the towing so she could make it to her appointment. So, just came back home.

Regarding your question: hms allows creating a challenge requests and responses containing the information about the expected signature params. It defines the Accept-Signature header for that purpose. The builder, you asked about is meant to create such a challenge. The corresponding functionality of the lib is described here in the readme. The direct usage of the builder is actually meant for the client side to inform the server it should sign the response. On the server side, the challenge can be configured by making use of the WithSignatureNegotiation option. I can't remember out my head, but it can also be that the option makes use of the builder internally as well.

[mariusor]

No worries about the silence, you don't need to apologise.

Let me know, though, if this passes the smell test for you.

[dadrus]

I finally found some time to take a closer look at your approach in the branch you referenced above.

For the concrete verification use case, the approach obviously works. There are however some aspects which makes me uncomfortable. In particular, this part:

algorithm := key.Algorithm
if err = exp.assert(params, msg, key.Algorithm, v.nonceChecker); err != nil {
	return err
}

if algorithm == Unknown {
	algorithm = params.alg
}

verifier, err := newPayloadVerifier(key.Key, key.KeyID, algorithm)

The problematic bit is this:

if algorithm == Unknown {
	algorithm = params.alg
}

This actually came from me as a suggestion in one of the comments above, but after thinking more about it, I am not fully happy with it.

With that logic, the verifier falls back to an algorithm value supplied by the message sender. I know this is not directly comparable to the well-known JWT algorithm confusion issues, and Go's type system plus the checks in this library and the standard library make some classes of attacks much harder or impossible. Still, the shape is similar: attacker-controlled input influences how the signature is verified. From a security API design perspective, these lines have a smell.

What I would like to avoid is a default behaviour where the sender can effectively select the verification algorithm just by setting alg in Signature-Input.

There is also another API design concern: this makes the meaning of Key.Algorithm less clear. So far, Key.Algorithm has meant: "this key is intended to be used with this concrete algorithm". With the proposed change, Unknown would additionally mean: "please derive the concrete verification algorithm from the signature parameters". That may be useful for verification, especially for RSA keys, but it also weakens the semantics of the Key type. Since the same Key type is used for signing and verification, I would prefer not to overload that field too much.

Let me try to recap my initial suggestion and map your implementation to it.

As of today, there are three relevant inputs:

• key.Key, which defines the actual key material and, to some degree, constrains which algorithms can technically be used.
• key.Algorithm, which is an explicit statement from the key resolver about the algorithm to be used.
• params.alg, which is a sender statement about the algorithm used for the signature.

These define the current constraints: key.Algorithm must be set and must be usable with key.Key. If params.alg is set, then key.Algorithm and params.alg must match.

My suggestion in #130 (comment) introduced the idea of compatible algorithms: a set of algorithms that are technically compatible with the key material, to the extent this can be derived from the Go key type.

That would allow the verifier to fall back to params.alg when key.Algorithm is intentionally left unspecified, while still staying within the technical constraints of key.Key.

However, technical compatibility alone is not sufficient. For RSA, for example, a public key may be technically compatible with both RSA-PSS and RSA PKCS#1 v1.5. If a deployment wants to require RSA-PSS, accepting RSA PKCS#1 v1.5 just because it is technically compatible with the RSA key would be an algorithm downgrade. So there needs to be some sort of policy signal as well.

One possible way to express that signal is to allow Key.Algorithm to be Unknown for verification. In that case, Unknown would mean that the key resolver intentionally does not enforce a concrete algorithm and allows the verifier to derive the selected algorithm from Signature-Input;alg, subject to further verification policy checks.

This would work reasonably well for asymmetric keys, where at least the key type gives us useful compatibility information.

For symmetric keys, however, deriving compatible algorithms from the key material does not really work. A shared secret byte slice does not tell us whether HMAC-SHA256, HMAC-SHA384, or HMAC-SHA512 should be used. In that case, either Key.Algorithm or an explicit verifier policy is required.

Your branch does not have something like compatible algorithms. Instead, it introduces a new option named WithSignatureAlgorithmPreferences, which effectively acts as an allow-list. I do see the need for such an allow-list, and it can also help with the symmetric-key case mentioned above. However, I see it as another check in the verification chain, not as a replacement for checking compatibility with the actual key material.

I think the better direction would be to design the algorithm resolution and verification flow like this:

1. If both Key.Algorithm and Signature-Input;alg are present, they must match.
2. If Key.Algorithm is present, it remains the selected algorithm.
3. If Key.Algorithm is Unknown, Signature-Input;alg may become the selected algorithm.
4. The selected algorithm must be compatible with the actual key material.
5. If an allowed-algorithms list is configured, the selected algorithm must be contained in it.
6. If no selected algorithm can be determined, verification fails.

That way, the RSA use case is still supported: a KeyResolver can return an RSA public key without having to hard-code PSS vs PKCS#1 v1.5. But the decision to accept a sender-provided alg value is not completely implicit. It is constrained by the actual key material and, if configured, by an explicit verifier policy.

I would also rename WithSignatureAlgorithmPreferences, because "preferences" sounds like ordering, negotiation, or a hint. For verification this is not really a preference, but a constraint. Something like WithAllowedSignatureAlgorithms or WithAcceptedSignatureAlgorithms would describe the semantics better.

So overall: I think the branch goes in the right direction, but I would like to adjust the naming and semantics before merging something like this. In particular, I would prefer an explicit compatibility check against the actual key material, plus an optional allow-list / verification policy, over treating Key.Algorithm == Unknown as an unconditional permission to use params.alg.

Another aspect worth considering is that Key.Algorithm is not only relevant for signature verification.

For signature creation, the situation is different from verification. When creating a signature, the library must eventually use one concrete algorithm. For some asymmetric key types this could theoretically be derived from the Go key type. For example, Ed25519 is obvious, and ECDSA can usually be mapped from the curve. For RSA, however, the key type alone does not tell us whether RSA-PSS or RSA PKCS#1 v1.5 should be used, so the library would have to choose a default. For symmetric keys, deriving the algorithm from the key material is not possible at all. A byte slice does not tell us whether HMAC-SHA256, HMAC-SHA384, or HMAC-SHA512 should be used.

So for signing, Key.Algorithm is still the explicit algorithm selection and shall imo remain a concrete value != Unknown.

There is also the Accept-Signature / challenge generation case. There, Key.Algorithm has yet another role: it can be used to tell the peer which key and algorithm should be used for a future signature. In that context, the algorithm may intentionally be omitted, because the challenge can be more or less specific. But that is different from verifying an already received signature. The challenge only expresses what we request from the peer; it should not define how the verifier resolves ambiguous algorithms later.

To summarize: For signing, Unknown is not useful because one concrete algorithm is required. For challenge generation, omitting the algorithm may be meaningful. For verification, Unknown would mean that the verifier may derive the algorithm from Signature-Input;alg, but only under well-defined verification rules described above

Does this make sense?

[dadrus]

@mariusor: An unrelated question - are you maybe attending the OWASP AppSec EU in Vienna this week? If so, let's meet for a chat, or a beer, or so :)

[mariusor]

No, sorry. I'm not really a security dev, it's just incidental to what I'm doing sometimes. :) Terrible time for the conference though, my commiserations.

PS. I still have this open in my browser and will give it a proper look when I have some time from fixing some other bugs.