Repository navigation
Allow CSRs to be created for encryption-only public keys (such as ML-KEM) #15313
Description
In relation to #15263, which allows ML-KEM public keys to be included in the subjectPublicKeyInfo field in X.509 certificates.
Certificate applicants will either use a CSR (RFC 2986) or a CRMF (RFC 4211) to provide their to-be-certified public key to the CA (among other information). Since ML-KEM (among others) cannot be used to create a digital signature, RFC 9883 has been published as solution.
While most of this RFC describes a procedure, the following items need be added to support this mechanism:
- Sign a CSR using a different private key than was included;
- Ability to add the
statementOfPossessionattribute to the CSR. I'd imagine extending theAttributemechanism in a similar fashion as is done forExtension.
Activity
ronaldvanrij commentedon Aug 6, 2026
For the first item, I've created #15400 to allow using a different public key in a CSR than it signed with. The second item remains open.
test(x509): add CSR public key type validation assertions (pyca#15313)
fix(x509): use x509.NameOID to resolve flake8 F821 undefined name (py…
fix(x509): use x509.oid.NameOID namespace to resolve flake8 (pyca#15313)
style(x509): wrap long line to satisfy ruff 79-char limit (pyca#15313)
style(x509): format NameAttribute single line for ruff format (pyca#1…
fix(x509): fix method indentation from 8 spaces to 4 spaces (pyca#15313)
test(x509): add CSR signing execution for 100% coverage (pyca#15313)
anishbhujbal7 commentedon Oct 6, 2026
I'd love to take a crack at this.
My rough plan is to:
Update CertificateSigningRequestBuilder so a CSR can be signed with a different private key than what's in subjectPublicKeyInfo.
Add support for the statementOfPossession attribute according to RFC 9883 (ASN.1 encoding, OID mapping, and exposing it through the builder/CSR parser).
And add the tests necessary tests