On Thu, 24 Jan 2019 10:04:00 +0100 Kurt Roeckx via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > Will you fill something in in the commonName? I think what is > expected in the commonName is what the user would type and expect to > see, I don't think the commonName should contain > xn--gau-7ka.siemens.de. If you have a commonName, I would expect that > it contains gauß.siemens.de. And if you create a commonName then, you > are required to check that it matches the xn--gau-7ka.siemens.de in > the SAN.
I have two responses to this, first the practical one: In Firefox (our most direct concern here on m.d.s.policy) of course CN is entirely ignored for matching certificates in the Web PKI. However many other clients exist, and we know most of them continue to parse CN as you might have done twenty years ago trying to find some IP address or DNS name in the human readable text. In some cases they either don't understand SANs, or they prioritise matching CN over SANs. This is a bad idea (if you are reading this and have responsibility for the name matching algorithm in either a client or library I implore you to go look at this again) but it's out there today and isn't going away in the immediate future. Concrete example: Until relatively recently Python's SSL/TLS implementation, including in the very popular "Requests" library, would match a Unicode hostname string against CN or SANs, even though that's not correct behaviour. When a user asks to connect to 瞺瞹砡.example the Python code correctly determines that it needs the DNS name xn--b6yb42a.example to find the IP address but it still expects the certificate to match 瞺瞹砡.example not xn--b6yb42a.example. This is of course impossible for SANs by definition, and that impossibility was helpful in persuading developers that their understanding of what needed to happen here couldn't be correct. I (as a relying party) would prefer that failure modes that fall out of this sort of error aren't fatal to security. CAs that write SANs as IA5-Strings with A-labels into CN fail safely here, whereas those which try to conjure U-labels for a Unicode String risk tricking some of this bad parser code into accepting a certificate for one name as valid for a similar but different name or blowing up the parser itself (I haven't seen examples where UCS-2 string data ends up written to a NUL-byte terminated C string but I would not be surprised if it happens) For compatibility reasons omitting CN altogether is not usually a good plan, so to me that leaves writing the A-labels as the best option. I believe Let's Encrypt currently has experiments ongoing as to how to opt out of writing CN, but there's no intent to actually stop doing it by default. Second, a philosophical response: The purpose of the Subject DN is to identify the Subject to a Relying Party and we want it to be clear exactly which Subject we're identifying. It is difficult, and maybe impossible, for a Certificate Authority to specify how the user's input will be handled or how exactly a name will be displayed in every possible user agent software. On the other hand, the DNS A-labels, though unfamiliar to a human and unwieldy to think about, have the advantage that they're definitely identifying the specific thing we validated, not anything with a different but similar name. The reason it's hard for the CA to reason about Unicode names is that not only do you have all of IDNA-2003, IDNA-2008, TR#46 but also browsers have lots of counter measures (and the exact counter measures deployed in famous brand browsers have changed over time) for the problem of confusable DNS names. A browser may choose to write an IDN in Punycode to avoid confusing users into believing the IDN is actually some distinct name that merely looks similar. My preferred outcome here would be for CAs to just voluntarily choose not to write U-labels into CN AND for user agents to stop trying to parse CN instead of just handling SANs. I think that's easier and safer for basically everybody. But I don't feel strongly enough about it that I feel we want "Incident Reports" for every scenario where this didn't happen. I do feel strongly enough about it that if a incident does happen and the proximate cause was "We write U-labels into CN and that tripped a bug" there's a good chance I will do the Nelson Muntz laugh and no chance I'll have sympathy for the CA this happened to. Nick. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
