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

Jan Pechanec <jan.pechanec@oracle.com> Sun, 04 January 2015 14:53 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 291141A8738; Sun, 4 Jan 2015 06:53:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 S9__eY906XN5; Sun, 4 Jan 2015 06:53:26 -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 8A5591A1EF8; Sun, 4 Jan 2015 06:53:26 -0800 (PST)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t04ErE5x024204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 4 Jan 2015 14:53:15 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t04ErDOD013633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Jan 2015 14:53:13 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id t04ErCVh016259; Sun, 4 Jan 2015 14:53:12 GMT
Received: from keflavik.us.oracle.com (/10.132.148.214) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 04 Jan 2015 06:53:11 -0800
Date: Sun, 4 Jan 2015 06:53:10 -0800 (PST)
From: Jan Pechanec <jan.pechanec@oracle.com>
X-X-Sender: jpechane@keflavik
To: Jaroslav Imrich <jaroslav.imrich@gmail.com>
Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call))
In-Reply-To: <CAB6OCMs=iZcn=1LBLEAs606ani9k6B6VANj4iH8QAqnjNb5Ygg@mail.gmail.com>
Message-ID: <alpine.GSO.2.00.1501040650200.7930@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> <CAB6OCMs=iZcn=1LBLEAs606ani9k6B6VANj4iH8QAqnjNb5Ygg@mail.gmail.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: acsinet21.oracle.com [141.146.126.237]
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/40kzhQH5pqzIXVg5mUQyChqTLeo
Cc: Darren J Moffat <Darren.Moffat@oracle.com>, ietf@ietf.org, =?ISO-8859-15?Q?Patrik_F=E4ltstr=F6m?= <paf@frobbit.se>, saag@ietf.org, John C Klensin <john-ietf@jck.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: Sun, 04 Jan 2015 14:53:29 -0000

On Sun, 4 Jan 2015, Jaroslav Imrich wrote:

>Hello Jan,
>
>the text mentions "NFC" but I was unable to find any pointer or reference
>to its definition. I was not familiar with the term before so I think
>reference in the text would be helpful.

	hi Jaroslav, it's defined in the Unicode standard which I can 
reference directly but you would still need to search for the term 
rather than read the whole standard.

	please google "unicode NFC", all first hits lead to the right 
information.

	Jan.

>
>Regards, Jaroslav
>
>
>On Sun, Jan 4, 2015 at 6:58 AM, Jan Pechanec <jan.pechanec@oracle.com>
>wrote:
>
>> On Thu, 1 Jan 2015, Nico Williams wrote:
>>
>>         Nico, many thanks for the drafted text and also to Patrik and
>> John for discussing it.
>>
>>         I've updated the draft in sections on URI matching guidelines,
>> URI comparision, added a new section on I18n, and added a new paragraph
>> to the Security considerations.  Individial diffs inline, a draft for
>> new draft 18 attached (draft-pechanec-pkcs11uri-18-v1.txt).
>>
>> >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 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 otherwise label tokens, SHOULD normalize labels to
>> >   NFC.  For the same reason PKCS#11 libraries, slots (token readers),
>> >   and tokens SHOULD normalize their names to NFC.  When listing
>> >   libraries, slots, tokens, 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 the objects might pre-date these
>> >   recommendations).
>>
>>         I've created "Internationalization Considerations" section and
>> put the text above there after I slightly modified it.  I wanted to
>> mention CK_UTF8CHAR type so that it's clear what is discussed.
>>
>> 768     6.  Internationalization Considerations
>>
>> 770        The PKCS#11 specification does not specify a canonical form for
>> 771        strings of characters of the CK_UTF8CHAR type.  This presents
>> the
>> 772        usual false negative and false positive (aliasing) concerns that
>> 773        arise when dealing with unnormalized strings.  Because all
>> PKCS#11
>> 774        items are local and local security is assumed, these concerns
>> are
>> 775        mainly about usability.
>>
>> 777        In order to improve the user experience, applications that
>> create
>> 778        PKCS#11 objects or label tokens, SHOULD normalize labels to
>> NFC.  For
>> 779        the same reason PKCS#11 libraries, slots (token readers), and
>> tokens
>> 780        SHOULD normalize their names to NFC.  When listing PKCS#11
>> libraries,
>> 781        slots, tokens, and/or objects, an application SHOULD normalize
>> their
>> 782        names to NFC.  When matching PKCS#11 URIs to libraries, slots,
>> 783        tokens, and/or objects, applications MAY use form-insensitive
>> Unicode
>> 784        string comparison for matching, as those might pre-date these
>> 785        recommendations.  See also Section 3.5.
>>
>>         in section 3.5 on URI Matching Guidelines, I've added the
>> following as the last paragraph of the section (it was based on John's
>> note from his last email).  This paragraph might not be necessary there
>> and the first part could be moved to the I18N section but I think it's
>> good to put it to where attribute matching is discussed so that it is
>> not easily overlooked.
>>
>> 513        As noted in Section 6, the PKCS#11 specification is not clear
>> about
>> 514        how to normalize UTF-8 encoded Unicode characters [RFC2279].
>> Those
>> 515        who discover a need to use characters outside the ASCII
>> repertoire
>> 516        should be cautious, conservative, and expend extra effort to be
>> sure
>> 517        they know what they are doing and that failure to do so may
>> create
>> 518        both operational and security risks.  It means that when
>> matching
>> 519        UTF-8 string based attributes (see Table 1) with such
>> characters,
>> 520        normalizing all UTF-8 strings before string comparison may be
>> the
>> 521        only safe approach.  For example, for objects (keys) it means
>> that
>> 522        PKCS#11 attribute search template would only contain attributes
>> that
>> 523        are not UTF-8 strings and another pass through returned objects
>> is
>> 524        then needed for UTF-8 string comparison after the normalization
>> is
>> 525        applied.
>>
>> >Then later in the security considerations section, add something like:
>> >
>> >   PKCS#11 does not authenticate devices to users; PKCS#11 only
>> >   authenticates 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.
>>
>>         I've added the following to the Security Considerations
>> section (again, slightly modified, I'd rather not use "PKCS#11" as
>> an alias for the specification):
>>
>> 807        The PKCS#11 specification does not provide means to authenticate
>> 808        devices to users; it only allows to authenticate users to
>> tokens.
>> 809        Instead, local and physical security are demanded: the user
>> must be
>> 810        in possession of their tokens, and system into whose slots the
>> users'
>> 811        tokens are inserted must be secure.  As a result, the usual
>> security
>> 812        considerations regarding normalization do not arise.  For the
>> same
>> 813        reason, confusable script issues also do not arise.
>> Nonetheless, it
>> 814        is best to normalize to NFC all strings appearing in PKCS#11 API
>> 815        elements.  See also Section 6.
>>
>>         on top of that, I've added the following sentence to 3.6. PKCS#11
>> URI
>> Comparison section:
>>
>> 532        strictly avoiding false positives.  When working with UTF-8
>> strings
>> 533        with characters outside the ASCII character sets, see important
>> 534        caveats in Section 3.5 and Section 6.
>>
>>         the attribute Table 1 now also states which attributes are
>> UTF-8 strings so that it's clear without consulting the spec.
>>
>>         thank you, Jan.
>>
>> --
>> Jan Pechanec <jan.pechanec@oracle.com>
>> _______________________________________________
>> saag mailing list
>> saag@ietf.org
>> https://www.ietf.org/mailman/listinfo/saag
>>
>>
>

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