Re: [Uri-review] PKCS#11 URI registration request review

Ted Hardie <> Wed, 13 February 2013 17:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A116221F8877 for <>; Wed, 13 Feb 2013 09:38:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.54
X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ov6-hv3yBNCP for <>; Wed, 13 Feb 2013 09:38:40 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c02::22e]) by (Postfix) with ESMTP id BBA3D21F8530 for <>; Wed, 13 Feb 2013 09:38:40 -0800 (PST)
Received: by with SMTP id o25so1432338iad.33 for <>; Wed, 13 Feb 2013 09:38:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=nreMlstsm2hzTM+b8pREhys6W+MD+yEOhklhcPNUOCg=; b=P32XUuSNOtmFkJN+p37bt6BE8zOWHJyQGW+EcKUX1eaRM2dldiR5NdjwFanBy4wxCO KKEWrT7i0sCs2o8jaEON39r/vjcAiQE5TEbGn2HKY1i/SgGrCgNMEJ+Ego0zjshqtzLf NkSUQOzFOWfw7ouo7tYDnWvXO6N59KXlbldlS6QCM4JWnD3F+hyWyrkUzPBynzMONOxE 5F/1uReTqS3ZgUn71UxvjVjocuCEFxe1dFOPcoS2Ilhauod1klylntD3cVMEbONkigTs 4Irj1GL0rs4a+m1hDtj39otwWR6OwXflb/tT+ev8aw5iGrXp1+f+dyvz1sv+ysAWKcq9 096Q==
MIME-Version: 1.0
X-Received: by with SMTP id fv1mr12559033igc.96.1360777120380; Wed, 13 Feb 2013 09:38:40 -0800 (PST)
Received: by with HTTP; Wed, 13 Feb 2013 09:38:40 -0800 (PST)
In-Reply-To: <alpine.GSO.2.00.1302122349180.14210@rejewski>
References: <alpine.GSO.2.00.1301261430001.28908@rejewski> <alpine.GSO.2.00.1302081722560.7401@rejewski> <> <alpine.GSO.2.00.1302122349180.14210@rejewski>
Date: Wed, 13 Feb 2013 09:38:40 -0800
Message-ID: <>
From: Ted Hardie <>
To: Jan Pechanec <>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [Uri-review] PKCS#11 URI registration request review
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Proposed URI Schemes <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Feb 2013 17:38:41 -0000

On Wed, Feb 13, 2013 at 12:01 AM, Jan Pechanec <> wrote:
>         hi Ted, I agree it is confusing, thanks for bringing it up. I'd
> like to change it to:
>    This section contains some examples of how PKCS#11 token objects,
>    PKCS#11 tokens, and PKCS#11 libraries can be identified using the
>    PKCS#11 URI scheme.  Note that in some of the following examples,
>    newlines and spaces were inserted for better readability.  As
>    specified in Appendix C of [RFC3986], whitespace should be ignored
>    when extracting the URI.  Also note that all spaces as part of the
>    URI are percent-encoded, as specified in Appendix A of [RFC3986].

This looks much better, thanks.

>>I also believe you may wish to make explicit statements about where on
>>the 3986 ladder of comparison you intend for these attribute-value
>>pairs to fall.  As it stands, some of the text about Library version
>>indicates that you expect a semantic comparison, but it is usual in
>>cryptographic contexts to require something that has much less wiggle
>>room.  Explicit text on this would help the reader understand what it
>>is expected
>         it sounds very reasonable and I'd like to add a new paragraph at
> the end of Section 3:
>    As ordering of attributes in the PKCS#11 URI is not significant,
>    comparison of URIs should be performed on a per-attribute basis after
>    the URI itself is normalized as explained in Section 6 of [RFC3986].
>    Caution should excercised when comparing the "id" attributes as their
>    values may not be fully percent-encoded.  Library version ".N" should
>    be interpreted as "0" for the major and "N" for the minor version of
>    the library.  Library version "M" should be interpreted as "M" for
>    the major and "0" for the minor version of the library.
So, I think you are mixing the comparison of the values encoded in the
URI with the comparison of the URI itself.  If the typical mode of
employment is to deconstruct the URI into a set of attribute/value
pairs, it's fine for the using application to treat the result as
unordered.  But this may mean that there is no reasonable comparison
to be done here at the URI level.  You can be sure that two URIs match
if they are bit-for-bit identical, but there are lots of other
conditions in which they *may* be equivalent.

Do you expect people to actually compare at the URI level at all?


>         does it look OK to you?
>         thanks a lot for your feedback.
>         regards, Jan.
>>Ted Hardie
>>On Fri, Feb 8, 2013 at 5:28 PM, Jan Pechanec <> wrote:
>>> On Sat, 26 Jan 2013, Jan Pechanec wrote:
>>>         hi, the section 5.2 of RFC 4395 notes "Allow a reasonable time
>>> for discussion and comments. Four weeks is reasonable for a permanent
>>> registration requests."
>>>         I will wait for two more weeks if there is any feedback (which
>>> would be greatly appreciated) to make it 4 weeks in total, and if there
>>> is none I will continue with the next step, which is the submission to
>>>         regards, Jan.
>>>>       hello,
>>>>       in accordance with section "5.2. Registration Procedures" of RFC
>>>>4395 "Guidelines and Registration Procedures for New URI Schemes", I
>>>>respectfully request a review for our planned permanent registration
>>>>request of the PKCS#11 URI as specified in the following I-D:
>>>>       the registration template is attached.
>>>>       best regards, Jan Pechanec
>>> --
>>> Jan Pechanec
>>> _______________________________________________
>>> Uri-review mailing list
> --
> Jan Pechanec <>