Re: PKCS#11 URI slot attributes & last call

Jan Pechanec <> Tue, 30 December 2014 18:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 238CE1A0371; Tue, 30 Dec 2014 10:14:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.21
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NF0VDjZxq3lz; Tue, 30 Dec 2014 10:14:26 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CDBA31A00FD; Tue, 30 Dec 2014 10:14:26 -0800 (PST)
Received: from ( []) by (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 ( []) by (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 ( []) by (8.14.4+Sun/8.14.4) with ESMTP id sBUIEJWx012548; Tue, 30 Dec 2014 18:14:19 GMT
Received: from (/ 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
From: Jan Pechanec <>
X-X-Sender: jpechane@keflavik
To: Nico Williams <>
Subject: Re: PKCS#11 URI slot attributes & last call
In-Reply-To: <>
Message-ID: <alpine.GSO.2.00.1412300946340.4549@keflavik>
References: <alpine.GSO.2.00.1412161359100.4549@keflavik> <> <20141217230150.GB9443@localhost> <alpine.GSO.2.00.1412171513520.4549@keflavik> <> <alpine.GSO.2.00.1412292234010.1509@keflavik> <>
User-Agent: Alpine 2.00 (GSO 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Source-IP: []
X-Mailman-Approved-At: Wed, 31 Dec 2014 21:32:39 -0800
Cc: Darren J Moffat <>, Stef Walter <>, Jaroslav Imrich <>, "" <>, "" <>, Nikos Mavrogiannopoulos <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 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.


   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 <>