[Opendnssec-develop] HSM vendors and common key attributes

[Roy Arends]

Roland van Rijswijk <roland.vanrijswijk at surfnet.nl> wrote on 12/02/2008 
01:58:15 PM:

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

> I think CKA_TOKEN should also be in the 'mandatory' list.

Yes.

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

Thanks for that Roland,

Are you able to list, and maybe eventually participate to test, the HSMs 
that you currently have at your disposal? 

Thanks,

Roy Arends
Sr. Researcher
Nominet UK