This is what happens when kids today are unaware of history. This was a known problem 30+ years ago, and the Go kids have just rediscovered it for themselves. The most extreme case of this madness was imagining you could re-encode certificates into a DER blob from their stored components and the signature would still validate, something that OER (from memory) guys are now trying to do.

The rules for DNs are "there is only one encoding rule and that is memcpy(); there is only one matching rule and that is memcmp()". Given that Go has fallen into the decades-old trap of trying to re-encode strings, it's bound to be vulnerable to any number of other issues like evading excludedSubtrees through string-encoding tricks.

▲

jchw 2 hours ago | parent | next [-]

Between this and the IPv6 zone identifier issue, it feels like there's a bit of a trend of commenters more or less assuming Go is doing the wrong thing when it's actually following the standards/best practices more correctly than average. I wonder where this reputation came from.

	▲	fragmede an hour ago \| parent [-]
		Most people accessing a site are likely not using Golang and are using Chrome. Thus Chrome is assumed right and Go is the one that's the outlier.

▲

ahmedtd a day ago | parent | prev | next [-]

From the article, it doesn't seem like Go is trying to re-encode strings? Go is saying (correctly, IMO) that a UTF8String field in the Issuer is not the same as a PrintableString field in the Subject.

	▲	pseudohadamard a day ago \| parent [-]
		Ah, you're right, I was a bit confused by the bouncing back and forth between Go and OpenSSL and the title, "Fooling Go's X.509" when in fact on re-read Go appears to be doing the right thing and using a strict compare while OpenSSL uses the open-to-manipulation compare.

▲

gowld an hour ago | parent | prev [-]

The Go "kids" are famous for, among other things, being industry leaders 30 years ago.

	▲	sidewndr46 22 minutes ago \| parent [-]
		Those young whipper snappers with their lifetime of experience!