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

Jan Pechanec <jan.pechanec@oracle.com> Mon, 12 January 2015 20:01 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 76C4D1ACDF7; Mon, 12 Jan 2015 12:01:37 -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 v_KZx30oyE-Y; Mon, 12 Jan 2015 12:01: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 B37E51ACDB1; Mon, 12 Jan 2015 12:01:02 -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 t0CK0Avm010717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Jan 2015 20:00:11 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t0CK09cI003058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 12 Jan 2015 20:00:10 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t0CK08O0012954; Mon, 12 Jan 2015 20:00:08 GMT
Received: from keflavik.us.oracle.com (/10.132.148.214) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Jan 2015 12:00:08 -0800
Date: Mon, 12 Jan 2015 12:00:07 -0800 (PST)
From: Jan Pechanec <jan.pechanec@oracle.com>
X-X-Sender: jpechane@keflavik
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call))
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAF5744C@uxcn10-tdc05.UoA.auckland.ac.nz>
Message-ID: <alpine.GSO.2.00.1501121153520.8555@keflavik>
References: <9A043F3CF02CD34C8E74AC1594475C73AAF5744C@uxcn10-tdc05.UoA.auckland.ac.nz>
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/cPSqtMD0ImqMQUb_dW8iBelcItk>
Cc: Stef Walter <stef@thewalter.net>, Jaroslav Imrich <jaroslav.imrich@gmail.com>, Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>, "saag@ietf.org" <saag@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
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: Mon, 12 Jan 2015 20:01:37 -0000

On Sun, 11 Jan 2015, Peter Gutmann wrote:

>Jan Pechanec <jan.pechanec@oracle.com> writes:
>
>>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.
>
>I'd go even further than that and just mandate MUST ASCII.  This is a simple
>means of pointing to a PKCS #11 object, not a universal means of communicating
>abstract concepts in any language known to man.  We've already gone from

	hello Peter, thank you for the feedback, I've made it 
RECOMMENDED to use US-ASCII only for labels/names but as noted by 
others, we cannot really make it REQUIRED and still support the 
PKCS#11 spec use of UTF-8.

>"specify a path to load a PKCS #11 module" to something that's fast heading
>towards being Turing-complete, if it isn't already.  The amount of code needed
>to parse and process all of this is getting frightening, not to mention the
>semantics of dealing with all of this (is anyone really going to care who the
>manufacturer of their HSM is when they attach to it?).  The result is going to

	for tokens that are guaranteed unique, combination of the 
manufacturer ID string and the token serial number makes the token 
identification unique which may be important when used from the 
configuration files, for example (on a command line though, I'd rather 
use a token name and be warned if there are more of those of the same 
name).

	I've just filed draft 18 which addresses issues discussed on 
the use of characters outside of the US-ASCII character set.  The diff 
is as follows:

http://www.ietf.org/rfcdiff?url1=draft-pechanec-pkcs11uri-17&url2=draft-pechanec-pkcs11uri-18

	best regards, Jan.

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