On 24/01/2019 09:04, Kurt Roeckx via dev-security-policy wrote: > On 2019-01-24 9:47, Buschart, Rufus wrote: >> Good morning! >> >> I would like to sharpen my argument from below a little bit: If a CA >> gets a request to issue a certificate for the domain >> xn--gau-7ka.siemens.de, how can the CA tell, that xn--gau-7ka is a >> punycode string in IDNA2008 and not only a very strange server name? >> At least I don't have a glass bowl to read the mind of my customers. >> Therefor I would say, it is perfectly okay to issue a certificate for >> xn--gau-7ka.siemens.de as long as you perform a successful domain >> validation for xn--gau-7ka.siemens.de. > > 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.
Hi Kurt. BRs 7.1.4.2.2 says that the subject:commonName "MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate’s subjectAltName extension (see Section 7.1.4.2.1)." Fitting the U-label into subjectAltName:dNSName (an IA5String, not a UTF8String) would be...hard, so in practice the dNSName has to contain the A-label. So what does "is one of the values" mean? It's certainly valid to use the A-label in both the CN and SAN:dNSName. However, it's arguably invalid (or at least it's not obviously valid) to put the A-label in the SAN:dNSName and the corresponding U-label in the CN. (i.e., the U-label and the A-label are different representations of the same value, but they are not the same value). This issue is one of the things that CABForum ballot 202 sought to clarify, and IIRC it was actually the reason why ballot 202 failed. > And if > you create a commonName then, you are required to check that it matches > the xn--gau-7ka.siemens.de in the SAN. > > > Kurt -- Rob Stradling Senior Research & Development Scientist Sectigo Limited _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
