Subject: [saag] new I-D on the PKCS#11 URI Scheme for naming objects

From: Jan Pechanec <[email-masked]>
Date: Mon, 16 Aug 2010 18:29:28 +0200 (CEST)

hi, attached is a new draft. I haven't filed that yet, if you 
have any comments or issues, I'd like to incorporated those before 
filing the 02 version.

	thanks, Jan.

-- 
Jan Pechanec
http://blogs.sun.com/janp

---

From: Darren J Moffat <[email-masked]>
Date: Mon, 16 Aug 2010 17:18:02 +0100

> have any comments or issues, I'd like to incorporated those before

I'm fairly sure the use of the ';' sub-separator may have come from me 
but I'm now wondering if we should be using '?' instead since 
essentially these are query components since they are in many cases 
going to be passed to the PKCS#11 C_FindObjects*() set of functions (or 
their equivalent).

The pinfile though I think should be ';' separated since it isn't 
actually part of the tokens that identify the object.

For example:

pkcs11:object=my-pubkey?objecttype=public
pkcs11:object=my-key?objecttype=private;pinfile=/secrets/mytoken_pin

I don't think we would have a '?' after the ':' just like currently we 
don't have a ';' after the ':'.

I don't really have a strong preference, more just throwing it out for 
discussion.

I'm pretty sure our lack of "//" after the ':' is correct since there 
isn't an authority to specify here.

-- 
Darren J Moffat

---

From: Jan Pechanec <[email-masked]>
Date: Mon, 16 Aug 2010 22:51:34 +0200 (CEST)

On Mon, 16 Aug 2010, Darren J Moffat wrote:

> I'm fairly sure the use of the ';' sub-separator may have come from me but I'm
> now wondering if we should be using '?' instead since essentially these are
> query components since they are in many cases going to be passed to the PKCS#11
> C_FindObjects*() set of functions (or their equivalent).
>
> The pinfile though I think should be ';' separated since it isn't actually part
> of the tokens that identify the object.
>
> For example:
>

	so object would be part of the path and anything else is part of 
the query? That does not seem to be complete to me. If there is to be a 
path and a query then the token attributes should be part of the path as 
well, I think.

	we should be also able to reference tokens aside from 
referencing objects so the "object" attribute may be missing. On the 
other hand, if we use a query then all attributes aside from a pinfile 
may be part of it since all such attributes can be used in the 
C_Findbject*() functions. And the pinfile attr does not fit anywhere. 
Anyway, I think it might be more complicated than needed.

	path does not have to be hierarchical so we can put all 
attributes into the path as it is now, including the pinfile. Also, only 
"?" or "/" can separate data within the query component (at least that's 
what I understand from "3.4 Query" section). That would mean that the 
pinfile attribute could not be separated by ";" in the query.

	I think there is a thin line between a path and a query. A path 
with wildcards can be easily seen as a query, for example: /etc/*

> I don't think we would have a '?' after the ':' just like currently we don't
> have a ';' after the ':'.
>

	I'd rather keep the current approach, it seems simpler to me.

> I'm pretty sure our lack of "//" after the ':' is correct since there isn't an
> authority to specify here.

	yes, I agree.

	the draft is probably lacking a section that would discuss what 
components from the generic URI are used and why.

	J.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 17 Aug 2010 10:24:00 +0200

Hello,
 I like the changes. May I suggest the addition of the following fields:

 ; The CK_INFO manufacturer ID field
 pk11-lib-manufacturer       = "library-manufacturer" "=" pk11-value
 ; The CK_INFO library version field
 pk11-version-value                = [0-9]+ "." [0-9]+
 pk11-lib-version       = "library-version" "=" pk11-version-value
 ; The CK_INFO library description field
 pk11-lib-description       = "library-description" "=" pk11-value

Those would allow to uniquely identify an object across a system with
several pkcs #11 providers.

best regards,
Nikos

---

From: Jan Pechanec <[email-masked]>
Date: Tue, 17 Aug 2010 13:10:21 +0200 (CEST)

>several pkcs #11 providers.

	I agree, that seems reasonable. The syntax of the version will 
be using 1*DIGIT but that's just a technical point.

	Darren?

	J.

---

From: Darren J Moffat <[email-masked]>
Date: Tue, 17 Aug 2010 12:14:36 +0100

> be using 1*DIGIT but that's just a technical point.

Looks perfectly reasonable addition to me.

-- 
Darren J Moffat

---

From: Jan Pechanec <[email-masked]>
Date: Tue, 17 Aug 2010 13:59:51 +0200 (CEST)

>be using 1*DIGIT but that's just a technical point.

	attached is a modified draft. I added three attributes listed 
above and also one example that shows that the URI can be used to 
identify the library alone without any objects.

	if I understand the spec correctly:

typedef struct CK_VERSION {
  CK_BYTE       major;  /* integer portion of version number */
  CK_BYTE       minor;  /* 1/100ths portion of version number */
} CK_VERSION;

	then the minor version must be 0-99, so the lib version 
