Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call))

[John C Klensin <[e-mail]>]

--On Monday, January 12, 2015 09:39 +0100 Randy Bush
<[e-mail]> wrote:

>> I'd go even further than that and just mandate MUST ASCII.
>> This is a simple means of pointing to a PKCS #11 object, not
>> a universal means of communicating abstract concepts in any
>> language known to man.  We've already gone from "specify a
>> path to load a PKCS #11 module" to something that's fast
>> heading towards being Turing-complete, if it isn't already
> 
> can you say "attack surface?"
> 
> http://www.cs.dartmouth.edu/~sergey/langsec/

Randy,

As I'm certain you know but others reading this probably don't,
this is symptomatic of an extremely general problem with i18n.
As with "more security" or "more privacy", "internationalization
good, ASCII-only bad" can easily pass from a legitimate and
important issue and goal into slogans and political correctness.
The problem is almost identical to the security one: doing
things well is hard, retrofitting into something that wasn't
designed with security/i18n in mind is _much_ harder, and there
is a permanent shortage of both pixie dust and magical
invocations with sufficient power to solve the problems.

As with protocols designed without security, taking something
that was designed for ASCII and with no thought for i18n issues,
either becomes a matter of very careful analysis or, as you
suggest, crude efforts to retrofit something don't solve the
i18n problems and, as you point out, often broaden the attack
surface.  We really need to get better at asking whether a given
piece of protocol actually needs characters outside the ASCII
repertoire and, if it does, to find the expertise and make the
investments needed to get it right.

Security-related protocols that increase the security risks,
whether in the name of i18n or something else, do not appear to
me to be the way we should be going.

It is clear to me that investment hasn't been made here.  It is
almost as clear that the problem lies with the PKCS specs and
not with this particular document.    What to do about it is
another matter, but it seems to me that "ASCII only until
PKCS#11 itself is adequately revised" is a plausible possibility.

best,
    john