I expected to get a negative result, as the signature on the attached CSR (also embedded in the example program) was not computed according to RFC2986. In particular, the attached CSR contains an unordered multi-value RDN, that is an unordered SET OF, in its Subject field, and this was apparently ignored when the CSR was generated (RFC2986 requires DER-encoding the certificationRequestInfo component prior to signing it). So the signature, although it's cryptographically correct, was computed over the wrong data, and I'd expect a CSR validator to detect that.
A number of other tool(kit)s report the signature as invalid, which IMO is the correct result, including GnuTLS and BouncyCastle.
What did you see instead?
I got a positive result.
The text was updated successfully, but these errors were encountered:
We do not recompute the DER encoding of the CSR (or certificate) when checking the signature, since that would rely on our encoder in order to verify the cryptographic correctness of the signature (which has, in the past, caused issues for other implementations). Instead we simply check the signature against the raw TBS DER encoding that was extracted during parsing. I believe our current behavior here, in regards to the signature, is correct.
That said there is an open question about parsing, if we consider improperly ordered RDNs as malformed (which the RFC suggests is correct), then we should reject the CSR during parsing. With the current CSR parser this isn't possible, but with #50674 this may be viable.