Improving X.509 certificate validation errors

[Martin Ukrop]

Hi Ben,

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
yet.

Martin.

On Thu, 26 Mar 2020 at 10:28, Kurt Roeckx <kurt at roeckx.be> 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
> implementations
> > produce different distributions of errors.  (That is, we might expect
> each
> > 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
> the
> > 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
> that
> > end up in a different cluster in different implementations.)
>
> That's what frankencert did.
>
>
> Kurt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200326/d32a1ef6/attachment-0001.html>