Signature name

[yaronf]

In 7.3.1 (use of gnap with HTTP message signatures), we do not mention the signature name (the string for which we always use sig1). This is a real issue because multiple signatures are possible on any message. Some options:

• Specify an explicit name, e.g. sig1 or better yet gnap.
• Include a signature name in the proof object (but that would preclude the string version of this parameter).

[jricher]

I'm not seeing why this is an issue. Are there security or interoperability concerns?

In the design of HTTP Signatures, the signature's label (sig1 here) is meant to be effectively random and not controlled by the application. The label is not covered by the signature, partially for this reason. We actively don't want people to rely on the value of the signature label at the application level.

The reason for this is that the label is only meant as syntax to the carrier and not something that should be relied upon. If any of the attached signatures for a message meet the requirements for the GNAP protocol (it's the right key, it covers the right components, it validates correctly), then it should be fine no matter what the label is.

Furthermore, I wouldn't expect all libraries to let you set the label explicitly when you're adding a signature to a message. In other words, you should expect a developer to be able to say "take this message and sign it with this key" and be done with it. The label value would be generated internally, after the value of the body has been created, and that should be fine.

[yaronf]

Sorry, this still doesn't make sense to me.

As a receiver, if I get multiple signatures on the same message (which granted is weird but allowed, and with proxy chains may even be realistic), am I really expected to analyze each one of them and apply heuristics to decide which one I like? And yes, a confused verifier is obviously a security issue.

IMO a library that doesn't let you set the sig name provides an incomplete interface.

[jricher]

Yes, I would expect a receiver to check all signatures and see that:

• it covers method, target-uri, content-digest, possibly authorization if there's a token
• it has a created time that's not too far in the past
• it has a tag parameter with the value "gnap"
• it has a nonce parameter that we haven't seen before in recent-ish memory (like maybe two or three times the allowable gap from the creation time)

If there's one that passes all that, then the message is accepted and the other signatures are ignored. This is one of the things that the tag parameter helps narrow down, because you can immediately filter on that parameter for each signature when you go to process it, more easily ignoring the others. The others might have been added by any number of other applications or processes that aren't GNAP.

[richanna]

The sole purpose of the signature name is to bind the Signature and Signature-Input header field entries together. They have no semantic value. They could just be randomly generated UUIDs and that would be fine.

As a receiver, if I get multiple signatures on the same message (which granted is weird but allowed, and with proxy chains may even be realistic), am I really expected to analyze each one of them and apply heuristics to decide which one I like?

Support for multiple signatures isn't just an accident of the design; it's a very intentional feature. Verifiers must examine each signature on the message until they are satisfied that their requirements are met, and should generally ignore signatures they cannot verify. (e.g., because they do not understand the key ID, they do not accept the algorithm, the key material is expired, etc.) I expect that usually a verifier will find either zero or one signatures that satisfy all of its requirements. In some cases, a verifier may permit or even require multiple signatures, for example:

1. A service behind a load balancer may expect a signature from the client that covers all of the application-level requirements, and a signature from the load balancer covering the Forwarded header field.
2. A service that sits behind a gateway that transforms requests might expect a signature from the client, and one from the transforming gateway.
3. A service could vend out signatures as a way to limit a client's authorization to make an API request. For example, a vended signature might cover one request parameter, thereby fixing the value that the client can submit for that parameter while allowing the client to control over parameters. Such a service would expect the vended signature along with a client-issued signature covering the vended signature and the remaining request parameters.

[jricher]

Also, this is addressed in the security considerations for Signatures, and GNAP relying on the label having a specific value would be counter to that advice: https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-13.html#name-signature-labels

[fimbault]

That seems pretty clear, maybe it could help if we'd extend that considerations with what @richanna explained above ?

[yaronf]

Before going into the more complicated use cases, please add some text that addresses basic interoperability. For example:

A received message MAY include multiple signatures, each with its own label. The verifier MUST examine all included signatures until it finds (at least) one that's acceptable according to its policy.

[fimbault]

@yaronf please let us know if we can merge the PR and close this issue ?

[yaronf]

@fimbault Yes, thank you all.