Allow separate public key in CSR

[ronaldvanrij]

This PR:

• Allows any public key type to be included in a CSR, in particular ML-KEM public keys.

[reaperhulk]

Two comments, but also could you share the use case here? Are there specific systems that require CSR submission for public keys they'll encode in certs that are non-signature? We obviously support this in certs, but I'm curious what platforms require submission via CSR for this.

[reaperhulk]

This needs to be documented

[reaperhulk]

Looking at this more, why not refactor is_signature_valid to have it take an optional public key to handle this case?

[alex]

It can'tm because it's a property. But I do think it'd be more appropriate to name this verify_directly_signed_by or something so what it's checking is clear.

[ronaldvanrij]

Indeed, I considered allowing an optional public key (as with CertificateRevocationList) , but that would break existing code because the function would always evaluate to a truthy value.

I've renamed the validate function to verify_directly_signed_by, and aligned its behaviour with Certificate.verify_directly_issued_by: made the public key mandatory and raise exceptions instead of returning a boolean. I've also added appropriate test cases.

[reaperhulk]

All the vectors need to be documented in test-vectors.rst.

[ronaldvanrij]

I wasn't aware of that, I now have added descriptions.

[ronaldvanrij]

The primary use case is when both digital signature and encryption are used in digital communication, for example in AS2. With the caveat here that both ends need full control over their private keys so only they can read the content and assert integrity and origin.

Within the Dutch Government we have a similar standard called Digikoppeling, which requires the use of both digital signature and payload encryption and enforces certificates issued by specific entities, which are part of the PKIoverheid ecosystem. To request certificates, organizations need to generate their own key pairs and issue a CSR towards said entities so they can issue appropriate certificates.

Both digital signature and encryption can currently be done using RSA, but with the PQC algorithms having only a single purpose, logically they will need to generate two key pairs (signing and non-signing) and request the two associated certificates.