--On Monday, January 12, 2015 18:08 -0600 Nico Williams
<nico(_at_)cryptonector(_dot_)com> wrote:
Given that this particular member of the IESG has
(successfully) argued vehemently for ASCII-only on multiple
occasions in the recent past, I would say that your worries
on that score are overdone. :-)
Well alright. I'd love to see a set of guidelines for I18N
activities.
So would we all. RFC 2277 was supposed to provide some guidance
but is now badly obsolete in many different ways, including
exhibiting how little we knew about some things at the time. We
have, I hope, learned a lot, but see below.
When should we try to support Unicode, and when should we not?
Is it one of those "I know it when I see it" kinds of
guidelines? That wouldn't be useful enough :(
Let me suggest a general way of thinking about things -- maybe
not quite a "guideline". Especially for security-type
protocols, make sure there is a substantive reason, presumably
connected to users and user experience, for it to be necessary
to go beyond ASCII. I really do mean "necessary": if it is just
a good idea in principle or a maybe-nice-to-have or "maybe
someone will want this some day", skip it because adding i18n
capabilities _will_ make correct and predictable implementations
more difficult and _will_ increase the number and range of
attack opportunities.
Mind you, IIRC PKCS#11 didn't even say anything about ASCII
before. Token labels and such used to be fixed-sized octet
strings containing character data. Jan can correct me if I'm
wrong. I'm not sure even saying "ASCII-only" would
necessarily be safe in that case...
And that reinforces my view that the real, underlying, problem
here has to be fixed in PKCS#11, not in anything the IETF puts
on top of it. Only they can fix the problems; we can, at best,
mitigate the damage.
Fortunately the OASIS PKCS11 TC has clarified that these are
UTF-8; unfortunately they left other I18N details out.
It appears to me that what they have said puts their level of
understanding of the various issues somewhat behind where we
were when RFC 2277 was written in 1997.
john