Thanks for reviewing the IDNA text Pete.
> I really, truly wish we could avoid all reference to 5895 and UTS46.
> (And this comes from a co-author of the former.) Basically, those
> documents are about taking user (or other sorts of "unwashed" input) and
> doing something 'magic' before handing it to something that expects
> proper IDNs. Really, I'd like this kind of protocol document to say,
> "What goes is this field is something that is properly pre-processed by
> whatever handed it to us and if it's bogus, we're not going to do
> anything to 'help' it."
Note that that's what this spec attempts to do in the intro to section 7..
> This processing model assumes that the UA implements IDNA2008
> [RFC5890], or possibly IDNA2003 [RFC3490], as noted in Section 11
> "Internationalized Domain Names for Applications (IDNA): Dependency
> and Migration". It also assumes that all domain names manipulated in
> this specification's context are already IDNA-canonicalized as
> outlined in Section 8 "Domain Name IDNA-Canonicalization" prior to
> the processing specified in this section.
>
> The above assumptions mean that this processing model also
> specifically assumes that appropriate IDNA and Unicode validations
> and character list testing have occured on the domain names, in
> conjunction with their IDNA-canonicalization, prior to the processing
> specified in this section. See the IDNA-specific security
> considerations in Section 13.2 "Internationalized Domain Names" for
> rationale and further details.
> But I understand that this may be "happy
> thoughts". If you really can't avoid talking about user input processing
> in this document, I will hold my nose and say no more about it.
yeah, sigh: lacking a more generalized spec laying out all that subsumed
detail, it seems prudent (from a completeness perspective, at least) to include
it. (I brought up concocting such a generalized
how-shud-app-protocols-do-IDNA(-during-"transition-from-IDNA2003-to-2008") spec
in the precis WG meeting in Taipei ietf-82, but there was a fair bit of
pushback on the notion there)
But, if the ADs and IESG were to decide we could get by without such language
(i.e. section 10 IDNA: Dependency and Migration) in this spec we could excise
it. (I'll leave it in for now)
thanks again,
=JeffH
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
