Re: Channel binding for post-quantum cryptography

Jacob Champion <jacob.champion@enterprisedb.com>

From: Jacob Champion <jacob.champion@enterprisedb.com>

To: Michael Paquier <michael@paquier.xyz>, Filip Janus <fjanus@redhat.com>

Cc: Pgsql Hackers <pgsql-hackers@postgresql.org>, Heikki Linnakangas <hlinnaka@iki.fi>, Daniel Gustafsson <daniel@yesql.se>

Date: 2025-10-28T15:18:50Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Fix handling of SCRAM-SHA-256's channel binding with RSA-PSS certificates
- 9244c11afe23 16.0 cited

On Mon, Oct 27, 2025 at 10:55 PM Michael Paquier <michael@paquier.xyz> wrote:
> Another thing that bugs me is that this patch would force sha-256 for
> everything, without at least checks based on NID_ML_DSA_44,
> NID_ML_DSA_65 or NID_ML_DSA_87.  That may be more flexible, but I'm
> wondering if it could become a problem long-term to enforce blindly
> such a policy every time algo_nid is undefined.

I think it would be a problem, at least if the previous conversations
around X509_get_signature_nid() are any indication.

Filip, you said

> RFC 5929 recommends SHA-256 for unknown/unsupported algorithms

but I don't see any language like that; can you provide a quote? That
doesn't seem like a recommendation that would allow for
interoperability in the long term.

The IETF draft at [1] (which was updated just last month) seems to
provide new signatureAlgorithm IDs for ML-DSA. Is this just a matter
of waiting until the specs are released and OpenSSL implements them?

Thanks,
--Jacob

[1] https://datatracker.ietf.org/doc/draft-ietf-lamps-dilithium-certificates/