On 18.2.2014 16:31, Jan Cholasta wrote:
2] low level replacement for eg the sqlite3 database in softhsm.
That's what I sometimes get the impression what is wanted. SoftHsm has
one component Softdatabase with an API, which more or less passes sets
of attributes (attributes defined by PKCS#11) and then stores it as
records in sql where each record has a keytype and opaque blob of data.
If that is what is wanted the decision would be how fingrained the pkcs
objects/attribute types would have to be mapped to ldap: one ldap
attribute for each possible attribute type ?
One-to-one mapping of attributes from PKCS#11 to LDAP would be the most
straightforward way of doing this, but I think we can do some
optimization for our needs. For example, like you said above, we can use
a single attribute containing PKCS#8 encoded private key rather than
using one attribute per private key component.
I don't think we need an LDAP attribute for every possible PKCS#11
attribute, ATM it would be sufficient to have just these attributes
necessary to represent private key, public key and certificate objects.
So, I would say it should be something between high-level and low-level.
There won't be a separate public key, it's represented by the certificate.
I'm not sure if this is the case for DNSSEC.
Honzo,
we really need the design page with some goal statement, high-level overview
etc. There is still some confusion, probably from fact that we want to use the
same module for cert distribution and at the same time for DNSSEC key storage.
--
Petr^2 Spacek
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
