Subject: Re: slot attributes & last call

From: Nico Williams <[email-masked]>
Date: Wed, 17 Dec 2014 17:01:54 -0600

On Wed, Dec 17, 2014 at 11:44:57PM +0100, Jaroslav Imrich wrote:
> I am CC-ing [email-masked] mailing list as it seems to be correct public
> list to discuss I-D for PKCS#11 URIs.

For an I-D in IETF LC that should be [email-masked].  Cc'ing it (and not
trimming any quotes).

> On Tue, Dec 16, 2014 at 11:29 PM, Jan Pechanec <[email-masked]>
> wrote:
> >         hi all, the draft is in the middle of the last call with
> > comments to be sent till Dec 29.  There are a few nits to be fixed but
> > we also got two independent inquiries about adding slot attributes.
> > One is internal to Solaris, another is from an engineer who would like
> > to replace some pam_pkcs11 module config attributes with one PKCS#11
> > URI.  One of the attributes there is "slot_description" and apparently
> > it's useful and being used there.
> >
> >         I think that having slot attributes is useful.
> >
> >         obvious choice is this:
> >
> > pk11-slot-desc        = "slot-description" "=" *pk11-pchar
> > pk11-slot-manuf       = "slot-manufacturer" "=" *pk11-pchar
> > pk11-slot-id          = "slot-id" "=" 1*DIGIT
> >
> 
> I don't mind adding "slot-description" and "slot-manufacturer" if someone
> finds them useful but I can't recommend adding "slot-id". I personally

The cases I've seen where this is useful are ones where the PKCS#11
provider library provides unified access to multiple types of
slots/tokens, and the application is trying to obtain user credentials
from a user's removable token (smartcard).

If the provider includes access to slots/token types like: software
tokens, TPMs, and removable user tokens, and if any of the tokens
require login even to be able to list public objects[*], then picking a
slot and token carefully becomes critical to providing a user-friendly
experience, and even to avoiding accidental token lockout (which would
be really user-unfriendly).

[*] I know, that would be rather surprising behavior, but there's at
    least one such non-removable token in use, as I recall.

> consider referencing slot/token by its internal slotId to be a very bad
> habit. Nikos has already mentioned that it is "just a meaningless number,
> it is not guaranteed to stay the same across reboots or program restarts",
> "its value is implementation-specific" and I fully agree with him. SlotId
> happens to be unsigned long in cryptoki API but it could also be a handle
> or pointer without changing its meaning. I believe that "slot-description"
> and "slot-manufacturer" along with other token identifying path attributes
> should cover most use cases. But maybe you know some specific use case that
> explicitly requires "slot-id"? Could you please describe it in more detail?

I agree that slot IDs are not reliable in general.  But specific
PKCS#11 provider libraries can arrange for them to be reliable.

I think the descriptions of these slot-specific attributes should be
very explicit about their general unreliability, and they should explain
when they can be useful.

> >         given that we already have attrs like "library-manufacturer"
> > it may seem weird to have "token", "manufacturer", "model", and
> > "serial" instead of "token-label", "token-manufacturer",
> > "token-model", and "token-serial".  However, we also have "object" and
> > "type" instead of "object-label" and "object-type" and I think it's
> > good to keep PKCS#11 URIs short and succinct.  In other words, I plan
> > to add the slot attributes above without changing other names.
> > Please let me know if you see any issues with it.
> 
> I'll share my latest experience with you. Few days ago I was writing simple
> encryption application and I have decided to use PKCS#11 URIs to identify
> encryption keys. Then I came to the point where I needed to write down URI
> into the config file and I was stuck. I couldn't remember attribute names
> even though in past I have implemented .NET library for PKCS#11 URI parsing
> and building. Attributes like "token", "type" or "object" seem just
> unnatural to me. I don't know maybe it is because I work with PKCS#11 at
> programming level but I would never refer to the value of "CKA_LABEL"
> attribute with other name than "label". However PKCS#11 URI uses "object"
> attribute for object label. Maybe regular non-developer users find current
> names suitable and easier to understand/remember but in my ideal world I
> would change the attribute names to:

Well, it's a bit late for this sort of change, as there are existing
implementations, and the change is superficial.  Otherwise I'd agree
with you.

> library-description
> library-manufacturer
> library-version
> slot-description
> slot-manufacturer
> token-manufacturer instead of "manufacturer"
> token-model instead of "model"
> token-serial instead of "serial"
> token-label instead of "token"
> object-class instead of "type"
> object-label instead of "object"
> object-id instead of "id"
> 
> I believe these names would be more appropriate for people who are already
> familiar with PKCS#11 and the others would have to learn them anyway. But I
> understand it may be too late for such a big change as there are already
> widely used implementations of current I-D.

Yes.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 17 Dec 2014 17:56:17 -0600

On Wed, Dec 17, 2014 at 03:52:50PM -0800, Jan Pechanec wrote:
> On Wed, 17 Dec 2014, Nikos Mavrogiannopoulos wrote:
> >I don't follow how the above require the slots to be known in order to
> >figure where the object is. In gnutls we handle all of these use cases,
> >and we don't need to know the slot at all. First you iterate all slots
> >searching for the object, and then you login and search again. How would
> >knowing the slot would have helped that?
> 
> 	hi Nikos, if I expect a token to be inserted with some key 
> (rather then identifying the key to use) then specifying the slot 
> where such token is to be found seems useful to me.  If I understand 
> it correctly, that's how pam_pkcs11 works.  It has two configuration 
> options for this - slot description and slot ID.

That only works with a PKCS#11 implementation like Solaris' libpkcs11.

In general PKCS#11 slot IDs are unreliable, and that's why Nikos
objects.

> 	I know that the slot ID is cryptoki module specific.  It would 
> have been nice if the specification supported token serial number as 
> it does for tokens.

It needn't be stable even for one module.

> 	the updated text would have to provide information about 
> general unreliability using the slot ID, for example.

Please post proposed new text.  Time is running out.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 17 Dec 2014 18:07:42 -0600

On Thu, Dec 18, 2014 at 12:57:16AM +0100, Jaroslav Imrich wrote:
> On Thu, Dec 18, 2014 at 12:01 AM, Nico Williams <[email-masked]>
> wrote:
> OK but I still don't understand the role of slot-id attribute here. Could
> you please be more specific about the use case?
> 
> Are you trying to say there exists PKCS#11 implementation that always
> presents i.e. TPM as slot 0, OS wide software token as slot 1 and whatever
> removable token you can connect as slot 2? And that you need to access that

Yes.

> removable token and you cannot use slot-description, slot-manufacturer and
> neither of token attributes? So the only option left is: pkcs11:slot-id=2
> ???

I think so.  This is really for Jan to answer.  Maybe the Solaris
libpkcs11 should just ensure a meaningful (stable and distinct) slot
label.  If that could be done then slot-id could be excluded here.

Jan?

> Well exactly the same thing can be said about object IDs (i.e. signature
> key is always presented with objectId 1, encryption key with objectId 2)
> and yet they are not present in the I-D.

Yes, and it should be said (or object ID attribute not included).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 17 Dec 2014 18:47:22 -0600

On Thu, Dec 18, 2014 at 01:23:02AM +0100, Jaroslav Imrich wrote:
> On Thu, Dec 18, 2014 at 1:15 AM, Jan Pechanec <[email-masked]>
> wrote:
> >         for example, metaslot on Solaris is always 0 so slot-id=0
> > would be reliable there to use to access the soft token.  Jan.
> 
> And there is no other URI that could identify that slot without the slot-id
> attribute? i.e. pkcs11:slot-description=metaslot

I would think so.  Maybe Jan misunderstood my question; he certainly
didn't answer it.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 17 Dec 2014 19:23:04 -0600

On Wed, Dec 17, 2014 at 05:10:08PM -0800, Jan Pechanec wrote:
> On Wed, 17 Dec 2014, Nico Williams wrote:
> 	I did, I'm sorry.  The description is distinct, "Sun Metaslot" 
> and it's defacto stable but what I wanted to say was that I don't 

This might be the reason to use slot-id in your case: that any token
reader device could claim to be a "Sun Metaslot" even though it's not.

