SV: [Opendnssec-develop] SoftHSM

[Roland van Rijswijk]

Hi Rickard,

Rickard Bondesson wrote:
> Then the question comes back to:
> 
> Should this be a general software implementation of a HSM or should
> it aim at the OpenDNSSEC project?

That depends on how much time there is to spend on writing the PKCS #11
module. I think it would be very helpful to have a good PKCS #11 soft
token in the public domain, but I would be the first to admit that I'm
biased. I tend to concur with you that it may be out of the scope of
OpenDNSSEC to provide this good PKCS #11 implementation... Maybe one day
if I find some time somewhere I'll lock myself up for a couple of days
and... :-)

> If we want the user to be able to specify different attributes, then
> we have to use a more complex background which can maintain these
> attributes from time to time. As of now, I just give default values
> back to user. These values are similar to those given by Roy in
> another email thread (and can be adapted to what ever we conform to).
> But what difference does it make to our project (with the SoftHSM in
> mind) if we can assign attributes? The main objective for the HSM in
> our project is to generate keys and sign data. Then I see no point of
> having the possibility to disallow certain activities other than
> specified by the defaults.

Point taken. If you want the soft token module to be as small in
footprint as possible and as simple as possible, you could chose to do
it that way. But you should at least try to make the design generic
enough that it allows for changing this to a better PKCS #11
implementation in the future, and most of all: document the choices you
make so others don't make wrong assumptions about the functionality in
the module and so they don't assume that this is normal behaviour for a
PKCS #11 module.

> "If none are specified, none are supposed to be set on the object;
> this means that no default values should be assigned"
> 
> If for example CKA_SIGN is not set by the user, how should we as a
> library act when a call comes to C_SignInit if no default values can
> be assigned by our self? If we continue to sign with the given key,
> then we could as easily just assign CKA_SIGN = CK_TRUE as a default
> in this case.

Strictly speaking, the call to C_SignInit should return
CKR_KEY_FUNCTION_NOT_PERMITTED in this case.

Cheers,

Roland.
-- 

-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl