[Freeipa-devel] DNSSEC design page

[Ludwig Krispenz]

Hi,

I am now getting more familiar with PKCS#11 and did check which objects 
are handled by softhsm and I think the best way would be a direct 
mapping of a subset of the pkcs#11 objectclasses and attributes to LDAP.
In my understanding we would only need the objectclasses of storage 
objects: certificate, {private|public|secret}key, evtl data. The 
attributes would then be the attributes required by these 
objectclassses. And here I am having a bit difficulties, eg in the spec: 
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf in 
the example (11.7) for adding a publicKey the attributes CKA_MODULUS and 
CKA_PUBLIC_EXPONENT are used, but these are not listed in the tables in 
10.7 as "Common Key Attributes", so how do I know which are the required 
and allowed attributes for these objectclasses ?
I will start to write a draft for the schema definitions we can discuss, 
but any input is welcome.

Regards,
Ludwig

On 02/18/2014 03:17 PM, 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.
>
>>
>> 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.
>
> Honza
>