When you know that slot #0 is is the "Sun Metaslot" then you can be more
certain that you're getting the "Sun Metaslot" than if you use the slot
label.

> think it is about whether we find a way not to use the attribute since 
> we could probably do without other attributes as well, I still think 
> that if we add slot-description and slot-manufacturer, we should add 
> slot-id since there are situations where it may be useful.

I agree now.

> 	I will draft new text including the slot-id attribute first 
> and send it here but will not file it yet.
> 
> 	thank you for reviewing this last minute proposals.  J.

Thanks,

Nico
--

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 18 Dec 2014 13:06:32 +0200

On Wed, 2014-12-17 at 22:54 -0800, Jan Pechanec wrote:

> +   Slot ID is a Cryptoki-assigned number that is not guaranteed stable
> +   across PKCS#11 module initializations.  However, slot description and
> +   manufacturer ID may not be enough to uniquely identify a specific
> +   reader.  In situations where slot information is necessary use of
> +   "slot-id" attribute may be justified if sufficient slot ID stability
> +   is provided in the PKCS#11 provider itself or externaly.

Hello Jan,
I'd like to propose the following text instead:
"Slot ID is a Cryptoki-assigned number that is not guaranteed stable
across PKCS#11 module initializations. However, there are certain
libraries and modules which provide stable slot numbers and
descriptions. For these cases, when the manufacturer ID is not
sufficient to uniquely identify a specific reader, the slot
information could be used to increase the precision of the token
identification. In other scenarios, using the slot identifiers is
likely to cause usability issues."

That text discusses both the benefits and the risks.

regards,
Nikos

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 18 Dec 2014 11:10:58 +0000

Hi Jan,

On 18/12/14 06:54, Jan Pechanec wrote:
> 	I really appreciate time you already spent reviewing this ID 
> and I'm not happy to do such last minute changes.  I hope this last 
> one would be worth it.

No worries - that's what the IETF LC is for, and it's good
to see it doing it's job esp. in this case, where it's not
a WG document.

Cheers,
S.

---

From: Nico Williams <[email-masked]>
Date: Thu, 18 Dec 2014 10:10:59 -0600

On Thu, Dec 18, 2014 at 11:22:09AM +0000, Darren J Moffat wrote:
> On 12/18/14 00:15, Jan Pechanec wrote:
> It is the zeroth slot in the list of slots not a slotid with a value
> of 0 - the distinction is subtle.

But it still works to speak of the nth slot.  Perhaps the attrbite
should be called 'slot', without the '-id', 'slot-list-offset' perhaps.

> I don't think we should have slot-id, it isn't stable and I know
> that some vendors use random values.

But there's still a list with a zeroth element.  The list could be
returned in different order every time, but that would just make this
attribute useless (and so unused) with such a provider, but not harmful.

Perhaps we should say that this attribute should always be used in
conjunction with the provider library attributes, to ensure that this
attribute has the desired semantics.  I.e., unless coupled to a library
that gives it semantics, this attribute has none.

Nico
--

---

From: Darren J Moffat <[email-masked]>
Date: Thu, 18 Dec 2014 11:22:09 +0000

> would be reliable there to use to access the soft token.  Jan.

It is the zeroth slot in the list of slots not a slotid with a value of 
0 - the distinction is subtle.

I don't think we should have slot-id, it isn't stable and I know that 
some vendors use random values.

-- 
Darren J Moffat

---

From: Darren J Moffat <[email-masked]>
Date: Thu, 18 Dec 2014 11:23:45 +0000

> That text discusses both the benefits and the risks.

If the consensus is that slot-id stays then I think text exactly like 
you wrote is essential.

-- 
Darren J Moffat

---

From: Jan Pechanec <[email-masked]>
Date: Wed, 17 Dec 2014 17:10:08 -0800 (PST)

-- 
Jan Pechanec <[email-masked]>

---

From: Jan Pechanec <[email-masked]>
Date: Wed, 17 Dec 2014 15:17:40 -0800 (PST)

>from a user's removable token (smartcard).

	I agree that if we add slot description and manufacturer 
attributes, we should add slot ID as well.

<...>

>very explicit about their general unreliability, and they should explain

	agreed.

	J.

---

From: Jan Pechanec <[email-masked]>
Date: Wed, 17 Dec 2014 15:34:19 -0800 (PST)

>would change the attribute names to:

	Jaroslav, I think that most of the users of the URI may be 
quite ignorant about the PKCS#11 spec.  I don't think they will know 
about CKA_LABEL attribute, for example.  The thing was to come up with 
some "compromise between how precisely are the URI attribute names 
mapped to the names in the specification and the ease of use and 
understanding of the URI scheme", as stated in the ID.  I think it's 
much easier to use and read:

	pkcs11:object=my-key;token=my-token

	rather than:

	pkcs11:object-label=my-key;token-label=my-token

	where the use of "label" looks quite redundant.  Please note 
that it's about general usability and ease of use of the URI, not how 
precisely it is mapped to the actual spec.

	that why we also chose "type" over less understandable "class" 
which is btw also used in the spec in text:

	"CK_OBJECT_CLASS is a value that identifies the classes (or 
types) of objects that Cryptoki recognizes."

	Jan

---

From: Jan Pechanec <[email-masked]>
Date: Wed, 17 Dec 2014 15:52:50 -0800 (PST)

On Wed, 17 Dec 2014, Nikos Mavrogiannopoulos wrote:

>On Tue, 2014-12-16 at 17:42 -0600, Nico Williams wrote:
>> The rationale is this:
>>  - you may have a PKCS#11 library with various slots, and you may have
>>    builtin tokens as well as removable tokens, and...
>
>Correct.
>
>>  - you need to intelligently pick one at logon time so you don't prompt
>>    the user for PIN entry for tokens they don't have access to (e.g.,
>>    the TPM), just the one smartcard they plugged in.
>
>Correct.
>
>> PKCS#11 is pretty lousy at this, and all we have to match on are the
>> various slot and token attributes.
>> There are tokens that won't let you list public objects without PIN
>> entry.  And there are tokens where incorrect PIN entry can lead to
>> logout.  And PAM has limits as to what it can do in terms of
>> intelligently prompting a user for a slot/token/object.
>

	also, the PKCS#11 URI can be used to identify PKCS#11 objects, 
tokens, and libraries.  I think that adding attributes to add the last 
major element, a token, is a good idea.

	Jan.

---

From: Jan Pechanec <[email-masked]>
Date: Wed, 17 Dec 2014 16:15:49 -0800 (PST)

---

From: Jan Pechanec <[email-masked]>
Date: Wed, 17 Dec 2014 16:31:13 -0800 (PST)

>attribute? i.e. pkcs11:slot-description=metaslot

	hi Jaroslav, you could use the slot description to find the 
slot but that's not the case.  The thing is that you can use slot 0 
reliably there so slot-id would make sense in that context.  We have 
attributes that can be reasonable used only in certain scenarios and 
not others, like "pin-value".  Jan.

---

From: Jan Pechanec <[email-masked]>
Date: Wed, 17 Dec 2014 22:54:25 -0800 (PST)

>> and send it here but will not file it yet.

	hi, as Nikos mentioned yesterday, we discussed slot attributes 
in the past.  It was in Nov 2010 and I forgot about it.  It was a long 
discussion, 20+ emails, and I think the following summarizes it:

	- slot ID is unstable so its use is limited or even dangerous
	- slot description might be ok but it would still be better to 
choose slot simply via a number if needed (ie. not via URI)
	- exiting attributes are enough to identify what we need

	after giving it significant time thinking about it today I'd 
still add attributes for token description, manufacturer, and ID for 
this reasons:

	(1) as in pam_pkcs11 case, there will be scenarios where slot 
information will be needed.  It would be nice if it could be provided 
via a PKCS#11 URI when we can do that for objects, tokens, libraries 
and even PKCS#11 module paths.

	(2) neither slot description nor manufacturer is enough to 
uniquely identify a slot and it does not have serial number as a 
token.  While generally unstable, slot-id may be the only way to 
uniquely identify a slot.  If stability is provided either in the 
module or externally, its use may be justified in such scenarios.

	(3) if we do not add slot attributes people will keep asking 
