On Wed, Dec 31, 2014 at 08:33:28AM +0100, Patrik Fältström wrote:
Ok, so what you say is that the side that is to calculate whether
there is a match or not can do whatever normalization they want on the
string(s)? Or do you say that whoever is doing a match is to not do
normalization at all as the application (on client side) can and
should define what normalization (in a broader sense, not only Unicode
Normalization) must be possible to define?
I'm saying something subtly different:
When you don't have the luxury of every string you might chance upon
being required to be normalized to the one true form, then you have
three choices:
- give up
- go fix whatever needs to be fixed so that you do have that luxury
Here that would be: PKCS#11 itself, token vendors, and so on.
I.e., not quite boiling the oceans but maybe a Great lake.
- try your best
Normalization-insensitive comparison falls into the third bucket.
In IDNA2008, as you know, we did choose the latter, but recommend
applications to define what normalization to do, and that NFC is the
Unicode Normalization to use.
For another example, in the world of filesystems we have:
- most of the world just-uses-8 (UTF-8, ISO-8859-*, whatever, and when
UTF-8, form is accidental)
- some of the world insists on UTF-8 (though it's hard for a filesystem
to enforce this: all it sees is octet strings)
- some of the world normalizes to NFD (close enough) on create and
lookup (e.g., HFS+)
- some of the world is normalization-preserving-but-form-insensitive
(ZFS)
The NFD case is obnoxious because even on those systems the input system
tends to produce NFC... But anyways. When you have no canonical form
for whatever reason, you can try form-insensitive matching.
Obviously there's aliasing to consider (but there is anyways), and so
on. But none of this is terribly interesting here except for the "best
effort matching" idea, since that's probably the user-friendly and
not-too-dangerous thing to do here.
Nico
--