crypto/x509: add API to create RFC-compliant CRLs #35428
Description
What version of Go are you using (go version)?
$ 1.13.4
This is a bit of a redux of #13931, but while the fix there changed the serialization on the wire of the default value, it didn't address the underlying problem, which is that the X.509 RFC pretty clearly states (https://tools.ietf.org/html/rfc5280#section-5):
Conforming CAs are not required to issue CRLs if other revocation or
certificate status mechanisms are provided. When CRLs are issued,
the CRLs MUST be version 2 CRLs, include the date by which the next
CRL will be issued in the nextUpdate field (Section 5.1.2.5), include
the CRL number extension (Section 5.2.3), and include the authority
key identifier extension (Section 5.2.1).
This means that (as specified a bit after that) although any conforming client should be able to parse and understand a CRL created with this function, technically every CRL created via this function is non-conforming, because even if the root is self-signed it's still a CA. There's an argument to be made that a third party could be signing and creating the CRLs, but the behavior there isn't a distinction that is made clear in the RFC and it seems reasonable to assume that the intention is for it to behave the same way.
This would probably require a new function to create v2 CRLs so that the parameters required for the extensions can be provided.
Obviously clients are free to then ignore this extra information, but that's up to the client; it seems pretty clear that anything acting as a CA is required to issue v2 CRLs.