about it

	I drafted new text so that we can see how it would look.  I 
think we should either add all 3 slot-* attributes or none.  The draft 
is attached and the diff as well.  There were more necessary changes 
but it basically comes to this:

@@ -216,10 +218,13 @@
   pk11-type            = "type" "=" *1("public" / "private" / "cert" /
                          "secret-key" / "data")
   pk11-id              = "id" "=" *pk11-pchar
+  pk11-slot-desc       = "slot-description" "=" *pk11-pchar
+  pk11-slot-id         = "slot-id" "=" 1*DIGIT
+  pk11-slot-manuf      = "slot-manufacturer" "=" *pk11-pchar
   pk11-pin-source      = "pin-source" "=" *pk11-qchar
   pk11-pin-value       = "pin-value" "=" *pk11-qchar

@@ -292,6 +298,20 @@
    |                      | the token           | CK_TOKEN_INFO        |
    |                      |                     | structure            |
    +----------------------+---------------------+----------------------+
+   | slot-description     | slot description    | "slotDescription"    |
+   |                      |                     | member of            |
+   |                      |                     | CK_SLOT_INFO         |
+   |                      |                     | structure            |
+   +----------------------+---------------------+----------------------+
+   | slot-id              | Cryptoki-assigned   | decimal number of    |
+   |                      | value that          | "CK_SLOT_ID" type    |
+   |                      | identifies a slot   |                      |
+   +----------------------+---------------------+----------------------+
+   | slot-manufacturer    | ID of the slot      | "manufacturerID"     |
+   |                      | manufacturer        | member of            |
+   |                      |                     | CK_SLOT_INFO         |
+   |                      |                     | structure            |
+   +----------------------+---------------------+----------------------+
    | token                | application-defined | "label" member of    |

@@ -332,6 +352,13 @@
    version number is mandatory.  Both "M" and "N" must be decimal
    numbers.

    An empty PKCS#11 URI path attribute that does allow for an empty

@@ -506,6 +534,10 @@
       minor version.  Resulting minor and major version numbers must be
       then separately compared numerically.

+   o  value of attribute "slot-id" must be processed as a specific
+      scheme-based normalization permitted by Section 6.2.3 of [RFC3986]
+      and compared numerically.
+

@@ -602,6 +634,12 @@
             manufacturer=Snake%20Oil,%20Inc.
             ?pin-value=the-pin

+   In the context where a slot is expected the slot can be identified
+   without specifying any PKCS#11 objects in any token it may be
+   inserted in it.
+
+     pkcs11:slot-description=Sun%20Metaslot
+

	regards, Jan.

--- draft-pechanec-pkcs11uri-16.txt-no-linebreaks	2014-12-17 22:22:24.000000000 -0800
+++ draft-pechanec-pkcs11uri-17.txt-no-linebreaks	2014-12-17 22:41:51.000000000 -0800
@@ -5,20 +5,19 @@
 Network Working Group                                        J. Pechanec
 Internet-Draft                                                 D. Moffat
 Intended status: Standards Track                      Oracle Corporation
-Expires: April 16, 2015                                 October 13, 2014
+Expires: June 20, 2015                                 December 17, 2014

                          The PKCS#11 URI Scheme
-                      draft-pechanec-pkcs11uri-16
+                      draft-pechanec-pkcs11uri-17
 
 Abstract
 
    This memo specifies a PKCS#11 Uniform Resource Identifier (URI)
-   Scheme for identifying PKCS#11 objects stored in PKCS#11 tokens, for
-   identifying PKCS#11 tokens themselves, or for identifying PKCS#11
-   libraries.  The URI is based on how PKCS#11 objects, tokens, and
-   libraries are identified in the PKCS#11 Cryptographic Token Interface
-   Standard.
+   Scheme for identifying PKCS#11 objects stored in PKCS#11 tokens, and
+   also for identifying PKCS#11 tokens, slots or libraries.  The URI is
+   based on how PKCS#11 objects, tokens, slots, and libraries are
+   identified in the PKCS#11 Cryptographic Token Interface Standard.
 
 Status of This Memo
 
@@ -35,7 +34,7 @@
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on April 16, 2015.
+   This Internet-Draft will expire on June 20, 2015.
 
 Copyright Notice
 
@@ -64,12 +63,12 @@
      3.5.  PKCS#11 URI Matching Guidelines . . . . . . . . . . . . .  10
      3.6.  PKCS#11 URI Comparison  . . . . . . . . . . . . . . . . .  11
    4.  Examples of PKCS#11 URIs  . . . . . . . . . . . . . . . . . .  12
-   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
-   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
-   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
-     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
+   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
+     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
      7.2.  Informative References  . . . . . . . . . . . . . . . . .  16
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17
 
 1.  Introduction
 
@@ -86,40 +85,42 @@
    It is desirable for applications or libraries that work with PKCS#11
    tokens to accept a common identifier that consumers could use to
    identify an existing PKCS#11 storage object in a PKCS#11 token, an
-   existing token itself, or an existing Cryptoki library (also called a
-   producer, module, or provider).  The set of storage object types that
-   can be stored in a PKCS#11 token includes a certificate, a public,
-   private or secret key, and a data object.  These objects can be
-   uniquely identifiable via the PKCS#11 URI scheme defined in this
+   existing token itself, a slot, or an existing Cryptoki library (also
+   called a producer, module, or provider).  The set of storage object
+   types that can be stored in a PKCS#11 token includes a certificate, a
+   public, private or secret key, and a data object.  These objects can
+   be uniquely identifiable via the PKCS#11 URI scheme defined in this
    document.  The set of attributes describing a storage object can
    contain an object label, its type, and its ID.  The set of attributes
-   that identifies a PKCS#11 token can contain a token label, a
-   manufacturer name, a serial number, and a token model.  Attributes
-   that can identify a Cryptoki library are a library manufacturer, a
-   library description, and a library version.  Library attributes may
-   be necessary to use if more than one Cryptoki library provides a
-   token and/or PKCS#11 objects of the same name.  A set of query
-   attributes is provided as well.
+   that identifies a PKCS#11 token can contain a token label,
+   manufacturer name, serial number, and token model.  Attributes that
+   can identify a slot are a slot ID, description, and manufacturer.
+   Attributes that can identify a Cryptoki library are a library
+   manufacturer, description, and version.  Library attributes may be
+   necessary to use if more than one Cryptoki library provides a token
+   and/or PKCS#11 objects of the same name.  A set of query attributes
+   is provided as well.
 
    The PKCS#11 URI cannot identify other objects defined in the
    specification [pkcs11_spec] aside from storage objects.  For example,
    objects not identifiable by a PKCS#11 URI include a hardware feature
    and mechanism.  Note that a Cryptoki library does not have to provide
    for storage objects at all.  The URI can still be used to identify a
-   specific PKCS#11 token or an API producer in such a case.
+   specific PKCS#11 token, slot or an API producer in such a case.
 
    A subset of existing PKCS#11 structure members and object attributes
    was chosen believed to be sufficient in uniquely identifying a
-   PKCS#11 token, storage object, or library in a configuration file, on
-   a command line, or in a configuration property of something else.
-   Should there be a need for a more complex information exchange on
-   PKCS#11 entities a different means of data marshalling should be
+   PKCS#11 storage object, token, slot, or library in a configuration
+   file, on a command line, or in a configuration property of something
+   else.  Should there be a need for a more complex information exchange
+   on PKCS#11 entities a different means of data marshalling should be
    chosen accordingly.
 
    A PKCS#11 URI is not intended to be used to create new PKCS#11
    objects in tokens, or to create PKCS#11 tokens.  It is solely to be
-   used to identify and work with existing storage objects and tokens
-   through the PKCS#11 API, or identify Cryptoki libraries themselves.
+   used to identify and work with existing storage objects, tokens, and
+   slots through the PKCS#11 API, or identify Cryptoki libraries
+   themselves.
 
    The URI scheme defined in this document is designed specifically with
    a mapping to the PKCS#11 API in mind.  The URI uses the scheme, path
@@ -188,7 +189,8 @@
                          pk11-model / pk11-lib-manuf /
                          pk11-lib-ver / pk11-lib-desc /
                          pk11-object / pk11-type / pk11-id /
