Re: [Idna-update] emoji and security

[Asmus Freytag <[e-mail]>]

On 3/13/2018 1:44 PM, Michel Suignard wrote:
> <<
> If the general-category approach to IDNA2008 was unsuitable in 2008 because it yielded examples of things that should never in principle be identifiers, I wish someone would have made that argument.  I do not recall it having been made, and I believe I participated pretty avidly.  I do recall some people arguing that various archaic things were "not needed" or "almost always unusable by anyone", but that would have put us in the situation of going through everything one code point at a time.  There were some who wanted to try to re-do
> IDNA2003 only updated for then-current versions of Unicode, but I think experience shows that wouldn't have worked out too well either.
> No, I still think in context, general-category approach was the best approach possible, short of developing a new category which was unpalatable to most. As you correctly pointed out in your answer in my comment about Egyptian hieroglyphs, these may be used in limited-use identifier context (for example if you want to identify base Old Egyptian phonemes) but with some caveat.

The design of IDNA2008 reflects two or three conflicting thrusts:

1) it was intended to be updatable to newer versions by simply applying 
the properties, with using an exception list as a fail-safe.
2) it was intended to avoid clear-cut cases of dual encoding (via 
normalization)
3) it was intended to be usable on all levels of the tree - therefore it 
could not be maximally restrictive

It would have been easy to restrict IDNA 2008 to modern scripts only - 
the number of scripts that are in actual modern use of significance for 
network identifiers is not something that changes based on Unicode 
version (there really aren't any unencoded ones left in that category). 
They could have been enumerated and their script properties be used to 
filter the code points.

That was seen as too restrictive - and it's not worth arguing about 
whether that was the wrong or correct thing to do.

However, many non-modern scripts are really not suitable for general 
identifiers: there's not a body of working expertise on where the 
problems are with them. It's arguable that they should (have been) kept 
out of second level domains altogether, because nobody who includes them 
in a registry can be said to have done so understanding the 
consequences, therefore implicitly violating the prescription in RFC 5891.

Yet they are perfectly fine on some 3rd or 4th level, for example any 
level, where the same entity controls all labels and there therefore 
can't be a risk from spoofing, etc.

Now, given that the protocol as a whole is that permissive, and given 
that there are some dozens of outright homographs even in the modern 
scripts, and have been from 2008 (not to mention hundreds if not 
thousands of rather similar-looking code points), it's bordering on the 
absurd to stop all work on updating IDNA 2008 over the case of a single 
Arabic addition that isn't even an exact homoglyph (fonts that I have 
researched tend to bind the precomposed mark more tightly to the 
skeleton than an independent code point having the same shape as the mark).

So, Michel's question is relevant:

>
> Still, what needs to happen to unlock the IANA IDN table from being frozen at Unicode 6.3? Unicode 11.0 is months away. I don't think anyone wants to revise the protocol (IDNA 2008), can't we just agree that the protocol is not 100% failsafe and move on? Documenting the problematic cases outside the protocol seems to me the best way to proceed. And it should not be a gating factor in letting IANA revise their table (although it would be great if that documentation was progressing).
So, let's get back to that discussion.

A./
>
> Best regards
>
> Michel
> _______________________________________________
> IDNA-UPDATE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idna-update
>