WIMSE HTTP Message Signatures

The digest lists five new issues on draft-ietf-wimse-s2s-protocol. Two concern draft-ietf-wimse-http-signature-08: a request for test vectors (#419, four comments) and a note that sample nonces in the examples are illustrative and below the entropy floor (#420). Two are editorial-comment trackers for the HTTP-Sig and workload-creds drafts (#417, #418). Issue #416 proposes requiring name-constrained issuing CAs when a trust anchor is shared across trust domains. It also drew a comment on #370 (overlapping trust roots, labelled workload-creds and mutual-tls) and on arch PR #142 (Terminology). Issue #414 (Reconcile Coexistence) got one comment, and PR #415 fixes three spelling errors. The digest gives only titles and comment counts, so no proposed wording or decisions are visible, and no draft text changed.

• An implementer of WIMSE HTTP message signatures waiting on test vectors to validate interoperability can follow issue #419.
• A deployer where several trust domains share a root CA can follow issue #416 and #370 on whether name-constrained issuing CAs will be required.

Jiahui Miao posted 6 positive and 22 negative vectors for draft-ietf-wimse-http-signature-08 (issue #419 in the s2s-protocol repository), each negative case tied to a MUST in the draft, with keys, signature bases and a fixed clock. Two questions: whether a verifier should reject or ignore keyid/alg parameters, and whether the Section 3.7 example nonces, which carry less than the 64-bit minimum, deserve an editorial note. Yaron replies that a MUST NOT in a security RFC should be rejected by the recipient, an issue to add that note has been opened, and a few vectors may need fixing (details in the issue). The nonce question is not answered in this reply.

• Implementers of WIMSE HTTP message signatures who want interop test cases for rejecting malformed requests.
• Verifiers deciding whether to reject or silently ignore forbidden signature parameters.

An individual contributor reports on the mailing list that test vectors P-01 and P-02 wrote the @query component value without the leading ? required by RFC 9421 Section 2.2.7. An independent run found the same defect in P-06's WIMSE signature. All three were regenerated over corrected signature bases with the same keys, parameters and fixed clock. The literal signature in N-15 was also regenerated because it was computed over a P-01-shaped base. Its expected outcome (reject, Section 3.1) is unchanged. Old signatures fail against the corrected bases, and other cases are unaffected. The author also confirms that N-06/N-07 record reject for the keyid / alg MUST NOT parameters, now backed by the draft author's stated intent. An issue was opened to add an example-nonce note. The author will contact the chairs about how to contribute the vectors. Nothing in the draft itself changed.

The reviewer notes the draft is past WGLC and judges the rest of the document very good. They propose adding 'HTTP' to the first sentence of the introduction so the full scope is stated at once. They also propose rewriting the introduction's rationale for application-layer protection. The new text says the motivation is consistent identifier and credential handling across the full transit path, including TLS sessions terminated and restarted at proxies or middleboxes, using HTTP signatures with a JWT. No protocol change is proposed, and no WG response is in the material.

The review says the draft is clear and in good shape. It suggests adding HTTP to the first sentence of the introduction. It also suggests rewording the paragraph on why deployments prefer application-layer protection. The proposed text says TLS may involve several hops that terminate and restart sessions, such as at a proxy or middlebox, and HTTP signatures with a JWT keep one identifier and credential across the path. It is a wording change only and does not alter the protocol. Yaron noted it as s2s-protocol issue #417.