-                         pk11-x-pattr
+                         pk11-slot-desc / pk11-slot-manuf /
+                         pk11-slot-id / pk11-x-pattr
   ; Query component and its attributes.  Query may be empty.
   pk11-qattr           = pk11-pin-source / pk11-pin-value /
                          pk11-module-name / pk11-module-path /
@@ -216,10 +218,13 @@
   pk11-type            = "type" "=" *1("public" / "private" / "cert" /
                          "secret-key" / "data")
   pk11-id              = "id" "=" *pk11-pchar
+  pk11-slot-manuf      = "slot-manufacturer" "=" *pk11-pchar
+  pk11-slot-desc       = "slot-description" "=" *pk11-pchar
+  pk11-slot-id         = "slot-id" "=" 1*DIGIT
   pk11-pin-source      = "pin-source" "=" *pk11-qchar
   pk11-pin-value       = "pin-value" "=" *pk11-qchar
-  pk11-module-name     = "module-name" = *pk11-qchar
-  pk11-module-path     = "module-path" = *pk11-qchar
+  pk11-module-name     = "module-name" "=" *pk11-qchar
+  pk11-module-path     = "module-path" "=" *pk11-qchar
   pk11-x-attr-nm-char  = ALPHA / DIGIT / "-" / "_"
   ; Permitted value of a vendor specific attribute is based on
   ; whether the attribute is used in the path or in the query.
@@ -259,6 +264,7 @@
    |                      |                     | PKCS#11              |
    |                      |                     | specification to     |
    +----------------------+---------------------+----------------------+
+   |                      |                     |                      |
    +----------------------+---------------------+----------------------+
    | id                   | key identifier for  | "CKA_ID" object      |
    |                      | object              | attribute            |
@@ -292,6 +298,20 @@
    |                      | the token           | CK_TOKEN_INFO        |
    |                      |                     | structure            |
    +----------------------+---------------------+----------------------+
+   | slot-description     | slot description    | "slotDescription"    |
+   |                      |                     | member of            |
+   |                      |                     | CK_SLOT_INFO         |
+   |                      |                     | structure            |
+   +----------------------+---------------------+----------------------+
+   | slot-id              | Cryptoki-assigned   | decimal number of    |
+   |                      | value that          | "CK_SLOT_ID" type    |
+   |                      | identifies a slot   |                      |
+   +----------------------+---------------------+----------------------+
+   | slot-manufacturer    | ID of the slot      | "manufacturerID"     |
+   |                      | manufacturer        | member of            |
+   |                      |                     | CK_SLOT_INFO         |
+   |                      |                     | structure            |
+   +----------------------+---------------------+----------------------+
    | token                | application-defined | "label" member of    |
    |                      | label, assigned     | the CK_TOKEN_INFO    |
    |                      | during token        | structure            |
@@ -332,6 +352,13 @@
    version number is mandatory.  Both "M" and "N" must be decimal
    numbers.
 
+   Slot ID is Cryptoki-assigned number that is not guaranteed stable
+   across PKCS#11 module initializations.  However, slot description and
+   manufacturer ID may not be enough to uniquely identify a specific
+   reader.  In situations where slot information is necessary use of
+   "slot-id" attribute may be justified if sufficient slot ID stability
+   is provided in the PKCS#11 provider itself or externaly.
+
    An empty PKCS#11 URI path attribute that does allow for an empty
    value matches a corresponding structure member or an object attribute
    with an empty value.  Note that according to the PKCS#11
@@ -421,8 +448,8 @@
 
 3.5.  PKCS#11 URI Matching Guidelines
 
-   The PKCS#11 URI can identify PKCS#11 storage objects, tokens, or
-   Cryptoki libraries.  Note that since a URI may identify three
+   The PKCS#11 URI can identify PKCS#11 storage objects, tokens, slots,
+   or Cryptoki libraries.  Note that since a URI may identify three
    different types of entities the context within which the URI is used
    may be needed to determine the type.  For example, a URI with only
    library attributes may either represent all objects in all tokens in
@@ -434,7 +461,7 @@
    resource.
 
    o  the consumer must know whether the URI is to identify PKCS#11
-      storage object(s), token(s), or Cryptoki producer(s).
+      storage object(s), token(s), slot(s), or Cryptoki producer(s).
 
    o  if the consumer is willing to accept query component module
       attributes only those PKCS#11 providers matching these attributes
@@ -488,11 +515,12 @@
 
    o  values of path component attributes "library-description",
       "library-manufacturer", "manufacturer", "model", "object",
-      "serial", "token", "type", and query component attribute "module-
-      name" must be compared using a simple string comparison as
-      specified in Section 6.2.1 of [RFC3986] after the case and the
-      percent-encoding normalization are both applied as specified in
-      Section 6.2.2 of [RFC3986].
+      "serial", "slot-description", "slot-manufacturer", "token",
+      "type", and query component attribute "module-name" must be
+      compared using a simple string comparison as specified in
+      Section 6.2.1 of [RFC3986] after the case and the percent-encoding
+      normalization are both applied as specified in Section 6.2.2 of
+      [RFC3986].
 
    o  value of attribute "id" must be compared using the simple string
       comparison after all bytes are percent-encoded using uppercase
@@ -506,6 +534,10 @@
       minor version.  Resulting minor and major version numbers must be
       then separately compared numerically.
 
+   o  value of attribute "slot-id" must be processed as a specific
+      scheme-based normalization permitted by Section 6.2.3 of [RFC3986]
+      and compared numerically.
+
    o  value of "pin-source", if deemed containing the filename with the
       PIN value, must be compared using the simple string comparison
       after the full syntax based normalization as specified in
@@ -527,12 +559,12 @@
 4.  Examples of PKCS#11 URIs
 
    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].
+   tokens, slots, and 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].
 
    An empty PKCS#11 URI might be useful to PKCS#11 consumers.  See
    Section 3.5 for more information on semantics of such a URI.
@@ -602,6 +634,12 @@
             manufacturer=Snake%20Oil,%20Inc.
             ?pin-value=the-pin
 
+   In the context where a slot is expected the slot can be identified
+   without specifying any PKCS#11 objects in any token it may be
+   inserted in it.
+
+     pkcs11:slot-description=Sun%20Metaslot
+
    The Cryptoki library alone can be also identified without specifying
    a PKCS#11 token or object.
 
@@ -668,7 +706,7 @@
 
    From those security considerations, Section 7.1 of [RFC3986] applies
    since there is no guarantee that the same PKCS#11 URI will always
-   identify the same object, token, or a library in the future.
+   identify the same object, token, slot, or a library in the future.
 
    Section 7.2 of [RFC3986] applies since by accepting query component
    attributes "module-name" or "module-path" the consumer potentially

---

From: Jaroslav Imrich <[email-masked]>
Date: Thu, 18 Dec 2014 00:57:16 +0100

Regards, Jaroslav

---

From: Jaroslav Imrich <[email-masked]>
Date: Thu, 18 Dec 2014 01:23:02 +0100

Regards, Jaroslav

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 19 Dec 2014 08:52:12 +0200

> some vendors use random values.

Jan,
 Given that this was the main argument for adding slot-id, is there any
other reason for adding it? Aren't the description and manufacturer
sufficient for the applications which want to restrict to a specific
slot?

regards,
Nikos

---

From: Jan Pechanec <[email-masked]>
Date: Thu, 18 Dec 2014 23:28:30 -0800 (PST)

>sufficient for the applications which want to restrict to a specific

	hi Nikos, I still think that its ID is 0 since I've been using 
it that way in C_GetMechanismInfo(0, ...).  However, my point is that 
some modules MAY provide stable IDs and since there is no serial 
number as for token then description/manufacturer may not be enough to 
uniquely identify a slot.  That's why it could be useful in certain 
situations.

	I somehow think that people would end up using it anyway and 
partly for that reason we added "pin-value" which was initially 
rejected, too.  If we define slot-id we avoid different parsers to use 
different names like "slot", "slotid", or "slot-id".  That's why I 
think it might be better to include it with a proper note.

	regards, Jan.

---

From: "Henry B (Hank) Hotz, CISSP" <[email-masked]>
Date: Fri, 19 Dec 2014 15:19:00 -0800

