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

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5DE5F1A8AA9; Wed, 31 Dec 2014 01:09:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.261
X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G_2BSnJj7X8C; Wed, 31 Dec 2014 01:09:43 -0800 (PST)
Received: from ( [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4A5BB1A8760; Wed, 31 Dec 2014 01:09:43 -0800 (PST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id B00811FD32; Wed, 31 Dec 2014 10:09:40 +0100 (CET)
Subject: Re: NF* (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=_E760699F-2F5B-461D-BAD0-D507440D1D87"; 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: <20141231082551.GN24442@localhost>
Date: Wed, 31 Dec 2014 10:09:39 +0100
Message-Id: <>
References: <> <alpine.GSO.2.00.1412292234010.1509@keflavik> <> <alpine.GSO.2.00.1412300946340.4549@keflavik> <> <> <20141231070328.GK24442@localhost> <> <20141231074641.GM24442@localhost> <> <20141231082551.GN24442@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 09:09:47 -0000

> On 31 Dec 2014, at 09:25, Nico Williams <> wrote:
>> 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.

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.

So the issues are the same.

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.

Look at UTF-8 for example.

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.

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,...)?

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.