Re: i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call))
Jan Pechanec <jan.pechanec@oracle.com> Sun, 04 January 2015 05:58 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 AC8991A6F1E; Sat, 3 Jan 2015 21:58:50 -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 DYFrAbRHafBy; Sat, 3 Jan 2015 21:58:42 -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 225A51A049C; Sat, 3 Jan 2015 21:58:42 -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 t045wNxu028446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 4 Jan 2015 05:58:23 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t045wJYN026420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 4 Jan 2015 05:58:20 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t045wJsv012590; Sun, 4 Jan 2015 05:58:19 GMT
Received: from keflavik.us.oracle.com (/10.132.148.214) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 03 Jan 2015 21:58:19 -0800
Date: Sat, 03 Jan 2015 21:58:17 -0800
From: Jan Pechanec <jan.pechanec@oracle.com>
X-X-Sender: jpechane@keflavik
To: Nico Williams <nico@cryptonector.com>
Subject: Re: i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call))
In-Reply-To: <20150102030130.GN24442@localhost>
Message-ID: <alpine.GSO.2.00.1501032124490.6923@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>
User-Agent: Alpine 2.00 (GSO 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-586517042-1420350762=:6923"
Content-ID: <alpine.GSO.2.00.1501032152480.6923@keflavik>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/f96x6QY7dZGhcZgrABsWw2Eo3sc
Cc: Darren J Moffat <Darren.Moffat@oracle.com>, ietf@ietf.org, Patrik Fältström <paf@frobbit.se>, Shawn Emery <shawn.emery@oracle.com>, 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 05:58:51 -0000
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>
- Re: slot attributes & last call Nico Williams
- Re: PKCS#11 URI slot attributes & last call Nico Williams
- Re: slot attributes & last call Nico Williams
- Re: slot attributes & last call Nico Williams
- Re: slot attributes & last call Nico Williams
- Re: PKCS#11 URI slot attributes & last call Nikos Mavrogiannopoulos
- Re: [saag] PKCS#11 URI slot attributes & last call Stephen Farrell
- Re: slot attributes & last call Nico Williams
- Re: PKCS#11 URI slot attributes & last call Jan Pechanec
- Re: slot attributes & last call Darren J Moffat
- Re: PKCS#11 URI slot attributes & last call Darren J Moffat
- Re: slot attributes & last call Jan Pechanec
- Re: PKCS#11 URI slot attributes & last call Jan Pechanec
- Re: PKCS#11 URI slot attributes & last call Jan Pechanec
- Re: PKCS#11 URI slot attributes & last call Jan Pechanec
- Re: slot attributes & last call Jan Pechanec
- Re: PKCS#11 URI slot attributes & last call Jan Pechanec
- Re: slot attributes & last call Jaroslav Imrich
- Re: slot attributes & last call Jaroslav Imrich
- Re: slot attributes & last call Nikos Mavrogiannopoulos
- Re: slot attributes & last call Jan Pechanec
- Re: [saag] PKCS#11 URI slot attributes & last call Henry B (Hank) Hotz, CISSP
- Re: [saag] PKCS#11 URI slot attributes & last call Nico Williams
- Re: PKCS#11 URI slot attributes & last call Nico Williams
- Re: [saag] PKCS#11 URI slot attributes & last call Jan Pechanec
- Re: PKCS#11 URI slot attributes & last call Jan Pechanec
- Re: PKCS#11 URI slot attributes & last call Nico Williams
- Re: PKCS#11 URI slot attributes & last call Nico Williams
- Re: [saag] PKCS#11 URI slot attributes & last call Nico Williams
- Re: PKCS#11 URI slot attributes & last call Patrik Fältström
- Re: PKCS#11 URI slot attributes & last call Nico Williams
- Re: PKCS#11 URI slot attributes & last call Patrik Fältström
- NF* (Re: PKCS#11 URI slot attributes & last call) Nico Williams
- Re: NF* (Re: PKCS#11 URI slot attributes & last c… Patrik Fältström
- Re: NF* (Re: PKCS#11 URI slot attributes & last c… Nico Williams
- Re: NF* (Re: PKCS#11 URI slot attributes & last c… Patrik Fältström
- Re: NF* (Re: PKCS#11 URI slot attributes & last c… Nico Williams
- i18n requirements (was: Re: NF* (Re: PKCS#11 URI … John C Klensin
- Re: i18n requirements (was: Re: NF* (Re: PKCS#11 … Nico Williams
- Re: PKCS#11 URI slot attributes & last call Jan Pechanec
- Re: [saag] PKCS#11 URI slot attributes & last call Jan Pechanec
- Re: [saag] PKCS#11 URI slot attributes & last call Nico Williams
- Re: PKCS#11 URI slot attributes & last call Jan Pechanec
- Re: PKCS#11 URI slot attributes & last call Jan Pechanec
- Re: [saag] PKCS#11 URI slot attributes & last call Jan Pechanec
- Re: i18n requirements (was: Re: NF* (Re: PKCS#11 … Nico Williams
- Re: i18n requirements (was: Re: NF* (Re: PKCS#11 … Patrik Fältström
- Re: i18n requirements (was: Re: NF* (Re: PKCS#11 … John C Klensin
- Re: i18n requirements (was: Re: NF* (Re: PKCS#11 … Patrik Fältström
- Re: i18n requirements (was: Re: NF* (Re: PKCS#11 … Nico Williams
- Re: i18n requirements (was: Re: NF* (Re: PKCS#11 … Jan Pechanec
- Re: NF* (Re: PKCS#11 URI slot attributes & last c… Jan Pechanec
- Re: NF* (Re: PKCS#11 URI slot attributes & last c… Nico Williams
- Re: i18n requirements (was: Re: NF* (Re: PKCS#11 … Jan Pechanec
- Re: [saag] i18n requirements (was: Re: NF* (Re: P… Jan Pechanec
- RE: [saag] i18n requirements (was: Re: NF* (Re: P… Christian Huitema
- RE: [saag] i18n requirements (was: Re: NF* (Re: P… Jan Pechanec
- Re: [saag] i18n requirements (was: Re: NF* (Re: P… Jaroslav Imrich
- Re: i18n requirements (was: Re: NF* (Re: PKCS#11 … Jan Pechanec
- Re: i18n requirements (was: Re: NF* (Re: PKCS#11 … Jan Pechanec
- Re: i18n requirements (was: Re: NF* (Re: PKCS#11 … John C Klensin
- My IESG Eval for draft-pechanec-pkcs11uri-19 (Was… Pete Resnick
- Re: My IESG Eval for draft-pechanec-pkcs11uri-19 … John C Klensin