Yes, a reply after a few weeks is still very useful, thanks!
You are right about the point that every library has an "expired" code,
though I start to see other differences. The number of errors itself wildly
differ – OpenSSL has over 75 of certificate-related errors, while GnuTLS
has only about 18 and Botan about 40.
Hearing developer opinions helps me do it in a way useful for you. I
understand big, replied-on, open-source projects are sensitive about
changes. Though I believe at least updating the documentation should be
harmless (the details on the error message in OpenSSL docs sometimes just
restate the message). I'll open a separate issue/WiP pull request when we
have specific propositions.
PS: @Kurt, thanks for the pointer to Frankencert, it did not cross my radar
On Thu, 26 Mar 2020 at 10:28, Kurt Roeckx wrote:
> On Wed, Mar 25, 2020 at 10:21:36PM -0700, Benjamin Kaduk wrote:
> > I tihnk it's an interesting idea. To me, perhaps the most valuable part
> > would be to accumulate a corpus of certificates/chains that are malformed
> > or fail to validate due to a wide variety of errors, almost akin to a
> > fuzzing corpus. I'd also be curious (though I'm not entirely sure how
> > large a practical impact it would have) to perform a clustering analysis
> > across different X.509 implementations and see if different
> > produce different distributions of errors. (That is, we might expect
> > implementation to have an error for "not valid yet", "expired", "missing
> > required ASN.1 field", etc.; each implementation will have a different
> > error string, of course, but if we group all certificates that produce
> > same error with the same implementation together, we have a bunch of
> > different clusters. Repeating the clustering across all implementations
> > lets us compare the different distributions, and examine certificates
> > end up in a different cluster in different implementations.)
> That's what frankencert did.