[gnutls-devel] GnuTLS | Valid cert fails to verify due to different DN encodings (#553)

[Development of GNU's TLS library]

For what it's worth, the strings we're having trouble with are in the pure ascii territory: no codepoints above 0x7f. They match exactly and do not differ in case. Ignoring the tag while comparing the strings would work fine in this case. I only mention the stringprep stuff because it's a clear indication that the spec expects implementations to deal with encodings and not just do straight binary compares, like GnuTLS is doing now.

The cert validates just fine with OpenSSL. So I don't think "the generation should be fixed" is the right answer here—This is a consumption issue in GnuTLS. As far as I can tell, GnuTLS is deviating from the spec here, and not the library that created the cert. Therefore, arguing that they must change their code instead of fixing a compliance bug in GnuTLS is going to be a very hard sell.

In our particular case, the CA and the created cert have different dn encodings because different tools created them. If the CA generation tools were java based everything would be UTF8Strings and it would work fine. It's kind of crazy to me that this hasn't come up yet, but maybe most people don't have heterogeneous tooling?

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/553#note_101707949
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20180917/55790605/attachment.html>