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

Nico Williams <> Wed, 31 December 2014 09:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6788A1A8AA9; Wed, 31 Dec 2014 01:19:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.034
X-Spam-Status: No, score=0.034 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 602DgA5hQ8U8; Wed, 31 Dec 2014 01:19:12 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 36E8B1A8768; Wed, 31 Dec 2014 01:19:12 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id C25844012D694; Wed, 31 Dec 2014 01:19:11 -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=ZSS0v1pOURfSEzKxCbjmEPJ5k6s=; b=po2kEdZfViu 7bUMp9u0oZ4JhDTJPuY30KK8hgW3A+lj7X+pP2HTYMA5v1yjhIZA7746kOgUgASg KTrivnEs0C2Ls+I7EaBCUWp6vFsFRtrWDugO23X+5IEiPHRNEDYcYKliV/5yP79f t67KYTonkg04zP9IVTWgDADEda3PFD5A=
Received: from localhost ( []) (Authenticated sender: by (Postfix) with ESMTPA id 4F1354012D68E; Wed, 31 Dec 2014 01:19:11 -0800 (PST)
Date: Wed, 31 Dec 2014 03:19:10 -0600
From: Nico Williams <>
To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= <>
Subject: Re: NF* (Re: PKCS#11 URI slot attributes & last call)
Message-ID: <20141231091906.GO24442@localhost>
References: <> <alpine.GSO.2.00.1412300946340.4549@keflavik> <> <> <20141231070328.GK24442@localhost> <> <20141231074641.GM24442@localhost> <> <20141231082551.GN24442@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 09:19:13 -0000

On Wed, Dec 31, 2014 at 10:09:39AM +0100, Patrik Fältström wrote:
> > On 31 Dec 2014, at 09:25, Nico Williams <> wrote:
> > 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.
> Well, the definition of a URI like in this case in reality define a
> protocol with a client and server, if we think about the case when the
> URI is used. Someone create a URI (by typing, speaking, OCR:ing,
> copying) and use it to reach a resource.

As with filesystems, the "processes" creating and accessing the resource
are all clients.  There are no servers that can make right, therefore we
might as well not speak of them :)

(We're agreeing.)

> Regarding "the PKCS#11 does not talk about the issue, so why would
> IETF" is a question I think has a clear answer. IETF have in many
> cases created profiles, or let me say "interpretations" of definitions
> made elsewhere. Simply because IETF do not think the specification is
> crisp enough.

Yes.  The question is whether we should in this case.

I'm in favor of saying "do form-insensitive comparison".  I'd settle for
"always normalize to NFC when creating PKCS#11 resources" because, after
all, that's what IRIs need anyways, it's just that a PKCS#11 URI-using
app might not be in a position to make "normalize on create" happen.

OTOH, I think this is a minor issue, so if reaching consensus is hard,
then I say "say nothing", normatively anyways.

However, you're right that as far as Security Considerations go, we
can't say nothing.

> Look at UTF-8 for example.

Indeed.  We make things better.

> You also write:
> > 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.
> Sure, that is my point.

Yes, we agree :)

> What you say is that the IETF use of PKCS#11, without any
> specification of normalisation, mapping or otherwise, will not have
> any security implications what so ever regardless of what an
> application do (i.e. one party participating using one normalisation
> form, another do PRECIS mapping, a third do NFC,...)?

No, it will have security considerations regardless.

The only way to help that is to force normalization on create, but as I
say, that's not something this spec can cause to happen or assume has

> That is what I see you write, and if either I understand you wrong, or
> if that is not what you are saying, then a text must be created and
> added that explain the pitfalls -- at least as part of the security
> considerations section if not in the specification on how PKCS#11 is
> to be used.