Hello Neil, Thanks for the thoughtful feedback.
You're right that CNSA 2.0 systems will effectively be their own little world. The Purpose and Scope section is quite explicit about this: SHA-256 methods remain the recommended defaults, deployments not subject to CNSA-like policies SHOULD NOT use the SHA-512 alternatives, and nothing is being deprecated. On whether PKCE code challenges or DPoP proofs are "classified data": systems operating under these constraints treat these much like FIPS mode in OpenSSL, i.e. only validated algorithms are available and non-compliant algorithms are disabled. They don't cherry-pick individual artifacts and classify them one by one. And so if SHA-256 is not an approved algorithm in that environment, it's simply not available regardless of what you'd use it for. I used CNSA 2.0 as a concrete example of why this gap exists but I don't intend to opine on its interpretation or scope. Whether one agrees with the policy or not, the deployments that have these constraints are (about to be?) real, and they currently cannot use PKCE, mTLS certificate binding, or DPoP at all (because let's not mention none anymore)... 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? > Agreed, we'd resolve this awkwardness as we go along. Can someone talk to NSA and tell them to stop being so silly about SHA-256? Agreed, (╯°□°)╯︵ ┻━┻ S pozdravem, *Filip Skokan* On Fri, 27 Feb 2026 at 00:07, Neil Madden <[email protected]> wrote: > 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 > > On 26 Feb 2026, at 21:52, Filip Skokan <[email protected]> wrote: > > > 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-Possession* > <https://datatracker.ietf.org/doc/draft-skokan-oauth-additional-hashes> > > *Problem:* 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, > *Filip Skokan* > > 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. > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] > >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
