Re: PKCS#11 URI slot attributes & last call

Patrik Fältström <> Wed, 31 December 2014 07:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7AF6F1A1B3E; Tue, 30 Dec 2014 23:33:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.961
X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oxMiBVpR-TwK; Tue, 30 Dec 2014 23:33:31 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 52C8C1A01C6; Tue, 30 Dec 2014 23:33:31 -0800 (PST)
Received: from [IPv6:2a02:80:3ffc::2052:de55:8a05:c974] (unknown [IPv6:2a02:80:3ffc:0:2052:de55:8a05:c974]) by (Postfix) with ESMTPSA id 0964A22720; Wed, 31 Dec 2014 08:33:29 +0100 (CET)
Subject: Re: PKCS#11 URI slot attributes & last call
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Content-Type: multipart/signed; boundary="Apple-Mail=_617DFA80-0015-42AF-9A0A-05FD15F8B4F8"; protocol="application/pgp-signature"; micalg=pgp-sha1
X-Pgp-Agent: GPGMail 2.5b4
From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= <>
In-Reply-To: <20141231070328.GK24442@localhost>
Date: Wed, 31 Dec 2014 08:33:28 +0100
Message-Id: <>
References: <alpine.GSO.2.00.1412161359100.4549@keflavik> <> <20141217230150.GB9443@localhost> <alpine.GSO.2.00.1412171513520.4549@keflavik> <> <alpine.GSO.2.00.1412292234010.1509@keflavik> <> <alpine.GSO.2.00.1412300946340.4549@keflavik> <> <> <20141231070328.GK24442@localhost>
To: Nico Williams <>
X-Mailer: Apple Mail (2.1993)
Cc: Darren J Moffat <>, "" <>, Jan Pechanec <>, "" <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 31 Dec 2014 07:33:33 -0000

> On 31 dec 2014, at 08:03, Nico Williams <> wrote:
> On Wed, Dec 31, 2014 at 07:29:47AM +0100, Patrik Fältström wrote:
>>> On 30 dec 2014, at 20:53, Nico Williams <> wrote:
>>> Better say
>>> nothing, because I think the thing to do is obvious enough, but if we
>>> must say anything, it's that the various strings (e.g., token manuf)
>>> are to be compared normalization-insensitively.
>> Sorry, but I have not heard the term "normalization-insensitively" before.
>> Can you explain what you mean?
> Notionally, if you're comparing two unnormalized strings, you could
> normalize both then compare the two normalized strings.
> Of course, that can be inefficient (e.g., if it means allocating memory,
> of if they will prove not equal in the first few codepoints) or
> infeasible (e.g., if one of the strings is actually a hashed key to a
> hash table).
> What you can for the first case is compare code-unit by code-unit, with
> a fast path for the cases that need no normalization, and normalizing
> one character (but possibly multiple codepoints, of course) at a time.
> This limits the total memory consumption, and anyways, for the common
> case you can often expect an inequality result long before you're done
> traversing the shorter string.  This is (can be, if you do it right), of
> course, equivalent to normalizing both strings then comparing -- but it
> should usually be much faster.
> For the second case the thing to do is to normalize the key at hash
> time, naturally.
> [ZFS, incidentally, supports this for filesystem object names, and has
> for years now.]
> Now, PKCS#11 nowadays supports UTF-8 for things like "token label", but
> it doesn't say anything about form -- why should it (see below)?
> But where PKCS#11 URIs are intended to _match_ PKCS#11 resources by
> name... apps will need to care about normalization.  In practice, like a
> great many applications, doing nothing about normalization will probably
> work fine (until the day that it doesn't).  But saying anything about
> this could be tricky: what if there are two tokens with equivalent
> labels, just in different forms?  Fortunately PKCS#11 URIs can match on
> more attributes than labels, so there's that.
> PKCS#11 should say "don't do that" or "don't do that, normalize to NFC"
> (or NFD, whatever), but doesn't (or I didn't find where it does, if it
> does), so the most that this document could say is "compare
> normalization-insensitively where possible".

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?

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.