[Opendnssec-develop] SoftHSM back-end database
Roland van Rijswijk
roland.vanrijswijk at surfnet.nl
Sat Dec 13 15:58:24 UTC 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