NF* (Re: PKCS#11 URI slot attributes & last call)

Nico Williams <nico@cryptonector.com> Wed, 31 December 2014 07:46 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9921A6EEF; Tue, 30 Dec 2014 23:46:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.334
X-Spam-Level: *
X-Spam-Status: No, score=1.334 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyiZa0TrjgCa; Tue, 30 Dec 2014 23:46:47 -0800 (PST)
Received: from homiemail-a70.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id F26F21A01C6; Tue, 30 Dec 2014 23:46:46 -0800 (PST)
Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id B1DFE768059; Tue, 30 Dec 2014 23:46:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=wjRwwh+sNwNhSJ5Roxm/S1YIoDo=; b=SDOgEjQaFV/ gBNkwj6PUWJY0gW6JsJLUL9ZoNuTXjj8WjJQdNxL/fK8COfIBJkpIJup2P11s67k Zca6tDDQ9X7ix5cYbtXKbVgY/bLtDSr+BaVCEdQD+u+FOVIf5enGIWZ8KE/l9uvy i5Pj9K5IbzrI9ptrIq/QN7kDO3lAve4E=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPA id 407B8768057; Tue, 30 Dec 2014 23:46:46 -0800 (PST)
Date: Wed, 31 Dec 2014 01:46:45 -0600
From: Nico Williams <nico@cryptonector.com>
To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= <paf@frobbit.se>
Subject: NF* (Re: PKCS#11 URI slot attributes & last call)
Message-ID: <20141231074641.GM24442@localhost>
References: <20141217230150.GB9443@localhost> <alpine.GSO.2.00.1412171513520.4549@keflavik> <CAK3OfOjnRCmiu-TKCJ-AFanpCsqnw1o2w_EC2AKMUnQ2A4DqVw@mail.gmail.com> <alpine.GSO.2.00.1412292234010.1509@keflavik> <CAK3OfOgm_ZYj-rY+4ExZzY8KY4G3rz2KLrZ8hQJi7ZUR4yiP0Q@mail.gmail.com> <alpine.GSO.2.00.1412300946340.4549@keflavik> <CAK3OfOha9qu=uDtqwDTdV78waLMaorYq0T6cq1YX3VzQn2OpKA@mail.gmail.com> <A4CC6CEC-D17E-4235-B615-9D2AD88096D4@frobbit.se> <20141231070328.GK24442@localhost> <B08B813F-B8B4-49F1-A0B9-60F322C8E9C7@frobbit.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <B08B813F-B8B4-49F1-A0B9-60F322C8E9C7@frobbit.se>
User-Agent: Mutt/1.5.21 (2010-09-15)
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/u_AWZ8mFT6i4ccFkDKR4Q44sc4c
Cc: Darren J Moffat <Darren.Moffat@oracle.com>, "saag@ietf.org" <saag@ietf.org>, Jan Pechanec <jan.pechanec@oracle.com>, "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Dec 2014 07:46:48 -0000

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
--