在 2019年1月25日星期五 UTC+8上午3:19:42,Tim Hollebeek写道:
> I think the assertion that the commonName has anything to do with what the
> user would type and expect to see is unsupported by any of the relevant
> standards, and as Rob noted, having it be different from the SAN strings is 
> not in compliance with the Baseline Requirements.  It's also deprecated.  If 
> anything, it should cease to exist.
> 
> Requiring translation to a U-label by the CA adds a lot of additional 
> complexity
> with no benefit.
> 
> What users type and see are issues that are best left to Application Software
> Suppliers (browsers).
> 
> -Tim
> 
> > -----Original Message-----
> > From: dev-security-policy <[email protected]>
> > On Behalf Of Kurt Roeckx via dev-security-policy
> > Sent: Thursday, January 24, 2019 4:04 AM
> > To: [email protected]
> > Subject: Re: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded
> > international domain names
> > 
> > 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. 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
> > _______________________________________________
> > dev-security-policy mailing list
> > [email protected]
> > https://clicktime.symantec.com/36Cdb8NdVuWoSCnRVsmajRE7Vc?u=https
> > %3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy

It seems like that the commonName should be one of the values of the dNSNames 
in the SAN to comply with the requirements of BR, though the different values 
are for the same domain name and the U-label reads more easily. 
Can BR add an exception for the Non-English domain names? Will this lead to 
some risks that I didn't think of? 

In my opinion, a subscriber will need more time to manage them and it is easier 
to make mistakes if he has serveral certificates with both unreadable 
commonName and SAN.
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to