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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Sun, 11 January 2015 22:26 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 0723D1A1ACA; Sun, 11 Jan 2015 14:26:49 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 bSb0tHmOCn6E; Sun, 11 Jan 2015 14:26:43 -0800 (PST)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1CB91A1ABE; Sun, 11 Jan 2015 14:26:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1421015203; x=1452551203; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=BHTviDyf27a9J/9mRUpZMXReUee/InSl2sUK0g9Y8oU=; b=QuwpZQ79U2kId1/7MTFigPy9CRPI2sDnwmmHtniwcfKTcDiuR9EuL38E 85VF+/tI84LxIZjUHdom3/VvPSmGT6POLjE/XPzWrT8Mx+cDRhdHQHco0 aiZSSV5GhY5cE2FnxUyiWVSVO/PhT4WDxSgW7+Tv8/bLQ5qwfdRDARoWH Q=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="300747240"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 12 Jan 2015 11:26:41 +1300
Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.148]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Mon, 12 Jan 2015 11:26:41 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Jan Pechanec <jan.pechanec@oracle.com>, "ietf@ietf.org" <ietf@ietf.org>, "saag@ietf.org" <saag@ietf.org>
Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call))
Thread-Topic: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call))
Thread-Index: AdAt7aueiIQsDpJZRV+GYQnIBrYzUA==
Date: Sun, 11 Jan 2015 22:26:40 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAF5744C@uxcn10-tdc05.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/rCAK9GTgOAnFMxcR-dklS9UaiZw>
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, 11 Jan 2015 22:26:49 -0000

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
"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
be a bunch of partial, incompatible implementations with applications needing
to perform probing to see which attributes the driver they're talking to
supports if they go beyond anything but the basics.

Peter.