Does this ID, in fact, define an API which is sufficient to support realistic, interoperable code across a significant range of libraries and platforms? Is there a unique way to reference the authentication credential on my guaranteed-unique government-issued smart card regardless of which reader on which platform it’s plugged into?

Since I did not involve myself in the process, I do not know if those goals were excluded for some legitimate reason, but the discussion preceding makes it sound like they were not met.

Personal email.  [email-masked]

---

From: Nico Williams <[email-masked]>
Date: Fri, 19 Dec 2014 18:04:59 -0600

On Fri, Dec 19, 2014 at 03:19:00PM -0800, Henry B (Hank) Hotz, CISSP wrote:
> Does this ID, in fact, define an API which is sufficient to support
> realistic, interoperable code across a significant range of libraries
> and platforms? Is there a unique way to reference the authentication
> credential on my guaranteed-unique government-issued smart card
> regardless of which reader on which platform it’s plugged into?

Excellent questions.

As to the first: it's a rather abstract API.  I'm a bit concerned about
some of the semantics, that we might need to make matching a bit more
flexible.

IIRC there's a token that requires a login even to see public objects.
I might want to have a way to say "match public objects that don't
require login".

Or, I might want to provide slot/token attributes as hints, but not as
required attributes, that match preferentially but which are ignored if
not.

Abstract operations that I think should be described:

 - given a PKCS#11 URI, return a PKCS#11 provider (e.g., a handle
   returned by dlopen()/LoadLibrary*(), or a v-table, or whatever is
   appropriate in the caller's given programming language);

   This is described, actually.

 - given a PKCS#11 URI (and, optionally, a PKCS#11 provider) return a
   PKCS#11 provider and relevant PKCS#11 handles (token, session,
   object);

   This is also described.

 - given a PKCS#11 URI return a list of URIs for all matching tokens
   and/or objects;

   This is not described.

   E.g., given "pkcs11:" output a list of all {provider, slot},
   {provider, slot, token}, {provider, slot, token, public object} URIs
   for actual slots, tokens, public objects.

   E.g., given "pkcs11:" and a PKCS#11 session return all {provider,
   slot, token, object} URIs for actual objects reachable via that
   session.

 - given a PKCS#11 provider and handle of some sort, return a URI for
   it, with an option to include or exclude slot/token matching
   attributes.

   This is also not described, IIRC.

> Since I did not involve myself in the process, I do not know if those
> goals were excluded for some legitimate reason, but the discussion
> preceding makes it sound like they were not met.

They weren't.  And the I-D covers semantics in such a way that it
defines an abstract API, but perhaps it needs to be made more explicit.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 19 Dec 2014 18:06:59 -0600

One thing I just noticed is that you allow Unicode.  You might want to
reference RFC3987 (IRIs), for, e.g., advice as to normalization.

Nico
--

---

From: Jan Pechanec <[email-masked]>
Date: Fri, 19 Dec 2014 23:30:21 -0800 (PST)

>   This is also not described, IIRC.

	so, as well as we have "PKCS#11 URI Matching Guidelines" 
section, we might need "PKCS#11 URI Generation Guidelines" to discuss 
these things about "reverse mapping".  I will take a look at it.

	J.

---

From: Jan Pechanec <[email-masked]>
Date: Fri, 19 Dec 2014 11:02:48 -0800 (PST)

>That text discusses both the benefits and the risks.

	hi Nikos, thank you, I like that it is more explicit.  I made 
a minor modification since it could be implied that a slot description 
might have a different stability level than a slot manufacturer ID.

-   Slot ID is Cryptoki-assigned number that is not guaranteed stable
-   across PKCS#11 module initializations.  However, slot description and
-   manufacturer ID may not be enough to uniquely identify a specific
-   reader.  In situations where slot information is necessary use of
-   "slot-id" attribute may be justified if sufficient slot ID stability
-   is provided in the PKCS#11 provider itself or externaly.
+   Slot ID is a Cryptoki-assigned number that is not guaranteed stable
+   across PKCS#11 module initializations.  However, there are certain
+   libraries and modules which provide stable slot identifiers.  For
+   these cases, when the slot description and manufacturer ID is not
+   sufficient to uniquely identify a specific reader, the slot ID could
+   be used to increase the precision of the token identification.  In
+   other scenarios, using slot IDs is likely to cause usability
+   issues.

	attached is draft-pechanec-pkcs11uri-17-v2.txt

	there will more versions as I'm gonna address more comments 
that came in during the last call.

	regards, Jan.

---

From: Nico Williams <[email-masked]>
Date: Tue, 30 Dec 2014 01:41:30 -0600

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

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 30 Dec 2014 13:53:53 -0600

On Tue, Dec 30, 2014 at 12:14 PM, Jan Pechanec <[email-masked]> wrote:
> On Tue, 30 Dec 2014, Nico Williams wrote:
>         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:

No, I meant Unicode normalization.  It's a messy business.  Better say
nothing, because I think the thing to do is obvious enough, but if we
must say anything, it's that the various strings (e.g., token manuf)
are to be compared normalization-insensitively.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 30 Dec 2014 22:12:02 -0600

On Tue, Dec 30, 2014 at 5:07 PM, Jan Pechanec <[email-masked]> wrote:
>>As to how to say anything about this, here's what comes to mind:
>>
>>   Given a PKCS#11 URI template [RFC6570], an application MAY support
>>   listing URIs of PKCS#11 resources such that the resulting URIs can
>>   later be used to access the same resources if the template captured
>>   the necessary context.
>
>         I like the use of the templates.  I just quickly read through
> the RFC.  It looks that, for example, when generating a key pair, the
> application could support a default template with empty variables
> which would be used to optionally list a URI based on the
> CK_OBJECT_HANDLE of the generated key pair.  And it could accept a
> different one to override the default.  As mentioned above, I'd like
> to explicitly express that URI list is context specific.  I slightly
> modified the paragraph above:
>
>         When listing URIs of PKCS#11 resources the exact set of
>         attributes used in a URI is inherently context specific.  A
>         PKCS#11 URI template [RFC6570] support MAY be provided by a
>         URI generating application to list URIs to access the same
>         resource(s) again if the template captured the necessary
>         context.

Excellent.

>         I think we wouldn't need to say more about the matter.

Agreed.

Nico
--

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 31 Dec 2014 07:29:47 +0100

> On 30 dec 2014, at 20:53, Nico Williams <[email-masked]> wrote:
> 
> Better say

Sorry, but I have not heard the term "normalization-insensitively" before.

Can you explain what you mean?

   Patrik

---

From: Nico Williams <[email-masked]>
Date: Wed, 31 Dec 2014 01:03:33 -0600

> Can you explain what you mean?

Notionally, if you're comparing two unnormalized strings, you could
normalize both then compare the two normalized strings.

Of course, that can be inefficient (e.g., if it means allocating memory,
of if they will prove not equal in the first few codepoints) or
infeasible (e.g., if one of the strings is actually a hashed key to a
hash table).

What you can for the first case is compare code-unit by code-unit, with
a fast path for the cases that need no normalization, and normalizing
one character (but possibly multiple codepoints, of course) at a time.
This limits the total memory consumption, and anyways, for the common
case you can often expect an inequality result long before you're done
traversing the shorter string.  This is (can be, if you do it right), of
course, equivalent to normalizing both strings then comparing -- but it
should usually be much faster.

For the second case the thing to do is to normalize the key at hash
time, naturally.

[ZFS, incidentally, supports this for filesystem object names, and has
for years now.]

Now, PKCS#11 nowadays supports UTF-8 for things like "token label", but
it doesn't say anything about form -- why should it (see below)?

But where PKCS#11 URIs are intended to _match_ PKCS#11 resources by
name... apps will need to care about normalization.  In practice, like a
great many applications, doing nothing about normalization will probably
work fine (until the day that it doesn't).  But saying anything about
this could be tricky: what if there are two tokens with equivalent
labels, just in different forms?  Fortunately PKCS#11 URIs can match on
more attributes than labels, so there's that.

PKCS#11 should say "don't do that" or "don't do that, normalize to NFC"
(or NFD, whatever), but doesn't (or I didn't find where it does, if it
does), so the most that this document could say is "compare
normalization-insensitively where possible".

