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

Nico Williams <> Wed, 31 December 2014 08:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 540B51A8AA3; Wed, 31 Dec 2014 00:25:58 -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 VP25m5r4cShP; Wed, 31 Dec 2014 00:25:57 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 14D1C1A8AA0; Wed, 31 Dec 2014 00:25:57 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id E205E678062; Wed, 31 Dec 2014 00:25:56 -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=k8NTKmT0EYBCyr9S7K77JnDCzBM=; b=ysZzu2VFlGI cHFf4Nf/EU+wweU8ZBcarIqZ01fNVSeAILJ4TD6UFk2AHRuMQn590gY0dS3LqhGQ Xd1p/ebAPavhzQ1svubKF0uH8JgqP9mHFjOFgEMXjCf5pkCBzfvomgzdEmwfqiYV oHOOCpSCVc4pgqLQClGNYFuottYD9BuY=
Received: from localhost ( []) (Authenticated sender: by (Postfix) with ESMTPA id 6CAEC678058; Wed, 31 Dec 2014 00:25:56 -0800 (PST)
Date: Wed, 31 Dec 2014 02:25:55 -0600
From: Nico Williams <>
To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= <>
Subject: Re: NF* (Re: PKCS#11 URI slot attributes & last call)
Message-ID: <20141231082551.GN24442@localhost>
References: <> <alpine.GSO.2.00.1412292234010.1509@keflavik> <> <alpine.GSO.2.00.1412300946340.4549@keflavik> <> <> <20141231070328.GK24442@localhost> <> <20141231074641.GM24442@localhost> <>
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 08:25:58 -0000

On Wed, Dec 31, 2014 at 08:54:00AM +0100, Patrik Fältström wrote:
> What I think is then needed is for this case:
> 1. A simple explanation what you really is talking about
> What is the requirement on whom regarding normalization/mapping/whatever?

The I-D in question defines a URI scheme for PKCS#11 resources some of
whose naming attributes are character strings which PKCS#11 says should
be UTF-8.  PKCS#11 (*not* an Internet standard) does not say anything
about form.  Should this I-D say anything about form?

IMO the most it should say is "PKCS#11 doesn't specify a canonical form
for these labels, therefore the application may need to canonicalize
prior to comparing them".  The alternative is to say nothing.

PKCS#11 is an API.  PKCS#11 apps might "interoperate" using PKCS#11 URIs
communicated over, e.g., IPC (or plain old cut-n-paste).

PKC#11 URI _templates_ might well be exchanged far and wide, but still
not really as a part of a network protocol.

> The tricky part regarding choice of normalization (together with
> selection of code points allowed) is of course whether false positives
> or false negatives is the most troublesome event when trying to do
> matching.

This can be true even if we say nothing.

> Let me just be clear here, I am very much in favor of specifications
> that say that "server side matching" should NOT do normalization, as
> that give most freedom for the applications that use whatever

Where this works for filesystems, it is by accident: because input
methods "agree" on a canonical form for inputs.

As you know it actually doesn't work that well for filesystems:
"clients" (e.g., a program using a POSIX open() function) don't do
anything about normalization.  Neither do C library/run-time system call
stubs.  Neither do kernels.  Neither do <pick networked fs protocol>
clients.  They just don't.  Why would they?  These systems have lineages
much older than Unicode.

For IDNA, of course, the DNS client application has to canonicalize.

IOW, what to do depends on the application.  For filesystems I say: be
form-preserving-form-insensitive.  For IDNA there's no choice but to go
with clients-must-normalize.  Each app will be different.

> mechanism is defined. But, that to me set requirements on "client
> side" to do the right thing (for example like in IDNA2008 only be
> allowed to use certain code points).
> So, given your choice on server side matching, what are the
> requirements on client side?

There's no network protocol here.  There's an API and applications
interoperating over IPC ("cut-n-paste").

Of course, the issues are the same, it's just that there's no "server"
to consider.  It's all as good as "clients".  Unlike IDNA, it's all
UTF-8, all the time, so that form-insensitive can work.