[Opendnssec-develop] HSM vendors and common key attributes

Roy Arends roy at nominet.org.uk
Tue Dec 2 13:46:55 CET 2008


Hi,

In a separate thread, Rick van Rein elaborated on the state of PKCS11 
compliance, especially the CKA_XXX attributes a key might have.

I think that a rule of thumb should be that OpenDNSSEC should be as strict 
as possible, but not more strict than that :-)

In order to gauge how strict, please list the type of HSM to your avail 
that you will be able to test OpenDNSSEC against.

Nominet has the following:

Sun SCA6000
SafeNet Luna SA 
nCipher netHSM

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)

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

And here the attibutes I think are nice to have:

CKA_DECRYPT = CK_FALSE
CKA_UNWRAP = CK_FALSE
CKA_SIGN_RECOVER 
CKA_ALWAYS_AUTHENTICATE

Let me know.

Roy Arends
Sr. Researcher
Nominet UK

[1] The CKA_ID can have any value and is said to be of an array of 
unsigned 8-bit characters. We have noticed that different vendors have 
different length of this array. We have seen silliness that when we 
specify a value of 1, it is often stored as the ascii value for "1", where 
other HSMs store it as value 1. Also we see restrictions that ID can only 
be numerical, while others allow it to be anything.





More information about the Opendnssec-develop mailing list