SV: [Opendnssec-develop] SoftHSM

[Rickard Bondesson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Then the question comes back to:

Should this be a general software implementation of a HSM or should it aim at the OpenDNSSEC project?

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.

"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.

- -----Ursprungligt meddelande-----
Från: Roland van Rijswijk [mailto:roland.vanrijswijk at surfnet.nl] 
Skickat: den 2 december 2008 13:46
Till: Rickard Bondesson
Kopia: Rick van Rein; Opendnssec-develop at lists.opendnssec.org
Ämne: Re: SV: [Opendnssec-develop] SoftHSM

Hi Rickard,

Rickard Bondesson wrote:
> Does the quotation below imply that you HAVE to assign the other 
> values, given by the user, to the generated key?
> 
> "Other attributes supported by the RSA public and private key types 
> (specifically, the flags indicating which functions the keys support) 
> may also be specified in the templates for the keys, or else are 
> assigned default initial values."
> 
> With for example CKM_RSA_PKCS_KEY_PAIR_GEN: Is it ok to just take the 
> CKA_MODULUS_BITS and CKA_PUBLIC_EXPONENT (default 65537) from the 
> template and ignore the the other values? Then for example assign 
> CKA_SIGN = TRUE in our case, since that is what the purpose is with 
> the generated keys in the SoftHSM.

The correct way to implement it is as follows:

- - It is not mandatory to specify any key attributes. If none are specified, none are supposed to be set on the object; this means that no default values should be assigned

- - The values specified by the user should not be overridden; you should copy the values that the user specifies

- - The attributes must be enforced by the PKCS #11 module when calls to functions like C_SignInit are made

- - It is up to the implementor of the module whether or not changes are allowed to these attributes once the object has been created

Summarising: you should not assign a value yourself and you should not ignore what is in the template. This would go against the PKCS #11 specification.

I hope this answers your question.

Cheers,

Roland.

- -- 

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

-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSTU2g+CjgaNTdVjaAQiTQgf/e3hHFMpjSUql7xXr3pSJWpjSlRFovI/1
CEUndyIyXMlb9VrIFV4pTPRrhOXgCi9l7105lkK21Wi8zUqlsqhEQNq2sL8Fqspy
RpI8kN9pIySkA9tNj+UvzTOW+vmJwjnY7/yMGXvLUlQbbmcWim2fV72W3ejLG/dN
tZNgr43bqNaxawjuVD2iozFLbJVxZahL/jzARb5CdOlfYSM1M18PZinSyMnx3Rj+
nR9HBgED2tiGaLbfV51+eSiEuWp9sU4Dtq+IGAq6oJRKtEWUo2iiitFDw7+HPU0d
Iix7SFPdSc687T6wxhtw/stiSHNf7XKuUIWiLe9g8Ih6iKUjpbLCDA==
=WIRv
-----END PGP SIGNATURE-----