Address reviewer feedback on httpsig

[mickenordin]

Address HTTPSig review feedback

This PR addresses the review feedback from Justin Richer on the
HTTP Message Signatures section of the draft.

Changes

Date header

The Date header is no longer covered by signatures: intermediaries commonly rewrite it, and the created signature parameter already conveys creation time (RFC 9421 §7.2.4).

Algorithm derivation

The signature algorithm is now derived from the key material instead of being restricted to the IANA "HTTP Signature Algorithms" registry. Each JWK MUST carry kid and alg; the JWK alg MUST be an asymmetric JOSE-registered algorithm and SHOULD be fully-specified per RFC 9864 (Ed25519 RECOMMENDED, which also replaces the RFC 8037 reference). The algorithm is applied per RFC 9421 §3.3.7, so new (e.g. post-quantum) JOSE algorithms work without updating this document. none and MACs are forbidden. The HTTPSig alg signature parameter is OPTIONAL; if present it MUST denote the same algorithm as the JWK, and is omitted when no registry counterpart exists. A new "Keys and Algorithms" subsection holds this text.

JWKS discovery

The unregistered /.well-known/jwks.json endpoint is replaced by a jwksUri field in the Discovery response (also added to spec.yaml). Servers advertising the http-sig capability MUST provide it.

keyid

The keyid signature parameter is now REQUIRED and MUST equal the kid of the verification key in the signer's JWK Set; verifiers reject signatures with no matching key.

Informative examples

Appendix B is now explicitly informative; its normative statements were moved into the HTTP Message Signatures section. All signature examples use RFC 8792 line wrapping, and the
Token Request example uses Content-Digest (RFC 9530) instead of the legacy Digest header, with real digest values.

Consistency pass

The Trusted Server definition, Discovery introduction, and Decision to Discard now speak of JWK Sets discovered via jwksUri and the keyid/kid match; the Token Request example covers content-length as required; the Appendix B example carries a real Content-Digest and Content-Length.

The Version 07 changelog records all of the above.

[MahdiBaghbani]

Thanks for this, I think the direction is really good.

Requiring keyid, deriving the algorithm from the JWK, and dropping Date from the covered components all make the signing model a lot easier to reason about. I also like moving the JWKS publication and payload-consistency requirements into the normative section and marking Appendix B as informative.

I have included suggested changes inline for each comment, so you can apply them quickly from the GitHub UI if you agree with them.

I left a few inline comments. Most of them are editorial, but three are worth sorting out before RFC last call:

• jwksUri has no https requirement (spec.yaml + I-D), and the I-D text does not say the JWK Set must be fetched over https.
• There is no kid uniqueness MUST within a JWK Set, so a verifier that hits two keys with the same kid has no defined behavior.
• The cross-registry alg mapping is only shown for Ed25519, so "MUST denote the same algorithm" is not really interoperable for RSA-PSS or ECDSA yet.

A couple of non-inline notes:

• The Version 07 changelog looks like it mixes in a few items that I think actually landed in #390 (the same-string note, the Appendix D label fix, the Signing Direction Index, Appendix E, the diagrams). Could you please double-check those belong here?
• Removing the fixed /.well-known/jwks.json path is a real wire change for peers that hardcoded it, and it adds a mandatory Discovery round-trip. I think a short migration note would help implementers.
• The diagrams under diagrams/ (02-discovery-receiver-publish, 07-signing-directions) still hardcode /.well-known/jwks.json. I added those diagrams myself, so if you like I can fix the diagram paths in this PR too, to keep them consistent with the new jwksUri model.

A few more small ones I could not attach inline because the lines fall outside this PR's diff:

• spec.yaml line 32: the 200 description still says "public key" (singular); now it is a JWK Set via jwksUri.
• IETF-OCM.md line 1348 and line 1999: "HTTP Signature" should read "HTTP Message Signature(s)" to match the section title and RFC 9421.

The examples check out as far as I can tell: the Content-Digest values and content-lengths match the example bodies, and the RFC 8792 folding looks mechanically correct.

Some of my suggestions are a bit more normative than editorial, so if I misunderstood the intended model, feel free to push back and we can narrow it down.

[mickenordin]

I think I addressed your feedback now @MahdiBaghbani

[glpatcern]

This looks good now, Mahdi you have the last word following your detailed review

[MahdiBaghbani]

This looks good now, Mahdi you have the last word following your detailed review

I'll review this soon

[mickenordin]

Maybe we shouldn't mandate HTTPS for fetching the key material @MahdiBaghbani ?

It breaks real deployments in Nextcloud, as well as a lot of testing setups: nextcloud/server#62543

I would be content with RECOMMENDING https.