On Thu, 14 Aug 2008, Garrett D'Amore wrote:
hi,
> If all things were equal (and I'm not saying they are), I'd think direct
> access
> to PKCS#11 would be preferable, since it would reduce layering induced
> overhead, and might offer additional configuration options.
another reason why we can't do it now is that the softtoken is
slower than OpenSSL code on quite a few platforms. The overhead of another
layer (CF) also takes its price. For example, my tests on AMD64 showed
regression around 15% in SSH data transfer in case of using the softtoken
only.
> One of the PKCS#11 configuration options that might be really cool to have,
> for
> example, would be support for PKCS#11 secure key management. (I.e. allow me
> to
> store my private keys securely in a FIPS-140-2 compliant crypto device such as
> SCA 6000.) It isn't clear to me that this is easy (or feasible) with an
> OpenSSL layered approach.
unfortunately, OpenSSL ENGINE API allows to work with RSA keys
only now.
> Also, what are the "compatibility" concerns of the new configuration file
> directive? What will happen to other open source implementations of SSH when
> they see the same directive (such as when sharing a home directory via NFS
> with
> Linux or FreeBSD systems)?
aside from what Darren said, we have IgnoreIfUnknown option in
Nevada, and it was also filed against OpenSSH. However, they haven't adopted
it so far. Anyway, users won't be expected to use this option unless
something goes wrong; normally they should be fine with the default value
"yes".
J.
--
Jan Pechanec
