On 18.2.2014 16:23, Rob Crittenden wrote:
Jan Cholasta wrote:
Hi,
On 18.2.2014 14:02, Ludwig Krispenz wrote:
Hi,
yesterday jan asked me about the status of the schema and if it would be
ready for certificate storage an dthat puzzled me a bit and showed that
I still do not really understand what you want to store in LDAP.
Two me there are two very different approaches.
1] LDAP as store for high level objects like certs and keys
For certs and related stuff there is rfc4523 and the schema for ldif
exists. For keys we would decide if the key is stored in PKCS#8 format
or as bind keypairs and define a key attribute and that's it. we could
export keys with softhsm, (eventually convert them) and add to ldap, in
the long term solution the PKCS#11 replacemnt would need to manage these
high level objects
I think RFC 4523 is not the right schema in this case, as it is suited
for PKIs rather than generic cryptographic data storage. For example,
RFC 4523 distinguishes between CA and end entity certificates, but in
PKCS#11 there are just certificates without any semantics attached to
them.
I'm not advocating one vs another, but you can make some educated
guesses on a CA vs a cert based on whether there is a private key with it.
Note that you may want/need to store CKO_NETSCAPE_TRUST values as well.
Yes. (I thought it was CKO_NSS_TRUST though, but that's not important.)
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.
And as I mentioned, trust, though you can fake it too if you can find
some means of distinguishing a CA from another cert. For example, in the
soft-pkcs11 module I showed you they define it in a configuration file
with "anchor" and it gets marked as trusted.
Or you can generate this on-the-fly entirely.
I plan to store trust information in LDAP, see the CA certificate
renewal design.
rob
--
Jan Cholasta
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
