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

Jan Pechanec <jan.pechanec@oracle.com> Thu, 08 January 2015 18:45 UTC

Return-Path: <jan.pechanec@oracle.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF15C1A007D; Thu, 8 Jan 2015 10:45:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.21
X-Spam-Level:
X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCG53B3OcTZk; Thu, 8 Jan 2015 10:45:50 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BB591A006C; Thu, 8 Jan 2015 10:45:50 -0800 (PST)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t08IjhEK010828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Jan 2015 18:45:44 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t08Ijfoq005708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 8 Jan 2015 18:45:42 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t08IjeR4005670; Thu, 8 Jan 2015 18:45:41 GMT
Received: from keflavik.us.oracle.com (/10.132.148.214) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Jan 2015 10:45:40 -0800
Date: Thu, 8 Jan 2015 10:45:38 -0800 (PST)
From: Jan Pechanec <jan.pechanec@oracle.com>
X-X-Sender: jpechane@keflavik
To: John C Klensin <john-ietf@jck.com>
Subject: Re: i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call))
In-Reply-To: <7A38C32D6DB867E71E8F90B4@JcK-HP8200.jck.com>
Message-ID: <alpine.GSO.2.00.1501081022410.8929@keflavik>
References: <CAK3OfOgm_ZYj-rY+4ExZzY8KY4G3rz2KLrZ8hQJi7ZUR4yiP0Q@mail.gmail.com> <alpine.GSO.2.00.1412300946340.4549@keflavik> <CAK3OfOha9qu=uDtqwDTdV78waLMaorYq0T6cq1YX3VzQn2OpKA@mail.gmail.com> <A4CC6CEC-D17E-4235-B615-9D2AD88096D4@frobbit.se> <20141231070328.GK24442@localhost> <B08B813F-B8B4-49F1-A0B9-60F322C8E9C7@frobbit.se> <20141231074641.GM24442@localhost> <947CA101-D717-4B56-8EEE-84B3A53BF4A1@frobbit.se> <20141231082551.GN24442@localhost> <E4837FDB76D5ACDEB1C568DF@[192.168.1.128]> <20150102030130.GN24442@localhost> <alpine.GSO.2.00.1501032124490.6923@keflavik> <alpine.GSO.2.00.1501071105250.8929@keflavik> <7A38C32D6DB867E71E8F90B4@JcK-HP8200.jck.com>
User-Agent: Alpine 2.00 (GSO 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/iGooMG61FXNjlaSDOOsHjmq1D4Q>
X-Mailman-Approved-At: Fri, 09 Jan 2015 08:39:59 -0800
Cc: Darren J Moffat <Darren.Moffat@oracle.com>, Stef Walter <stef@thewalter.net>, Jaroslav Imrich <jaroslav.imrich@gmail.com>, ietf@ietf.org, =?ISO-8859-15?Q?Patrik_F=E4ltstr=F6m?= <paf@frobbit.se>, Shawn Emery <shawn.emery@oracle.com>, saag@ietf.org, Christian Huitema <huitema@microsoft.com>, Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Jan 2015 18:45:52 -0000

On Thu, 8 Jan 2015, John C Klensin wrote:

>> On Sat, 3 Jan 2015, Jan Pechanec wrote:
>> 
>> 	hi, I haven't received any other comments on the draft 
>> recently (I know the LC already ended on Dec 29 though) so I
>> think I  can file changes discussed and drafted in this thread
>> as draft 18 on  Friday.  Thank you all for feedback, I really
>> appreciate it.
>> 
>> 	one more change for the draft 18 (v2 attached) is to spell 
>> "NFC" and reference the Unicode Annex on normalization based
>> on  comments from Jaroslav and Christian.
>>...
>
>Jan,
>
>I don't have a lot of time to spend on this and am not an expert
>on either X.509 or PKCK (#11 or otherwise).  At least the first
>may be unfortunate, but it is what it is.
	
	hi John, I very much appreciate time you already spent on 
this.  Please see my comments inline.

>While I think the changes you have made are definitely
>improvements, this i18n stuff is complicated.  As with Security,
>there is a completely inadequate supply of magic pixie dust that
>can be thrown at problems to make them go away.  "Normalize to
>NFC" (with spelling-out and references) is a vast improvement or
>"use [valid] UTF-8" but there are many other issues.  You have
>noted some and omitted others.  For example, case-independent
>matching is a very simple and completely deterministic issue for
>ASCII (one essentially just masks off one bit within a certain
>range), it can get very messy if one tries to be sensitive to
>different locales that have different conventions about what to
>do with diacritical marks when lower-case characters are
>converted to upper case.  There are Unicode "CaseFold" rules

	I understand from the previous discussion that the topic is a 
very complex one and that my draft needed to acknowledge that.

<...>

>I don't know how far in explaining this your document should go.
>I would urge, as I think I did before, some fairly strong
>warnings that, at least until the issues are clarified in
>PKCS#11 itself, one should be very certain one knows what one is
>doing (and what the consequences of one's choices will be) if
>one decides to move beyond the safety and general understanding
>of the ASCII/ ISO 646/ IA5 letter and digit repertoire.  That
>sort of warning should supplement your NFC language, not replace
>it-- neither is a substitute for the other.   Whether you
>incorporate it or not, your I-D should not assume that, by
>saying "NFC", you have somehow resolved the full range of issues
>in this area, any more than saying "UTF-8" did. 

	I understand that.  The note about spelling NFC was on top of 
the first changes I incorporated.  I don't know if you saw those, I 
know there were many emails and your time you could spend on this is 
very limited.  So, in section on URI matching, I tried to be very 
explicit and based the warning I added on one of your comments from 
the previous discussion:

+   As noted in Section 6, the PKCS#11 specification is not clear about
+   how to normalize UTF-8 encoded Unicode characters [RFC3629].  Those
+   who discover a need to use characters outside the ASCII repertoire
+   should be cautious, conservative, and expend extra effort to be sure
+   they know what they are doing and that failure to do so may create
+   both operational and security risks.  It means that when matching
+   UTF-8 string based attributes (see Table 1) with such characters,
+   normalizing all UTF-8 strings before string comparison may be the
+   only safe approach.  For example, for objects (keys) it means that
+   PKCS#11 attribute search template would only contain attributes that
+   are not UTF-8 strings and another pass through returned objects is
+   then needed for UTF-8 string comparison after the normalization is
+   applied.

	do you suggest a stronger warning than that?

	more on that was incorporated into a new Internationalization 
Condiderations section, based on new text drafted by Nico:

+6.  Internationalization Considerations
 
+   The PKCS#11 specification does not specify a canonical form for
+   strings of characters of the CK_UTF8CHAR type.  This presents the
+   usual false negative and false positive (aliasing) concerns that
+   arise when dealing with unnormalized strings.  Because all PKCS#11
+   items are local and local security is assumed, these concerns are
+   mainly about usability.
+
+   In order to improve the user experience, applications that create
+   PKCS#11 objects or label tokens SHOULD normalize labels to
+   Normalization Form C (NFC) [UAX15].  For the same reason PKCS#11
+   libraries, slots (token readers), and tokens SHOULD normalize their
+   names to NFC.  When listing PKCS#11 libraries, slots, tokens, and/or
+   objects, an application SHOULD normalize their names to NFC.  When
+   matching PKCS#11 URIs to libraries, slots, tokens, and/or objects,
+   applications MAY use form-insensitive Unicode string comparison for
+   matching, as those might pre-date these recommendations.  See also
+   Section 3.5.

	and a new paragraph was also added to the existing Security 
Considerations section:

+   The PKCS#11 specification does not provide means to authenticate
+   devices to users; it only allows to authenticate users to tokens.
+   Instead, local and physical security are demanded: the user must be
+   in possession of their tokens, and system into whose slots the users'
+   tokens are inserted must be secure.  As a result, the usual security
+   considerations regarding normalization do not arise.  For the same
+   reason, confusable script issues also do not arise.  Nonetheless, it
+   is best to normalize to NFC all strings appearing in PKCS#11 API
+   elements.  See also Section 6.

	I think these new paragraphs convey the message that users 
should very careful when using characters outside ASCII, and what to 
do to mitigate problems that can arise from such use.  Do you think 
more should be said in the draft itself?

>For more information, you might have a look at some of the
>PRECIS work, notably draft-ietf-precis-framework.
>
>I also remain convinced that the best place to fix this is in
>the PKCS#11 spec itself.  One is always at a disadvantage when
>trying to work around an inadequate specification in a different
>specification that has to depend on it and your work is no
>exception.  I wish there were whatever liaison arrangements
>between the IETF and others (presumably notably RSA) to be sure
>that happened or at least there was clear awareness on the PKCS
>side of the deficiencies.

	last week I did contact OASIS PKCS 11 TC which is where 
PKCS#11 moved to since 2013.  However, even if the issue is going to 
be fixed there I don't think it will be in new version 2.40 which is 
close to be published.

	Happy New Year to you, too.

	best regards, Jan.

-- 
Jan Pechanec <jan.pechanec@oracle.com>