On 18.2.2014 16:35, Petr Spacek wrote:
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.
It's on my TODO list, I'll try to get it out ASAP.
--
Jan Cholasta
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