Nico
--

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 31 Dec 2014 08:33:28 +0100

> On 31 dec 2014, at 08:03, Nico Williams <[email-masked]> wrote:
> 

Ok, so what you say is that the side that is to calculate whether there is a match or not can do whatever normalization they want on the string(s)? Or do you say that whoever is doing a match is to not do normalization at all as the application (on client side) can and should define what normalization (in a broader sense, not only Unicode Normalization) must be possible to define?

In IDNA2008, as you know, we did choose the latter, but recommend applications to define what normalization to do, and that NFC is the Unicode Normalization to use.

   Patrik

---

From: Nico Williams <[email-masked]>
Date: Wed, 31 Dec 2014 01:46:45 -0600

On Wed, Dec 31, 2014 at 08:33:28AM +0100, Patrik Fältström wrote:
> Ok, so what you say is that the side that is to calculate whether
> there is a match or not can do whatever normalization they want on the
> string(s)? Or do you say that whoever is doing a match is to not do
> normalization at all as the application (on client side) can and
> should define what normalization (in a broader sense, not only Unicode
> Normalization) must be possible to define?

I'm saying something subtly different:

When you don't have the luxury of every string you might chance upon
being required to be normalized to the one true form, then you have
three choices:

 - give up

 - go fix whatever needs to be fixed so that you do have that luxury

   Here that would be: PKCS#11 itself, token vendors, and so on.

   I.e., not quite boiling the oceans but maybe a Great lake.

 - try your best

Normalization-insensitive comparison falls into the third bucket.

> In IDNA2008, as you know, we did choose the latter, but recommend
> applications to define what normalization to do, and that NFC is the
> Unicode Normalization to use.

For another example, in the world of filesystems we have:

 - most of the world just-uses-8 (UTF-8, ISO-8859-*, whatever, and when
   UTF-8, form is accidental)

 - some of the world insists on UTF-8 (though it's hard for a filesystem
   to enforce this: all it sees is octet strings)

    - some of the world normalizes to NFD (close enough) on create and
      lookup (e.g., HFS+)

    - some of the world is normalization-preserving-but-form-insensitive
      (ZFS)

The NFD case is obnoxious because even on those systems the input system
tends to produce NFC...  But anyways.  When you have no canonical form
for whatever reason, you can try form-insensitive matching.

Obviously there's aliasing to consider (but there is anyways), and so
on.  But none of this is terribly interesting here except for the "best
effort matching" idea, since that's probably the user-friendly and
not-too-dangerous thing to do here.

Nico
--

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 31 Dec 2014 08:54:00 +0100

> On 31 dec 2014, at 08:46, Nico Williams <[email-masked]> wrote:
> 

Ok, got it (and yes, I have been bitten myself a few times on the NFD issues with HFS+).

What I think is then needed is for this case:

1. A simple explanation what you really is talking about

What is the requirement on whom regarding normalization/mapping/whatever?

2. An evaluation whether the choice is the right one or not

The tricky part regarding choice of normalization (together with selection of code points allowed) is of course whether false positives or false negatives is the most troublesome event when trying to do matching.

I.e. say that matching algorithm is not defined. Is there a larger risk you will get false positives, and because of that possible attacks using some kind of "hamming-distance"/"homograph" (based on normalization)? Or rather, a description must be part of the security considerations section to explain what should not be done to not increase the risk for such attacks.

Let me just be clear here, I am very much in favor of specifications that say that "server side matching" should NOT do normalization, as that give most freedom for the applications that use whatever mechanism is defined. But, that to me set requirements on "client side" to do the right thing (for example like in IDNA2008 only be allowed to use certain code points).

So, given your choice on server side matching, what are the requirements on client side?

   Patrik

---

From: Nico Williams <[email-masked]>
Date: Wed, 31 Dec 2014 02:25:55 -0600

> What is the requirement on whom regarding normalization/mapping/whatever?

The I-D in question defines a URI scheme for PKCS#11 resources some of
whose naming attributes are character strings which PKCS#11 says should
be UTF-8.  PKCS#11 (*not* an Internet standard) does not say anything
about form.  Should this I-D say anything about form?

IMO the most it should say is "PKCS#11 doesn't specify a canonical form
for these labels, therefore the application may need to canonicalize
prior to comparing them".  The alternative is to say nothing.

PKCS#11 is an API.  PKCS#11 apps might "interoperate" using PKCS#11 URIs
communicated over, e.g., IPC (or plain old cut-n-paste).

PKC#11 URI _templates_ might well be exchanged far and wide, but still
not really as a part of a network protocol.

> The tricky part regarding choice of normalization (together with
> selection of code points allowed) is of course whether false positives
> or false negatives is the most troublesome event when trying to do
> matching.

This can be true even if we say nothing.

> Let me just be clear here, I am very much in favor of specifications
> that say that "server side matching" should NOT do normalization, as
> that give most freedom for the applications that use whatever

Where this works for filesystems, it is by accident: because input
methods "agree" on a canonical form for inputs.

As you know it actually doesn't work that well for filesystems:
"clients" (e.g., a program using a POSIX open() function) don't do
anything about normalization.  Neither do C library/run-time system call
stubs.  Neither do kernels.  Neither do <pick networked fs protocol>
clients.  They just don't.  Why would they?  These systems have lineages
much older than Unicode.

For IDNA, of course, the DNS client application has to canonicalize.

IOW, what to do depends on the application.  For filesystems I say: be
form-preserving-form-insensitive.  For IDNA there's no choice but to go
with clients-must-normalize.  Each app will be different.

> mechanism is defined. But, that to me set requirements on "client
> side" to do the right thing (for example like in IDNA2008 only be
> allowed to use certain code points).
> 

There's no network protocol here.  There's an API and applications
interoperating over IPC ("cut-n-paste").

Of course, the issues are the same, it's just that there's no "server"
to consider.  It's all as good as "clients".  Unlike IDNA, it's all
UTF-8, all the time, so that form-insensitive can work.

Nico
--

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 31 Dec 2014 10:09:39 +0100

> On 31 Dec 2014, at 09:25, Nico Williams <[email-masked]> wrote:
> 

Well, the definition of a URI like in this case in reality define a protocol with a client and server, if we think about the case when the URI is used. Someone create a URI (by typing, speaking, OCR:ing, copying) and use it to reach a resource.

So the issues are the same.

Regarding "the PKCS#11 does not talk about the issue, so why would IETF" is a question I think has a clear answer. IETF have in many cases created profiles, or let me say "interpretations" of definitions made elsewhere. Simply because IETF do not think the specification is crisp enough.

Look at UTF-8 for example.

> with clients-must-normalize.  Each app will be different.

Sure, that is my point.

What you say is that the IETF use of PKCS#11, without any specification of normalisation, mapping or otherwise, will not have any security implications what so ever regardless of what an application do (i.e. one party participating using one normalisation form, another do PRECIS mapping, a third do NFC,...)?

That is what I see you write, and if either I understand you wrong, or if that is not what you are saying, then a text must be created and added that explain the pitfalls -- at least as part of the security considerations section if not in the specification on how PKCS#11 is to be used.

   Patrik

---

From: Nico Williams <[email-masked]>
Date: Wed, 31 Dec 2014 03:19:10 -0600

On Wed, Dec 31, 2014 at 10:09:39AM +0100, Patrik Fältström wrote:
> Well, the definition of a URI like in this case in reality define a
> protocol with a client and server, if we think about the case when the
> URI is used. Someone create a URI (by typing, speaking, OCR:ing,
> copying) and use it to reach a resource.

As with filesystems, the "processes" creating and accessing the resource
are all clients.  There are no servers that can make right, therefore we
might as well not speak of them :)