attribute is defined as:

pk11-lib-ver            = "library-version" "=" 1*DIGIT "." 1*2DIGIT

	in theory we should limit the major version to 0-255 (CK_BYTE) 
but I'm not sure it's worth it. Is it?

	J.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 17 Aug 2010 14:31:24 +0200

> but I'm not sure it's worth it. Is it?

I wouldn't add any limitation for the numbers. Those are returned by
the library itself and might not be really scrutinised. Would we
really want to fail calculating a URL on a library that returns 2.101
as a version number?

regards,
Nikos

---

From: Jan Pechanec <[email-masked]>
Date: Tue, 17 Aug 2010 14:39:51 +0200 (CEST)

>really want to fail calculating a URL on a library that returns 2.101

	hmm, that seems right, this is what Solaris soft token library 
returns:

$ ./a.out 
library manuf ID: Sun Microsystems, Inc.          
library description: Sun Crypto Softtoken            
library version: 1.184

	shall we relax a need for the minor version as well?

	or

 pk11-lib-ver     = "library-version" "=" 1*DIGIT *( "." 1*2DIGIT)

	we relaxed the number of digits so I'd support the latter 
attribute definition.

	J.

---

From: Jan Pechanec <[email-masked]>
Date: Tue, 17 Aug 2010 14:58:51 +0200 (CEST)

>	we relaxed the number of digits so I'd support the latter 

	latest version with the above mentioned attribute definition:

	http://www.devnull.cz/tmp/draft-pechanec-pkcs11uri-02.txt

---

From: Stef Walter <[email-masked]>
Date: Wed, 18 Aug 2010 10:14:18 +0200

> 	I'd rather keep the current approach, it seems simpler to me.

I agree with keeping the current approach and not trying to match this
too much to a query or a path.

A PKCS#11 URI like the following can sometimes represent a token, other
times all the objects on that token, depending on the application using
it and the context in which it is used:

pkcs11:token=Token%20Name

Cheers,

Stef

---

From: Jan Pechanec <[email-masked]>
Date: Wed, 18 Aug 2010 10:26:45 +0200 (CEST)

On Wed, 18 Aug 2010, Stef Walter wrote:

	hi Stef,

>too much to a query or a path.

	technically, all current attributes are in the path section now.

>pkcs11:token=Token%20Name

	agreed, this is also one of the examples in the I-D. Now it can 
represent a Cryptoki library as well.

	I'll publish a new draft version as it is now:

	Darren, is that OK with you?

	cheers, J.

---

From: Darren J Moffat <[email-masked]>
Date: Wed, 18 Aug 2010 09:47:11 +0100

> 	Darren, is that OK with you?

Yes I'm happy with it as is.

-- 
Darren J Moffat

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 19 Aug 2010 12:09:28 -0500

The thought occurred to me that an authority part would be useful, but
then I realized that an authority part cannot be mapped to a PKCS#11 API
call.

I think it'd be useful to:

 - State, in the Abstract and/or Introduction, that this URI scheme is
   designed specifically with a mapping to the PKCS#11 API in mind.

   You'd think this would be obvious, but it's not.  It's one thing to
   map a PKCS#11 URI to PKCS#11 concepts; it's another to map it to API
   elements.

 - Explain that an authority part cannot be mapped to PKCS#11 API
   elements, therefore there is no authority part in the PKCS#11 URI
   scheme.

 - [maybe] Provide some example C code snippets showing how to open a
   session with a token identified by various URI elements.  (But don't
   include code for parsing a URI, of course.)

Also, a PKCS#11 version would be useful.  Not just a provider version
but an actual PKCS#11 version.  This would allow the addition of new URI
elements in the future that cannot be understood by older
implementations, but with older implementations able to detect version
mismatch.

Nico
--

---

From: Jan Pechanec <[email-masked]>
Date: Fri, 20 Aug 2010 13:36:00 +0200 (CEST)

>then I realized that an authority part cannot be mapped to a PKCS#11 API

	hi Nico, thanks for feedback, I'll take a look at it the next 
week.

	meanwhile, I filed the new 02 version since the ABNF definition 
is quite different from the version 01 and there was a general agreement 
on 02.

	http://www.ietf.org/id/draft-pechanec-pkcs11uri-02.txt
	
	cheers, J.