[Freeipa-devel] DNSSEC design page

[Jan Cholasta]

On 20.2.2014 13:39, Ludwig Krispenz wrote:
> 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.

I agree, that's the way I imagined it.

One thing to note is that in PKCS#11 an object is allowed to have only 
single object class, so when you want to get e.g. certificate and 
private key of a single entity, you must lookup a certificate object and 
a private key object which have the same CKA_ID. I think it would be 
nice if we could store them both in a single entry in LDAP, given that 
an entry is allowed to have multiple object classes.

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

The attributes that hold the actual key data depend on the key 
algorithm, CKA_MODULUS and CKA_PUBLIC_EXPONENT are relevant to RSA, but 
they might not be relevant to other algorithms.

But I don't think we need such a level of detail, I like your previous 
idea of storing private key material as PKCS#8 - it has all the key 
algorithm-specific bits inside, so we would be able to have just one 
object class for private keys (with common private keys attributes and 
one attribute to store the PKCS#8 blob in), instead of one object class 
per algorithm (with common private key attributes and algorithm-specific 
attributes).

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


-- 
Jan Cholasta