Re: PKCS#11 URI slot attributes & last call

Jan Pechanec <jan.pechanec@oracle.com> Tue, 30 December 2014 18:14 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 238CE1A0371; Tue, 30 Dec 2014 10:14:28 -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 NF0VDjZxq3lz; Tue, 30 Dec 2014 10:14:26 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDBA31A00FD; Tue, 30 Dec 2014 10:14:26 -0800 (PST)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sBUIEKqS003473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Dec 2014 18:14:21 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 sBUIEJ1R000835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Dec 2014 18:14:20 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sBUIEJWx012548; Tue, 30 Dec 2014 18:14:19 GMT
Received: from keflavik.us.oracle.com (/10.132.148.214) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 30 Dec 2014 10:14:19 -0800
Date: Tue, 30 Dec 2014 10:14:18 -0800 (PST)
From: Jan Pechanec <jan.pechanec@oracle.com>
X-X-Sender: jpechane@keflavik
To: Nico Williams <nico@cryptonector.com>
Subject: Re: PKCS#11 URI slot attributes & last call
In-Reply-To: <CAK3OfOgm_ZYj-rY+4ExZzY8KY4G3rz2KLrZ8hQJi7ZUR4yiP0Q@mail.gmail.com>
Message-ID: <alpine.GSO.2.00.1412300946340.4549@keflavik>
References: <alpine.GSO.2.00.1412161359100.4549@keflavik> <CAB6OCMvGxT99cGGBSBbz=XU2+F1xRzBa97z6dY-qPSJk1GWXyQ@mail.gmail.com> <20141217230150.GB9443@localhost> <alpine.GSO.2.00.1412171513520.4549@keflavik> <CAK3OfOjnRCmiu-TKCJ-AFanpCsqnw1o2w_EC2AKMUnQ2A4DqVw@mail.gmail.com> <alpine.GSO.2.00.1412292234010.1509@keflavik> <CAK3OfOgm_ZYj-rY+4ExZzY8KY4G3rz2KLrZ8hQJi7ZUR4yiP0Q@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/Mk0ob7UYXF48Em-preZ3hD0wVME
X-Mailman-Approved-At: Wed, 31 Dec 2014 21:32:39 -0800
Cc: Darren J Moffat <Darren.Moffat@oracle.com>, Stef Walter <stef@thewalter.net>, Jaroslav Imrich <jaroslav.imrich@gmail.com>, "ietf@ietf.org" <ietf@ietf.org>, "saag@ietf.org" <saag@ietf.org>, 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: Tue, 30 Dec 2014 18:14:28 -0000

On Tue, 30 Dec 2014, Nico Williams wrote:

>Better not even think about saying anything about normalization,
>right?  PKCS#11 nowadays supports UTF-8 for the strings we care about,
>but says nothing about normalization.  I suppose you could say that
>matching should be (lowercase) normalization-insensitive.  In practice
>it will never matter (which is why the lowercase).

	hi Nico, I assume you talk about case normalization now.  I 
also agree we need not to say anything about it - and we don't aside 
from "case normalization" as defined in 6.2.2.1 of RFC 3986 where only 
the following sections are relevant to us:

   For all URIs, the hexadecimal digits within a percent-encoding
   triplet (e.g., "%3a" versus "%3A") are case-insensitive and therefore
   should be normalized to use uppercase letters for the digits A-F.

	and:

   The other generic syntax components are assumed to be 
   case-sensitive unless specifically defined otherwise by the scheme 
   (see Section 6.2.3).

	I also understand that technically it is not specified which 
pairs form lower-upper character relationship and that in some 
alphabets not everybody agrees on what the uppercase version of a 
specific character is.  I can also see a report that perl and GNU libc 
conversion routines work differently and that it may not be simply a 
bug in one or the other.

	so I'd rather compare UTF-8 strings literaly and assume that 
producers of PKCS#11 URIs will use exactly what they get via the 
PKCS#11 API and that consumers will not apply any case normalization 
post-processing on such URIs.

	cheers, Jan.

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