[Opendnssec-develop] HSM vendors and common key attributes
Roland van Rijswijk
roland.vanrijswijk at surfnet.nl
Tue Dec 2 12:58:15 UTC 2008
I've taken the liberty of quickly answering the question for some of the
attributes in your list below:
Roy Arends wrote:
> Consequently, we can create a simple matrix that contains CKA_XXX
> compliance and vendor.
> What follows is a list of attributes I require:
> CKA_ID (but see note  below)
Is supported by all PKCS #11 modules I know of (including nCipher
netHSM, Safenet Luna). This is such a basic attribute that a module
cannot be called PKCS #11 compliant if it doesn't support this attribute.
I think CKA_TOKEN should also be in the 'mandatory' list.
> And here the attributes I'd recommend to have:
> CKA_LOCAL = CK_TRUE
> CKA_SIGN = CK_TRUE
> CKA_EXTRACTABLE = CK_FALSE
> CKA_NEVER_EXTRACTABLE = CK_TRUE
> CKA_SENSITIVE = CK_TRUE
> CKA_ALWAYS_SENSITIVE = CK_TRUE
Again, these are such basic attributes that any module should support
them. The HSMs I've worked with all support these attributes.
> And here the attibutes I think are nice to have:
> CKA_DECRYPT = CK_FALSE
> CKA_UNWRAP = CK_FALSE
These first two are - again - basic attributes that any module should
support. The HSMs I've worked with all support these attributes.
These two are a bit trickier, especially the last one. I'm pretty
certain that most smart card PKCS #11 modules have problems with
CKA_ALWAYS_AUTHENTICATE and I also know that many applications that
support PKCS #11 such as Firefox, etc. have problems with this
attribute. I would not rely on either of these attributes being supported.
-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl
More information about the Opendnssec-develop