Related Issues

• crypto/x509: ParseCertificate error: PrintableString contains invalid character #36044 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

cc @golang/security

Thanks @gabyhelp for the link, that is a similar issue to what I am having, although the author there was satisfied without a resolution.

The ZCrypto suggestion is one that I looked at before posting this issue, but as that project states in its README, it is meant for experimental use only, and should not be used for production systems.

I unfortunately fall into the production systems category

Looking at that, I understand that the positioning of the standard library's crypto packages hasn't changed. We generally agree with the rationale behind RFC 9413.

To elaborate:

Are these certificates you are parsing publicly trusted? As the crypto/x509 package doc states: "The package targets the X.509 technical profile defined by the IETF (RFC 2459/3280/5280), and as further restricted by the CA/Browser Forum Baseline Requirements. There is minimal support for features outside of these profiles, as the primary goal of the package is to provide compatibility with the publicly trusted TLS certificate ecosystem and its policies and constraints."

We tend to try to eschew complexity needed for the myriad of additional uses of X509. Adding a lax parsing mode on its face seems extremely complicated, and would require us to carry multiple code paths in many places in order to support extremely niche uses of the package. On balance it seems unlikely to add enough value to justify the additional complexity.

To answer Roland, the certificates in question are internal to my organization, and come from a trusted source. I can't speak to the complexity of the implementation that would be required here, although I would have guessed fairly small.

I appreciate your thoughts. Hm. I certainly respect the effort to encourage protocol interoperability long-term, but nonetheless I am pretty taken aback at the lack of flexibility. A simple example that comes to mind is how curl allows you to bypass SSL verification, because sometimes you're just testing. And back to the original topic, sometimes you're simply working in less-than-perfect environments where you don't control all the variables.

I understand that the projects has guiding principles, though. As for me, I will certainly hesitate before using Go again on any project working with certificates or cryptography. It appears there is a fairly high risk of running afoul of the unbending rules.

You can, of course, copy the code and modify it for your purposes.

The question here is whether the Go project should add flexibility in the standard library. Since Go is very strict about backward compatibility, flexibility is a maintenance cost that has to be borne for the foreseeable future. And, flexibility is the antithesis of security, as each optional choice opens up additional possible security holes. And, the holes expand exponentially in the number of choices, as we have to consider all combinations of all choices.

We do have to be pragmatic: if many systems require a different approach, then we have to adapt. But with only a single report, where the data clearly violates the standards, there doesn't seem to be a strong argument here. Sorry.