(We're agreeing.)

> Regarding "the PKCS#11 does not talk about the issue, so why would
> IETF" is a question I think has a clear answer. IETF have in many
> cases created profiles, or let me say "interpretations" of definitions
> made elsewhere. Simply because IETF do not think the specification is
> crisp enough.

Yes.  The question is whether we should in this case.

I'm in favor of saying "do form-insensitive comparison".  I'd settle for
"always normalize to NFC when creating PKCS#11 resources" because, after
all, that's what IRIs need anyways, it's just that a PKCS#11 URI-using
app might not be in a position to make "normalize on create" happen.

OTOH, I think this is a minor issue, so if reaching consensus is hard,
then I say "say nothing", normatively anyways.

However, you're right that as far as Security Considerations go, we
can't say nothing.

> Look at UTF-8 for example.

Indeed.  We make things better.

> You also write:
> 
> > IOW, what to do depends on the application.  For filesystems I say:
> > be form-preserving-form-insensitive.  For IDNA there's no choice but
> > to go with clients-must-normalize.  Each app will be different.
> 
> Sure, that is my point.

Yes, we agree :)

> What you say is that the IETF use of PKCS#11, without any
> specification of normalisation, mapping or otherwise, will not have
> any security implications what so ever regardless of what an
> application do (i.e. one party participating using one normalisation
> form, another do PRECIS mapping, a third do NFC,...)?

No, it will have security considerations regardless.

The only way to help that is to force normalization on create, but as I
say, that's not something this spec can cause to happen or assume has
happened.

> That is what I see you write, and if either I understand you wrong, or
> if that is not what you are saying, then a text must be created and
> added that explain the pitfalls -- at least as part of the security
> considerations section if not in the specification on how PKCS#11 is
> to be used.

Yes.

Nico
--

---

From: John C Klensin <[email-masked]>
Date: Wed, 31 Dec 2014 10:41:28 -0500

--On Wednesday, 31 December, 2014 02:25 -0600 Nico Williams
<[email-masked]> wrote:

> The I-D in question defines a URI scheme for PKCS#11 resources
> some of whose naming attributes are character strings which
> PKCS#11 says should be UTF-8.  PKCS#11 (*not* an Internet
> standard) does not say anything about form.  Should this I-D
> say anything about form?
> 
> IMO the most it should say is "PKCS#11 doesn't specify a
> canonical form for these labels, therefore the application may
> need to canonicalize prior to comparing them".  The
> alternative is to say nothing.

Nico, commenting on this issue only and doing it in more general
terms (going a bit beyond Patrik's "IETF have in many cases
created profiles...": The conventions for IETF-approved
publications include that they are supposed to support
interoperability and that features/ characteristics that would
interfere with interoperability are grave defects.  This is
especially true of Standards Track documents, where 2026 very
clearly makes "known technical omissions" absent specific
reasons for waiving that requirement.  At least by convention
for nearly two decades, the IESG reaching such a conclusion
requires clear documentation of the defect and the reason for
making an exception in the specification and usually in the Last
Call.

Nowhere in our procedures is that any provision for a
standards-track document to get a waiver because some other
standards body got sloppy, did something that wouldn't meet our
standards, or didn't quite understand the implications of what
they were doing.

Now, we've had a lot of specs written on the assumption that a
sufficient path to internationalization of a protocol designed
around ASCII (or an ISO 646 profile or IA5) was "just say
'UTF-8' where we used to say 'ASCII', use UTf-8, and go merrily
on your way".  After a while, with help from both experience and
some of our friends, we figured out that wasn't a good idea and
various specs now, appropriately, push back anything resembling
"just use UTF-8" (a statement like "It's all UTF-8, all the
time, so that form-insensitive can work" (from your earlier
note, not the spec) is an example of "just used UTF-8" thinking.

In addition, we have an often-ignored requirement for an
"Internationalization Considerations" section when a document
touches on i18n issues (See Section 6 of RFC 2277).  Personally,
I don't think it is important for documents that really address
i18n topics but that it is extremely so when, e.g., the spec
doesn't really address the i18n issues but repeatedly says
things like "...in environments that are not strictly limited to
US-ASCII".  Without specific instructions (and I can find none
on quick skimming), that is dealing with i18n considerations by
aggressive handwaving.   One of the more impressive examples of
this is

	"...an implementer ought to use the spirit rather than
	the letter of the rules when generating or parsing these
	formats in environments that are not strictly limited to
	US-ASCII."

But the most frequent complaint we hear about i18n from protocol
designers in the IETF is similar to "I'm not an expert on this
stuff and don't intend to become one; just tell me what to do".
The above does nothing for "just tell me what to do".  It
instead implies that the implementer should become enough of an
expert to figure out what the implications of "the spirit"
actually are.  FWIW, I can't easily figure that out because
there are so many whitespace characters, zero-width things,
breaks and non-breaks of various sorts, etc., in Unicode to say
nothing of conventions in various scripts that don't separate
"words" with space-like things.  There is some guidance in a few
Unicode specs, but they are hard to read and understand, much
less apply reasonably to a particular situation, unless one
already has a good understanding of the Unicode Standard and
some of the issues involved.

Normalization is easily dealt with by making a clear statement.
Historically, our experience has been that the obvious
reasonably clear statement is "use NFC".  The growing community
opinion (including in the W3C i18n effort which is much more
active than various IETF-related groups) seems to be "don't
worry about normalization until comparison (or equivalent) time
because it will have to be done again then anyway to be safe).
You (and the authors) pick, but I agree with Patrik that
something needs to be said unless you take the alternate
suggestion below.

But other issues, like the whitespace one called out above, are
far more complex and require serious treatment of some sort.

Alternate suggestion in the interest of getting this out and
recognizing that this is mostly a PKCS#11 problem (presumably
ITU and/or RSA, but what do I know) and shouldn't be an IETF one:

(1) Put in an Internationalization Considerations section, which
I believe is required anyway.

(2) Indicate that PKCS#11 severely underspecifies issues
associated with characters outside the ASCII repertoire and,
especially, contexts not associated with European languages.  

(3) Say that, at least until PKCS#11 is updated to more
adequately handle and specify i18n issues, such characters, and
certificates that use them, SHOULD NOT be used in or referenced
from URIs, unless there is a clear need and the issues
associated with the characters to be used are clearly understood.

(4) As appropriate, update the handwaving in this document to
point to that new section.

That would make it very clear that you are not telling people
how to do it and would make the warning as obvious as it should
be.

Finally...

> PKCS#11 is an API.  PKCS#11 apps might "interoperate" using
> PKCS#11 URIs communicated over, e.g., IPC (or plain old
> cut-n-paste).
> 
> PKC#11 URI _templates_ might well be exchanged far and wide,
> but still not really as a part of a network protocol.

For many years, the IETF had a very strong "we don't do APIs"
policy.  That was motivated, at least in part, because APIs tend
to make strong assumptions about programming language and
operating system environments, either favoring some over others
(a business we didn't want to be in) or not standing the test of
time as things outside the IETF evolved.  The view was that we
were much better off specifying requirements and protocols and
leaving APIs to particular languages, libraries/packages, or
operational environments.

Times change but it seems that many of the times we do APIs drop
us into a rat hole similar to this one in which we are trying to
do an overlay to a spec over which we have little or no control.
Part of the problem is that an API is a somewhat different type
of beast from a protocol-style Technical Specification.  If we
are going to keep doing these, it may be time to modify/update
2026 to introduce a new class of standards-track document.
Until and unless we are willing to do that, I think we'd better
get used to these rough edges and stop pretending that they are
good excuses for work that doesn't meet the Technical
Specification target criteria.

   john

---

From: Nico Williams <[email-masked]>
Date: Wed, 31 Dec 2014 13:44:31 -0600

> standards, or didn't quite understand the implications of what

I think you're misreading what I wrote.  Please read my latest reply to
Patrik.

> on your way".  After a while, with help from both experience and

We've had specs that naively said "normalize" too.  NFSv4 comes to mind.

> note, not the spec) is an example of "just used UTF-8" thinking.

You're twisting my words.  I very specifically said that what to do
about normalization depends on the application.  I don't think there's a
one-size-fits-all approach, not without a time machine on hand.

> Normalization is easily dealt with by making a clear statement.

My experience with filesystems is that that's an easy statement to make
and much harder to make real.  This is why ZFS is form-preserving/
form-insensitive: it was the best solution in a world where none of the
moving parts could be expected to normalize to the one true canonical
form.

