[Freeipa-devel] DNSSEC design page

[Rob Crittenden]

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.

>>
>> 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.

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.

rob