| From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz>, Filip Janus <fjanus(at)redhat(dot)com> |
| Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Daniel Gustafsson <daniel(at)yesql(dot)se> |
| Subject: | Re: Channel binding for post-quantum cryptography |
| Date: | 2025-10-28 15:18:50 |
| Message-ID: | CAOYmi+ng6BjSrQtqPFH0suP8+rg6w-tiuOzHW7Ms2026_E_31A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Oct 27, 2025 at 10:55 PM Michael Paquier <michael(at)paquier(dot)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/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christoph Berg | 2025-10-28 15:20:50 | Re: failed NUMA pages inquiry status: Operation not permitted |
| Previous Message | Tomas Vondra | 2025-10-28 15:14:43 | Re: failed NUMA pages inquiry status: Operation not permitted |