On 25/01/2019 16:06, Tim Hollebeek wrote: > >> 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. >
Not as much a bug, as a previous specification. In other words, backwards compatibility with old systems and software predating the full migration to SAN-only checking in modern clients. As with all backwards compatibility, it is about interoperating with systems that followed the common standards and practices of their time, as they were. While the Python library mentioned apparently failed to match any valid IDNA SAN value to any actual IDNA host name, the much more common case is software that will process the A-label as an ASCII string and compare it to either the CN or the list of SAN values. One such example is GNU Wget, which is sometimes used to bootstrap the downloading of updated client software (by typing/pasting a known URL). GNU Wget was notably slow in implementing SAN support, doing only the matching of host name to CN. For some compile options, SAN checking of host names was implemented as recently as the year 2014. For this and other cases this old, putting the A-label in CN (if the subscriber chosen "most important to match name" is a DNSname) or putting the IP address in CN (if the most important to match name is an IPname). In either case, I suspect (but have no data) that using the lower case (ASCII lower case) name form will be the most compatible choice. If the subscriber does not specify which name is most important, choose the first DNS/IP name in the subscriber input, unless a later name is a wildcard that also matched that first name. Ideally, the subscriber would indicate all desired choices directly in the CSR, but in practice, most subscribers will use broken scripts to generate the CSR, not a carefully crafted filled in template. Example, if the subscriber fills out the human readable order form like this: www.example.com chat.example.com example.com detteerenprøve.example.com www.example.net example.net *.eXample.com *.examPle.nEt 192.0.2.3 the best choice is probably CN=*.example.com which is one of the SANs and is a wildcard covering the first SAN (www.example.com). The BRs do not require a specific choice among the 9 SANs that would go in the certificate (all of which must of cause be validated). The user entered U-label detteerenprøve.example.com must of cause be converted to A-label xn--detteerenprve-lnb.example.com before checking and encoding. This way, out of the correct uses of the certificate, only the example.net names and the IP address would not be accepted by older software. The clients of cause usually checks only CN or only SAN, it's the CA that deals with the complexity of trying to please everyone without harming anyone. >> 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 > Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
