AW: Crypto-API

[Warich, Eyck]

Hi Werner!

> The API is not build upon PKCS, but on an own API which I think is
> much more modern than the one of PKCS11 and much more flexible.  It
> uses S-Expressions (like spki) for many of it's data structures and
> is therefore quite easy to extend.
> 
[ew]  Ok, i'll have to take a look at it :).

> > My idea behind that is the integration of more specific crypto
> > devices as smartcards. I would suggest the usage of PKCS#11, as an
> > GPLed implementation of this one exists (gpkcs11) and it allows
> 
> I had a look at Gpkcs11 but noticed that it is based on OpenSSL which
> is not a GPLed implementation.  However it should be possible to use
> libgcrypt as a backend for gpkcs.  Frankly said, PKCS11 reminds me of 
> APIs as used with host software and I don't understand why the use
> fixed length data structures and thinks like strings padded with
> blanks (whatever a blank means, on a hoist it is 0x40).  The use of
> restrictions like "convention on packing is that structures should be
> 1-byte aligned" does not sound very portable for me.
> 
[ew]  Its not that bad. We have an pkcs#11 implementation which is quite
portable, but it is somewhat clumsy, nevertheless :(.

> Last not least, libgcrypt is not intended to be a "high"-level
> library but merely a low-level crypto library.  Okay, this might
> change in the future but I think it is better to put high/level
> abstractions on top of libgcrypt.
> 
[ew]  My intension was focused on integration of crypto hardware like
smartcards (what about that idea?), with the possibility for third parties
to develop their own crypto stuff to be used in gpgp or place it under GPL.

I'll take a look at your cryptolib, if i get some time and examine what
about integration of such stuff.

Eyck