Jerry Lundström writes: > > I'm separating the SoftHSMv2 into a new thread.
=> the SoftHSMv2 backend is abstract and simple, in particular only a few datatypes are used. It needs a documentation update to cover recent changes but IMHO it is easy to plug another storage backend to SoftHSMv2 (easier than to plug another crypto backend). > > Imagine that the data store is in fact a remote database. You want to > be able to use the keys stored in the token even if the connection to > the backend database is down. => if your database API supports it why not? > That should be handled by the backend code then, if it needs to cache > locally etc. => even if you cache locally you need to know if the state change (for example to handle new keys). So it can't be solved on the SoftHSMv2 side (but can be on the storage side). > > Anyway, we are going to investigate if SoftHSMv2 can work on top of > our existing database code or not. I'm not saying 'no', I'm just saying > that it is not that easy as it may seem. => the so called database SoftHSMv2 backend uses a dedicated API, but from my experience with similar projects, it should not be hard to code a backend for another database API. > I understand that, your basically trying to make a network distributed > HSM and we have seen big companies take their time to make it really > work. => if it can be reduced to a distributed existing database I can't see why it couldn't be done. BTW there are some physical HSMs using remote (i.e., not on the physical device) distributed (i.e., not in a single place) storage of its PKCS#11 objects. Regards Francis Dupont <[email protected]> _______________________________________________ Opendnssec-user mailing list [email protected] https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
