[Opendnssec-develop] HSM vendors and common key attributes

[Roland van Rijswijk]

Hi Roy,

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 [1] 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_KEY_TYPE
> 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.

> CKA_SIGN_RECOVER 
> CKA_ALWAYS_AUTHENTICATE

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.

Cheers,

Roland.

-- 

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