Description
Go 1.16 adds a number of additional convenience fields to CertificateRequest. I think these fields are a bad idea and should be removed before Go 1.16 is released and these fields have to be supported forever.
Go's Cryptography Principles state that the Go crypto library should be easy to use securely. Unfortunately, there are numerous examples of CAs accidentally copying unverified data from CSR fields into final certificates:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1551374
- https://bugzilla.mozilla.org/show_bug.cgi?id=1551372
- https://bugzilla.mozilla.org/show_bug.cgi?id=1551369
- https://bugzilla.mozilla.org/show_bug.cgi?id=1551364
- https://bugzilla.mozilla.org/show_bug.cgi?id=1551371
- https://bugzilla.mozilla.org/show_bug.cgi?id=1567456
- https://bugzilla.mozilla.org/show_bug.cgi?id=1390979
- https://bugzilla.mozilla.org/show_bug.cgi?id=1551363
Ingesting CSRs is so error-prone that a prudent CA should be discarding everything in a CSR except the public key. Of course, the library can't prevent people from copying raw extensions out of Extensions, but it could try to avoid nudging people in the wrong direction, and making CSR fields more conveniently accessible seems like a nudge in the wrong direction.
The Cryptography Principles also state that the library should focus on "common use cases." However, the bug which proposed this change (#37172) doesn't explain the use case for taking these fields from CSRs, and received only one positive reaction from a non-Go-teammember. I don't think there's any reason to believe that this is a common use case, particularly in the WebPKI, which crypto/x509 is aimed towards.
I'm particularly alarmed by the addition of the BasicConstraints fields (e.g. IsCA). In a robust PKI, the process for issuing a CA certificate should be distinct from the process for issuing an end-entity certificate. It's not something that should ever be based on the contents of the CSR.