support for non-openpgp cards

[Simon Josefsson]

pgut001 at cs.auckland.ac.nz (Peter Gutmann) writes:

> Simon Josefsson <jas at extundo.com> writes:
>
>>IMHO, you should not care about broken implementations.  There is a well-
>>defined PKCS#11 specification, even including header files. Write code for
>>the specification.  If something doesn't work because someone isn't
>>implementing the specification, that's their problem.
>
> That would rule out about 99% of all PKCS #11 implementations in existence.
> The problem is twofold, firstly the spec is very flexible (since it covers a
> large number of crypto devices ranging from little tinkertoy smart cards up to
> high-end crypto coprocessors) so there's a lot of room for interpretation,
> secondly since the major driving force for PKCS #11 for many years was
> Netscape, many vendors implemented whatever Netscape needed, which includes
> Netscape bugs.  So you can't create an implementation "for the specification"
> both because there are many ways to interpret it and because historically
> drivers have done things other than the way the spec said they should.

Then we could try to fix those buggy implementations, and improve the
specification.

Meanwhile, a realistic way forward might be to write clean code that
rely on unambiguous APIs, and move the bug workaround ugliness into
some library that talks with the drivers.  Then ideally, over time, as
implementations are improved, the middle library will gradually be
smaller and smaller.  And throughout that time, the core application
code will be clean and readable.

I think that writing code that cater to buggy external packages lead
to unreadable and potentially dangerous code.  So I believe strongly
that bug-compatibility code should be separated from core
applications.  For POSIX/C99 functions, I recommend gnulib
<http://www.gnu.org/software/gnulib/>.  Another advantage is that many
packages will benefit from the same middle-layer code.  That leads to
higher quality of the bug-compatibility code, than what could be hoped
for if every project had to maintain it's own such code.

The OpenSSH team seem to use a similar strategy, and the code is
almost a joy to read now.

Regards,
Simon