[Opendnssec-develop] SoftHSM back-end database

Roland van Rijswijk roland.vanrijswijk at surfnet.nl
Sat Dec 13 16:58:24 CET 2008


Hi Rickard,

Sorry for taking so long to respond, I've had a very busy week and a half...

Rickard Bondesson wrote:
> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
> 
> Hi
> 
> I have designed a back-end database for the SoftHSM which will
> remember the keys and its attributes from time to time. The current
> implementation of SoftHSM store the keys directly on the disc and
> auto generate the attributes. But we had a discussion about having a
> possibility to specify the attributes. So, attached is my design of
> the database with tables and columns. It presents all the possible
> attributes, but some of them are chosen not to be stored in the
> database.
> 
> Any comments or questions?

- What database are you going to use?

- I assume that attributes like CKA_MODULUS, etc. will be derived from 
the X509_public_key field? The same goes for the private key

- The CKA_ID value should not be stored as a string; it is defined as a 
byte array, so storing at as a string in a database could cause trouble 
(unless you store it Base64 encoded)

- How are you going to encrypt the PKCS #8?

- Are you really going to limit the possible values of a field such as 
CKA_CLASS?

- I've never seen CKA_WRAP_WITH_TRUSTED being used. So you could make 
that one gray...

- I would propose that you add a general "other attributes" blob, in 
which you can store - for instance in DER encoding - any attributes for 
which you have not created any fields; in this way you don't limit the 
types of attributes that can be stored without having to create fields 
for all possible attributes.

Hope this helps.

Cheers,

Roland.

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



More information about the Opendnssec-develop mailing list