On 25/01/2019 19:23, Buschart, Rufus wrote:
Hello Jakob!-----Ursprüngliche Nachricht----- Von: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> Im Auftrag von Jakob Bohm via dev-security-policy Gesendet: Freitag, 25. Januar 2019 18:47 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.If a CA receives such a list and creates the CSR for the customer (how does the CA this without access to the customers private key?), they have of course to perform an IDNA translation from U-label to A-label. And as we have learned the BRGs (indirectly) enforce the use of IDNA2003. But if the CA receives a filled in CSR they don't perform (not even indirectly) an IDNA translation and has no obligation to check if the entries are valid IDNA2003 A-label.
I was not suggesting that the CA creates the CSR. I was simply suggesting the common practice of the CA using the CSR mostly as a "proof of possession" of the private key, but not as a precise specification of the desired certificate contents. For example, a CSR may (due to old tools or human error) contain additional subject DN elements (such as eMailAddress). Of cause the CSR can't be completely different from the requested certificate, as that would be open to a man-in-the-middle attack where an attacker submits the victim's CSR with a completely unrelated order. 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
