SV: [Opendnssec-develop] SoftHSM

[Rickard Bondesson]

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

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.

// Rickard 

- -----Ursprungligt meddelande-----
Från: opendnssec-develop-bounces at lists.opendnssec.org [mailto:opendnssec-develop-bounces at lists.opendnssec.org] För Roland van Rijswijk
Skickat: den 2 december 2008 13:06
Till: Rick van Rein
Kopia: Opendnssec-develop at lists.opendnssec.org
Ämne: Re: [Opendnssec-develop] SoftHSM

Hello,

> The nuisance of this is that OpenDNSSEC, to be practical, would have 
> to be configurable for the CKA_xxx flags it relies on, just to make up 
> for any half-done middlewares.  I'd love to believe that HSM 
> manufacturers are doing better, but honestly I doubt it.

In my experience, HSM manufacturers generally do a better job of implementing PKCS #11 libraries than smart card manufacturers. Keep in mind that HSMs are an order of magnitude more expensive and complex than smart cards so they _need_ to support more CKA_xyz attributes.
Manufacturers of HSMs generally put more effort into their P #11 libraries. The only problem is that it is common practice for HSM manufacturers to 'extend' the PKCS #11 API with vendor specific functionality. In my opinion, if possible this kind of vendor specific functionality should not be relied on.

On another note: even the worst smart card manufacturers implement the common CKA_xyz attributes. Though I agree with Rick that there are many bad implementations, this should not deter you from correctly using PKCS
#11 attributes. Maybe it is a good idea to give an insight into which flags and attributes you want to use. I - and I believe Rick as well - should be able to tell you what the correct usage of these attributes is and whether or not they are commonly used...

Cheers,

Roland.

- -- 

- -- Roland M. van Rijswijk
- -- SURFnet Middleware Services
- -- t: +31-30-2305388
- -- e: roland.vanrijswijk at surfnet.nl
_______________________________________________
Opendnssec-develop mailing list
Opendnssec-develop at lists.opendnssec.org
https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop

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

wsBVAwUBSTUr1eCjgaNTdVjaAQiMyAf+JhafS+srRLkF76Xxq9uos0QK2ogKdp8y
ZBS6d4oj2r62/PXHmpOs9roSqWeNUvjFAME+Os2Qrjo2giKzRK6QN+Mmv1b2iRf8
A1e0NvkzW7tLIbDM+l1WcWAKYjOFxjivX3hkl74esGcQ/0rIOP+CdBqXjcOTo1ah
KlZBwo5+L6unzUQivE7IsnLdsWwTODXl/WdUlkCCA9f8YUOD40iCZR+oE8TIelC/
+Tjgqdnyo5WDrEWWdTJ0EF4F9q5zOWJGBdYmlObUgo8iz2pr6lu5SlQrmUd0hbyq
7qe84/+Ycw2NQoYPec/tnz5oRjnG0n9Ex6CZ9pxUnDJ6FncScBPalw==
=4UUd
-----END PGP SIGNATURE-----