Re: Defining HTTP signature validation (RFC 9421) as a precondition extension to allow 412 as the response code

[Justin Richer <[e-mail]>]

RFC9421 does not specify error codes to be used, as the appropriate error code depends entirely on the part of the overall security stack that the signatures are being used in. If the signature is used as part of an authentication scheme for some other protocol or system, then a 401 would be appropriate for a failure to sign the message appropriately (since the result is that the authentication failed). If you’re doing it as part of precondition checking as your example below, then 412 would be reasonable. It’s entirely up to the application of the signatures to define what errors make sense and how to process them. The details of section 1.4 (https://www.rfc-editor.org/rfc/rfc9421.html#name-application-of-http-message) are about how to apply the signature to an overall system, and the additional kinds of things that you need to define as part of the application. The examples therein are just that, examples, and carry no normative weight. There was some talk in the HTTP-API WG about defining a generic set of error messages per RFC9457, but initial discussions landed on there being many potential error cases that could be returned and the appropriateness of returning those errors specifically for different applications is going to vary.

Ultimately, choose an error code for your application that makes sense for your application.

 — Justin

On Nov 21, 2025, at 10:38 AM, DYER Kevin <[e-mail]> wrote:

Hello All,

I am working with a team that is looking to implement HTTP Message signatures and validation within our products. I have not read the entire history of how this specification evolved over time and therefore do not know if this topic was previously discussed. If it was and not acted upon, I apologize up front.

After reviewing the RFC I find the error reporting recommendations for using a status code of 401 is not in-line with [HTTP] RFC 9110 Section 15.5.2 401 Unauthorized. Additionally, the status code 403 does not make sense when requests have been made with credentials being exchanged. The 403 response can be interpreted by intermediary network components, as in ZTNA or identity-aware proxies, as an indicator by the origin/target server to cease all access to this session. If not the network components then the application itself may take action when a 403 is the status response and perform an absolute session termination (SLO).

My interpretation of RFC 9421 has me regarding signature validation as a higher class of preconditions to the HTTP message, much the same as If-Modified-Since, If-Match, etc. But these preconditions are applied before further processing the HTTP message and after any TLS preconditions have been met (SERVER HELLO Certificate Validation, SNI, mTLS, ALPN, etc).  In the Tomcat world this could be implemented at a valve level, to be executed before a single nibble of application code is run.

Prereq:  the server or client has been configured with a valve/filter/servlet/JavaScript function to recognize and operate on all signature components.

If the signature validation is indeed a super class of preconditions that must be validated. And when the signature components are found within the header section of the HTTP message then doesn’t it make sense to use the 412 Precondition Failed as the primary status response from signature validation failure or exception? The 412 response per [HTTP] allows for as much or as little details as necessary in the response body to provide information to the end user.

Best Regards,

Kevin J. Dyer
AMERICAS User Success Engineering Director, Infrastructure and Security
[e-mail]<mailto:[e-mail]>

Next OOO –
------------------------------------------------------------------------------------------------------------------------------------
Office:      [phone]
Mobile:    [phone]

Dassault Systèmes | www.3ds.com<http://www.3ds.com/> | The 3DEXPERIENCE
Dassault Systèmes | 175 Wyman St |Waltham, MA  02451-1223 | United States

This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.
If you are not one of the named recipients or have received this email in error,
(i) you should not read, disclose, or copy it,
(ii) please notify sender of your receipt by reply email and delete this email and all attachments,
(iii) Dassault Systèmes does not accept or assume any liability or responsibility for any use of or reliance on this email.

Please be informed that your personal data are processed according to our data privacy policy as described on our website. Should you have any questions related to personal data protection, please contact 3DS Data Protection Officer https://www.3ds.com/privacy-policy/contact/