John, Thank you for raising important points. I thought a code point table would be necessary for verification, and I suggested adding the IANA page. But, as you pointed out, the checking is only one in a set of rules, and I understood that it may be somewhat misleading to readers who have not carefully read the IDNA2008 specifications. On the other hand, aiming to include enough accurate information may complicate the maintenance of this document. Therefore, I agree with your suggestion to describe the minimum version necessary. Russ, I know you have already corrected it to -02 to reflect my comments. But please consider replacing the relevant text with the version John suggests again. > 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. Best, Nemo > 2024/01/04 7:05、John C Klensin <john-ietf@xxxxxxx>のメール: > > > > --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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
