Thank you for your clarifications, which were pretty much as I
expected. My only question relates to your answer to the question about
key management... are you saying you believe in the future you can add
use of an alternate key store using the OpenSSL library? (That seems
moderately surprising to me. And I recognize its "not this project".)
-- Garrett
Darren J Moffat wrote:
> Garrett D'Amore wrote:
>> Why are we using OpenSSL for this instead of PKCS#11? Is SunSSH
>> already using OpenSSL (without engine support)?
>
> Yes it already uses the libcrypto from OpenSSL.
>
>> 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.
>
> It would but we can do this project now or the bigger project much
> later.
>
>> 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.
>
> It is actually possible and Jan, myself and Ferenc have worked out how
> to do it.
>
>> It seems like this project is only offer the acceleration benefit for
>> hardware crypto, and not offering any key handling improvements, right?
>
> Correct that is what is is all about. The main focus is on the
> UltraSPARC T2 processor which is just an accelerator anyway - it has
> no hardware keystore.
>
>> 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)?
>
> We already have that problem. The workaround is to use the per system
> /etc/ssh/ssh_config.
>
>> Finally, might it not be a better choice to avoid hardcoding the
>> notion of OpenSSL into the configuration file syntax? Perhaps
>> something more generic, such as "UseHardwareOffload" or somesuch
>> might be better, especially if the software might one day be changed
>> to use a different crypto backend (such as PKCS#11.)
>
> This was on purpose because it is about using the OpenSSL engine. If
> we do a direct PKCS#11 interface in the future the configuration
> required will be more than just a boolean. Also if we switch to
> direct PKCS#11 then hardware vs software doesn't make much sense, what
> makes sense is which PKCS#11 slot/token is being used.
>
