[briansmith]

This is uninteresting. CAs are well aware that they have to encode the subject DN and issuer DN identically to maximize interoperability. There are several implementations that require that.

If we were to make a new version of the spec for X.509 certificates, I would hope that we would eliminate all the non-UTF8 encodings so that this would be a non-issue.

[dsl]

That is like saying you can't get a virus on your computer because Facebook doesn't allow viruses to be posted to the internet.

Differential parsing is a whole class of security bugs and they matter a lot. Take a look at HTTP Request Smuggling for examples.

Also, I am pretty sure there are more non-web x509 certificates out there than all the "browser trusted CAs" combined have signed. :)

[woodruffw]

To be clear, the differential here occurs because OpenSSL does the wrong thing. Go is correct to fail closed here, and it’s very hard to imagine a setting in which Go failing closed is a relevant security differential.

[briansmith]

Just to be clear, OpenSSL isn't doing the wrong thing, based on the description in the blog post. The specification allows and even requires behavior similar to that.

[briansmith]

If differential parsing of X.509 certificates is a material security concern for something, then that's a bug in that thing.

[bigfatkitten]

Even outside of the web PKI, the requirement for identical encoding is also often found in certificate policies used within closed communities.

[imperfectfourth]

uninteresting to you, i learned something new.

[NooneAtAll3]

if 2 fields are identical, why aren't they 1 field?

[woodruffw]

They’re two different fields on different certificates. The issuer on the child needs to match the subject on the parent; every certificate has its own subject and issuer.