Re: Extension of the agent protocol for the PKCS#11 URI scheme

[Nicolas Williams <Nicolas.Williams%oracle.com@localhost>]

On Wed, Dec 08, 2010 at 11:45:28AM -0500, Jeffrey Hutzelman wrote:
> On Wed, 2010-12-08 at 13:58 +0100, Jan Pechanec wrote:
> > 	we could reuse some existing messages, eg. put the URI into 
> > reader_id in SSH_AGENTC_ADD_SMARTCARD_KEY used by OpenSSH but that would 
> > be a hack. The way how OpenSSH works with keystores is different, all 
> > available keys from a PKCS#11 provider are used, if I read the code 
> > correctly.
> 
> IIRC, the existing smartcard support doesn't use PKCS#11 at all.  The
> only implementation I've played with transmits both a reader ID (which
> is really what PKCS#11 would consider a single slot) and a key ID, so in
> fact only a single key is named.  In any case, I agree that reusing
> those messages seems like a hack, and adding new messages may be more
> appropriate.  I'd suggest doing something a bit more general, but I
> think the community has mostly settled on PKCS#11 as being the primary

I agree as well that introducing new messages based on PKCS#11 is better
than abusing the existing SSH_AGENTC_ADD_SMARTCARD_KEY message.

> abstraction for this (which would be fine, if it didn't deal so poorly
> with dynamic changes in the number of slots).

A reasonably good solution is to pretend that there are many slots -- as
many as might ever be expected to exist.  But I agree, PKCS#11 is rather
limited here.

> > 	please let us now if the numbers we use clash with any 
> > implementation of yours or if you have any other concerns.
> 
> I think it's a (past) mistake to think of the agent protocol as being
> something private, rather than something for which interoperability is
> desirable and therefore for which standardization is appropriate.  I
> imagine if someone wanted to write an I-D documenting the protocol and
> setting up a registry for these values, that would be a good thing.  Not
> that I'm volunteering, mind you.

That's why Jan posted this.  There are multiple implementors, and we all
like to make sure that our implementations interop.  But we lack both,
Standards-Track specifications and registries.  Therefore posting here
(and perhaps elsewhere?) seems like a reasonable way to pseudo-register
protocol elements.

Nico
--