A funny story from back when: Apple apparently was porting ZFS to OS X,
and they made it normalize to NFD (close enough) to match HFS+.  This
caused breakage.  As I recall it the notable breakage was with git, and
ZFS got blamed by Linus T.  But of course, the problem was that the
filesystem in question (not ZFS, but ZFS modified to normalize to NFD)
was using an inconvenient NF.  That HFS+ normalizes to NFD is a reality
that can't be changed.  That input methods tend to produce NFC-ish
output is also a reality that can't be changed.  That system call stubs
in C libraries don't apply codeset conversions and normalization is a
reality that can be changed, but only at great effort.  I can go on.

The point is that "just normalize" is naive, and each application
requires careful consideration.

> something needs to be said unless you take the alternate

I agree with Patrick that something needs to be said at the very least
in the security considerations section.

Also, *I* brought up the issue, as I'm rather sensitive to normalization
issues.  *I* suggested something minimal and said that if there was no
consensus for it, I'd be fine with saying nothing, mostly because it's
late in the day and I don't think it will be critical in this case.

> ITU and/or RSA, but what do I know) and shouldn't be an IETF one:

RSA.

> I believe is required anyway.

Is it?  I'd like that to be required.

> especially, contexts not associated with European languages.  

Sure.

> associated with the characters to be used are clearly understood.

I think that's too strong.

> point to that new section.

Sure.

> policy.  That was motivated, at least in part, because APIs tend

Please point to a Standards-Track document that says that.

> operational environments.

We certainly have done APIs.  E.g., SCTP socket API, GSS-API.

GSS comes in two flavors: abstract, and bindings of the abstract API to
specific programming languages.

FYI, GSS defines a protocol _pattern_ (and just a handful of bits on the
wire of that pattern), but vast majority of it is an API.  Compare to
SASL, which also defines a protocol pattern, practically no bits on the
wire, and no API (of course, there are SASL APIs, because at the end of
the day most application developers want off-the-shelf implementatins of
such things).

Should we stop all work on GSS because you claim there's a policy
against APIs?

Further, I believe a lot of real problems have arisen from the lack of
APIs.  In particular I believe end-to-end IPsec is useless without
binding per-packet security into a higher-order construct like "packet
flow", which necessarily involves exposure of IPsec information to
higher layers, which then necessitates a notional (abstract) API.  That
API does not exist, therefore IPsec has been relegated to small networks
and VPNs, where local configuration is small, manageable, and can be
assumed.  The lack of an abstract API here hurt adoption.

> do an overlay to a spec over which we have little or no control.

This might well be the case here, but the problem isn't "oh noes, it's
API", but that the API (which could have been a protocol) in question is
defined _elsewhere_.

> of beast from a protocol-style Technical Specification.  If we

I disagree vehemently.  See above examples.  I think this opinion of
yours is harmful and hand-wavy.  If you have a detailed argument for why
APIs are so different from "protocol-style" specs that we should not
engage in API design, I'd like to see it.

> 2026 to introduce a new class of standards-track document.

To read RFC2026 as a prohibition on IETF work on APIs is real stretch.
Clearly many have disagreed with that take over the years since RFC2026
was published, and they (we) have published RFCs that contravene your
reading of RFC2026.

Nico
--

---

From: Jan Pechanec <[email-masked]>
Date: Mon, 29 Dec 2014 22:37:46 -0800 (PST)

>reference RFC3987 (IRIs), for, e.g., advice as to normalization.

	hi Nico, that's a good point.  I've added a note there (plus 
an entry to the References section):

--- draft-pechanec-pkcs11uri-17-v5.txt	2014-12-29 21:46:05.000000000 -0800
+++ draft-pechanec-pkcs11uri-17-v6.txt	2014-12-29 22:32:16.000000000 -0800
@@ -193,10 +193,13 @@
    characters in the unreserved set or to permitted characters from the
    reserved set should be percent-encoded.  This specification suggests
    one allowable exception to that rule for the "id" attribute, as
-   stated later in this section.  Grammar rules "unreserved" and "pct-
-   encoded" in the PKCS#11 URI specification below are imported from
-   [RFC3986].  As a special case, note that according to Appendix A of
-   [RFC3986], a space must be percent-encoded.
+   stated later in this section.  Note that if a URI does carry
+   characters outside of the ASCII character set a conversion to an
+   Internationalized Resource Identifier (IRI) defined in [RFC3987] may
+   be considered.  Grammar rules "unreserved" and "pct-encoded" in the
+   PKCS#11 URI specification below are imported from [RFC3986].  As a
+   special case, note that according to Appendix A of [RFC3986], a space
+   must be percent-encoded.

    The PKCS#11 specification imposes various limitations on the value of
    attributes, be it a more restrictive character set for the "serial"

	latest working version of draft 17 (v6) is attached.

	thank you, Jan.

---

From: Jan Pechanec <[email-masked]>
Date: Mon, 29 Dec 2014 23:13:18 -0800 (PST)

>these things about "reverse mapping".  I will take a look at it.

	I've been thinking about this for the past days and I'm not 
sure if such guidelines should be provided since it very much depends 
on how a URI will be used and in what scenarios.

	for example, if referencing a key pair, an "id" attribute is 
there to distinguish multiple public-key/private-key pairs held by the 
same subject.  However, I think that if used on a command line to 
provide an access to the key pair, it would be used only if there 
really were multiple keys of the same name.  And that information I 
may acquire only when I try not to use those attributes when I get an 
error message about multiple key pairs - which may or may not be 
acceptible.  On the other hand, it may be a good idea to use it always 
if such a URI would be provided in a long lived configuration file, 
for example.

	similarly with a token.  To uniquely identify a token (either 
to refence it by itself or because I have objects of the same name in 
multiple tokens), manufacturer and serial number should be used but 
again, I'd rather use the token (name) attribute unless I have 
multiple tokens of the same name.  What is more, if the token is not 
guaranteed unique then I may need library attributes (say for soft 
tokens in multiple libraries).  And even that may not be sufficient if 
I link to the same libraries from different file paths in which case 
the module attributes may be needed.  Again, I'd want to use all these 
attributes only when such a situation arises.

	if the consensus is that I should provide a paragraph that 
would summarize ideally in a more succint way what I've been saying 
above (or whether I should do something else) I will try to come up 
with a reasonable text but at this point I still don't think it is 
necessary.

	thank you, Jan.

---

From: Nico Williams <[email-masked]>
Date: Tue, 30 Dec 2014 02:14:21 -0600

On Mon, Dec 29, 2014 at 11:13:18PM -0800, Jan Pechanec wrote:
> >> [discussion about an abstract "list PKCS#11 resource URIs"
> >> operation elided.]
> 

Which attributes to use for the listing would have to be
context-specific.  Most apps/users would never want to match on slot
attributes, but some might.  We can't say much about that.

Users will mostly not be writing PKCS#11 URIs, that's for sure.  PKCS#11
is not very user-friendly...

Where a PKCS#11 URI is used, I suspect it will be produced by an
application, and then cut-n-pasted around as necessary by the user.

Do we have to say much about how the app should go about forming a URI
for a PKCS#11 resource?  It depends.

If the same app will consume the same URI, then we need not say
anything.  If a different app will consume the same URI then we might
have to.  This is about inter-app interoperation.

I don't think we could say much more without gaining experience with
deployment.

Caveat emptor: I'm not too conversant with URI templating, so I don't
know how to phrase this correctly...

Nico
--

---

From: Jan Pechanec <[email-masked]>
Date: Tue, 30 Dec 2014 10:14:18 -0800 (PST)

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.

---

From: Jan Pechanec <[email-masked]>
Date: Tue, 30 Dec 2014 12:43:58 -0800 (PST)

>are to be compared normalization-insensitively.

	yes, in that case I agree that we don't need to say anything.  
Thanks for bringing this up, Jan.

---

From: Jan Pechanec <[email-masked]>
Date: Tue, 30 Dec 2014 15:07:15 -0800 (PST)

>attributes, but some might.  We can't say much about that.

	yes, and I think it will be important to state in the text 
that the choice of exact set of attributes is context specific.

>have to.  This is about inter-app interoperation.

	I'd say it does not matter much whether it's the same 
application which is gonna use the generated URI or not, it's all 
about the context - if it's enough or not.

	thank you, J.