pkcs and host keys

[William Ahern]

On Thu, Jan 19, 2012 at 07:23:41PM +0100, Jean-Michel Pour? - GOOZE wrote:
> Dear William,
> 
> > able to get it to work (with three different cards), and apparently
> neither
> > has Apple, who attempted to integrate it but failed (I've never been
> > able to
> > get a smart card to work in OS X).
> 
> That's a pity you did not buy the right products. But never say "never".

The first product I ever bought was the Schlumberger Cryptoflex, which at
the time was *the* best supported chip for OpenSC. It was still a disaster.
I couldn't even be sure it was using the builtin operations (via the PKCS11
interface) instead of just the fancy flash drive PKCS12 mode. 10 years later
the whole industry is still a disaster from a software perspective.

When my concern is the privacy and integrity of my token and its private
key, having to deal with a huge, broken software stack does not build
confidence. If I have to question the ingegrity of the software stack, I
might as well just rely on my .ssh/id_dsa key.

> A lot of smartcards/tokens have partial OpenSC implementation.
> Smartcards and tokens are also usually quite expensive, because vendors
> like to change hardware and drivers. 
> 
> This is not the case of our products, which work perfectly and
> unexpensive.

How can you guarantee--or at least address the concern--that your vendor
won't discontinue the chip and start selling a new chip that requires a new
driver? For example, is the ePass2003 backwards compatible with the ePass?
Granted, I suppose 9 years is a good run. But what about, for example, the
ePass201x? I wouldn't be surprised if SHA-1 is severely broken in the next 5
years, so the ePass2003 seems like it should be near its end-of-life if it
can't do SHA-2, or the SHA-3 (which should be published soon).

This has been the problem with these cards all along. The chips come and go,
and each new chip has a totally different interface. It's ridiculous. The
industry is driven by fad after fad, each vendor simultaneously trying to
lock-in their customers while trying to address the dismal state of
interoperability caused by vendor lock-in in general.

<snip>
> PIV are outdated and frankly the ePass2003 is based on a SINGLE
> integrated ST Microelectronics chip with EAL5+ certification.

Does ISO 7816-8 provide a similar specification to PIV (and NIST SPs 800-73
and 800-78)? And if so, is it more widely supported by other chips? CCID is
by itself insufficient, though I've wondered if you could build a
maintainable stack using a domain specific script language tuned to CCID so
that "drivers" could be plain-text and much simpler to write.

> This is quite a revolutionary token which weights only 6 gramms.

I have no doubt that it's a great token. (I've almost purchased the
ePass2003 from Gooze several times, and as far as I can tell your shop is
definitely the best around.) But the issue, IMO, isn't which token is the
best. It's how best to support tokens in general with a minimal amount of
support code.

I don't mean to come across as combative. I'm just passionate about the
adoption of crypto tokens, but don't see it happening until the software
issues are resolved.