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

John C Klensin <> Fri, 02 January 2015 14:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E3E621A8750; Fri, 2 Jan 2015 06:30:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.401
X-Spam-Level: *
X-Spam-Status: No, score=1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HCw0JK_8kQQL; Fri, 2 Jan 2015 06:30:32 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 071E31A874F; Fri, 2 Jan 2015 06:30:32 -0800 (PST)
Received: from ([] helo=P5) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1Y73FD-0001E3-L2; Fri, 02 Jan 2015 09:30:27 -0500
Date: Fri, 02 Jan 2015 09:30:22 -0500
From: John C Klensin <>
To: Patrik Fältström <>, Nico Williams <>
Subject: Re: i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call))
Message-ID: <881FA95C72F0C69B513D143E@P5>
In-Reply-To: <>
References: <> <alpine.GSO.2.00.1412300946340.4549@keflavik> <> <> <20141231070328.GK24442@localhost> <> <20141231074641.GM24442@localhost> <> <20141231082551.GN24442@localhost> <E4837FDB76D5ACDEB1C568DF@[]> <20150102030130.GN24442@localhost> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
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: Fri, 02 Jan 2015 14:30:37 -0000

--On Friday, 02 January, 2015 07:57 +0100 Patrik Fältström
<> wrote:

> For the record, I like what is suggested the below.

Wfm, but please note the other comments in my prior note.  To
summarize, normalization is not the only issue.  Even for some
normalization cases, NFC is not the cure.  For example, NFKC is
needed to rationalize characters of various widths but causes
problems elsewhere.  So, I would suggest some additional words
that say, more or less, that, until PKCS#11 is revised to be
clear about how to handle characters outside the ASCII
repertoire, those who discover a need to use such characters
should be cautious, conservative, and expend extra effort to be
sure they know what they are doing and that failure to do so
will create both operational and security risks.

>> I think we could use some text like this:
>>   PKCS#11 does not specify a canonical from for UTF-8 string
>>   slots in the API.  This presents the usual false negative
>>   and false positive (aliasing) concerns that arise when
>>   dealing with unnormalized strings.  Because all PKCS#11