roy at nominet.org.uk
Mon Dec 1 13:30:15 CET 2008
"Rickard Bondesson" <Rickard.Bondesson at iis.se> wrote on 12/01/2008
> What is your view about the SoftHSM? Should it become a solution for
> OpenDNSSEC or a general purpose HSM?
I don't think these goals are mutual exclusive. The required functionality
for OpenDNSSEC is a small subset of a fully featured "virtual" HSM. We
need SoftHSM to at least work with OpenDNSSEC. Though I do see some value
for SoftHSM for other purposes outside of OpenDNSSEC (for which it then
needs richer functionality), but I'd give that less (or no) priority.
> For example:
> - - In OpenDNSSEC there is no need of having the possibility to add
> external public keys to the HSM, since we do not need to verify
> external signatures or encrypt data to a third party.
That is correct.
> - - In OpenDNSSEC we do not need to encrypt/decrypt anything.
> - - Since we only sign information, we do not need to keep track of
> whether a key pair is for signing or encryption.
To be clear, OpenDNSSEC is also capable of using a real HSM, one that
might store keys for encryption purposes as well. So if a pkcs11 template
is generated for a request, I'd like to contain CKA_SIGN=TRUE (at least)
and maybe even CKA_DECRYPT=FALSE. In short, the softtoken does need to
understand (or ignore, but not fail) those attributes.
> - - A general solution would need a more complex internal key
> handling solution.
> - - A general purpose solution would become a bit slower since we
> have to handle more internal state cases.
Hope this helps.
More information about the Opendnssec-develop