--On Wednesday, January 3, 2024 11:31 +0900 Takahiro NEMOTO <nemo@xxxxxxxxxxxxx> wrote: > Dear Russ, > > Thank you for your consideration regarding my comment. > I agree with your suggestions. > > Regards, > Nemo > >> 2024/01/03 3:58、Russ Housley >> <housley@xxxxxxxxxxxx>のメール: >> >> Thanks for the review. I suggest: >> >> Conforming CAs SHOULD ensure that IDNs are valid according >> to IDNA2008, which is defined in [RFC5892] and updated by >> [RFC8753]. This can be done by verifying all code points >> against [IDNA-Tables]. Failure to use valid A-labels may >> yield a domain name that cannot be correctly represented in >> the Domain Name System (DNS). In addition, the CA/Browser >> Forum offers some guidance regarding internal server names >> in certificates [CABF]. >> >> [IDNA-Tables] >> "IDNA Rules and Derived Property Values", 4 >> April 2022, >> <https://www.iana.org/assignments/idna-tables>. Russ, Takahiro, Not quite good enough. IDNA2008 defines A-label (and hence U-label) validity according to a set of rules [1], for which code-point checking against the IANA registry is just one. So, at least, change: Old: valid according to IDNA2008, which is defined in [RFC5892] and updated by [RFC8753]. This can be done by verifying all code points against [IDNA-Tables]. New (minimal): valid according to IDNA2008, which is defined in [RFC5890] through [RFC5894] and updates to them. (dropping the second sentence entirely). If you want to list the updates, you need to reference RFCs 6452 as well as 8753. 8753 does not obsolete 6452; to the extent that 8753 updates the tables, it is for changes between Unicode 6.0 (covered by RFC 6452) and Unicode 12.0, including some changes documented in Internet-Drafts that never formally reached IETF consensus and therefore were not published as RFCs (see Sections 3.1 and 4 of RFC 8753 for more of an explanation). This is further complicated by the observations that Unicode is now on version 15.1.0 [2], that there have been no updates since RFC 8753 for those versions, and, in particular, that the analysis required by Section 3.2 of RFC 8753 has not been performed and documented for versions after 12.0. As with the parallel discussion about Security Considerations in this thread, one could write much more text than the above to better inform readers who do not want to dig into the IDNA2008 specifications. Whether it would be a good idea and whether enough could be put into this document to be both accurate and sufficient is a question to which I don't know the answer. But, if we are not going to have a complete, accurate, and self-contained explanation, let's not pretend (as Russ's proposed text accidentally does). best, john [1] RFC 5981 Sections 4 and 5 provide a fairly good overview of the rules. I would recommend that, for determination of validity for certificate use, the more stringent "registration" rules of Section 4 (really 4.1 through 4.3) be followed. [1] https://www.unicode.org/versions/Unicode15.1.0/ -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
