Re: PKCS#11 URI slot attributes & last call

Nico Williams <> Wed, 31 December 2014 07:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4BD521A8A94; Tue, 30 Dec 2014 23:03:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uW9DXNmaEjjs; Tue, 30 Dec 2014 23:03:35 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E8D0B1A8A8D; Tue, 30 Dec 2014 23:03:34 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 8888E584065; Tue, 30 Dec 2014 23:03:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s=; bh=N4mmWNknQi5g41zd4s+OVw1iBKg=; b=m2freedPunC o2G6v6IqnN5i6ElCB/FkD/Q7gk4Bd6ShH6MsoW7KIWm1Ci55AdsekgQSUjMXauCh qyBYsioKLwpSpJ4tfawcJHKFI7G62KxX3SAWirEA5Aq+Q5+AEYwuhD4XTyTh1IIz PLiFKq6u+NpxoUeXDPYONA4045i1CurI=
Received: from localhost ( []) (Authenticated sender: by (Postfix) with ESMTPA id 09733584064; Tue, 30 Dec 2014 23:03:33 -0800 (PST)
Date: Wed, 31 Dec 2014 01:03:33 -0600
From: Nico Williams <>
To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= <>
Subject: Re: PKCS#11 URI slot attributes & last call
Message-ID: <20141231070328.GK24442@localhost>
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> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Content-Transfer-Encoding: quoted-printable
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:03:36 -0000

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