> On 2019-01-24 20:19, Tim Hollebeek wrote: > > 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. > > The BR do not say anything about it.
Rob already quoted it: "If present, this field MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's subjectAltName extension". The only reason it's allowed at all is because certain legacy software implementations would choke if it were missing. > > Requiring translation to a U-label by the CA adds a lot of additional > > complexity with no benefit. > > I have no idea what is so complex about that. When generating the > certificate, it's really just calling a function. On the other hand, when reading > a certificate you have to guess what they did. Given that it has no benefit at all, any complexity is too much. As I mentioned above, its existence is merely a workaround for a bug in obsolete software. > And if it's really to complex, just remove the CN, or is that too complex too? See above. > > What users type and see are issues that are best left to Application > > Software Suppliers (browsers). > > So you're saying all the other software that deals with certificates should > instead add complexity? What they actually do is to ignore this obsolete field, and process the subjectAltNames. There's no additional complexity for them because they already are doing the conversion of IDN names. -Tim
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
