[Freeipa-devel] DNSSEC design page

[Jan Cholasta]

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