This mostly seems fine to me on a technical basis. I think I’ve previously argued that if we were going to pick one hash it should have been SHA-512, but of course now we’ll have two.
However, the more I think about the rationale for this, the less it seems to make sense.
The CNSA 2.0 FAQ says it applies to NSS data “at all classification levels” - are PKCE code challenges or DPoP proofs actually classified data in such systems?
Are *plain* (unhashed) PKCE code challenges allowed in CNSA 2.0 or not? Seems a bit mad if they are but S256 is banned…
Relatedly, the draft currently says that a client must check the server metadata and only use S512 for PKCE if the server supports it. But if the client is NSS and so can only use S512 then presumably in this case it must either opt to not use PKCE at all, or else refuse to talk to the server? In what world are either of those sensible choices?
This all seems a bit daft to me. (CNSA, not this draft). The only winning move is not to play. I think the upshot is that CSNA 2.0 systems are in fact going to have to be their own little world where they all (by policy) only support S512 and do not interoperate with anything else.
Can someone talk to NSA and tell them to stop being so silly about SHA-256?
— Neil Hi all, Just in time for monday's I-D submission cut-off I'd like to introduce a new individual draft: Additional Hash Algorithms for OAuth 2.0 PKCE and Proof-of-PossessionProblem: Several OAuth 2.0 mechanisms, namely PKCE (RFC 7636), mutual-TLS certificate-bound access tokens (RFC 8705), and DPoP (RFC 9449) exclusively mandate SHA-256 as their hash algorithm, with no alternative and possibly even no extension point. Security policies such as the US CNSA 2.0 Suite prohibit the use of SHA-256 entirely and require SHA-384 or SHA-512 instead. This means that deployments operating under such policies cannot use any of these mechanisms. For deployments that prohibit SHA-256, this draft defines:- PKCE: An S512 code challenge method (registered via the existing PKCE Code Challenge Methods registry).
- Mutual-TLS: An x5t#S512 confirmation method.
- DPoP: A jkt#S512 confirmation method and ath#S512 access token hash DPoP Proof claim, along with a dpop_jkt_method authorization request parameter for specifying which hash is used in the JWK Thumbprint calculation for authorization code binding.
- Various RS and AS metadata such that if called for, a gradual migration would be possible.
I want to be very clear about what this draft is not: - It is not a deprecation of SHA-256 in PKCE, DPoP, or MTLS. The SHA-256 based methods remain the widely deployed, interoperable, and recommended defaults for all mechanisms this document addresses.
- It is not a call for migration. Deployments that are not subject to restrictive security policies have no reason to adopt the SHA-512 alternatives and in my opinion should not offer or use them.
Feedback is welcome. Thank you S pozdravem,
A new version of Internet-Draft draft-skokan-oauth-additional-hashes-01.txt
has been successfully submitted by Filip Skokan and posted to the
IETF repository.
Name: draft-skokan-oauth-additional-hashes
Revision: 01
Title: Additional Hash Algorithms for OAuth 2.0 PKCE and Proof-of-Possession
Date: 2026-02-26
Group: Individual Submission
Pages: 14
URL: https://www.ietf.org/archive/id/draft-skokan-oauth-additional-hashes-01.txt
Status: https://datatracker.ietf.org/doc/draft-skokan-oauth-additional-hashes/
HTML: https://www.ietf.org/archive/id/draft-skokan-oauth-additional-hashes-01.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-skokan-oauth-additional-hashes
Abstract:
This document defines SHA-512 as an additional hash algorithm for
OAuth 2.0 Proof Key for Code Exchange (PKCE), mutual-TLS certificate-
bound access tokens, and Demonstrating Proof of Possession (DPoP),
for use in deployments operating under security policies that
prohibit the use of SHA-256, which is otherwise mandated or the only
option in these mechanisms.
|
