[Freeipa-devel] DNSSEC design page

[Petr Spacek]

On 20.2.2014 14:20, Jan Cholasta wrote:
> 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'm attaching a file with key metadata used by BIND 9. Most important field is 
"label", it assigns key with the DNS zone. (Name of DNS zone is derived from 
file name.)

It seems that we don't need any special identifier in the key itself, standard 
label is just fine.

Petr^2 Spacek

>> 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
-------------- next part --------------
Private-key-format: v1.3
Algorithm: 5 (RSASHA1)
Modulus: xjgfDGfpgvdPuwwQDMB8dvXH/qmqPWiR6dIn+VTRuJAkdjX5OUUmVP0BE9iaXK3pxwGG3E8g152oakUovcpC3trvZZbEc1JHfeF0lPdH5HrKVF8LgwLLRN+eF4m6n1zs0P/rG19DeVRhZU0xr5BNrOaEmz6N5VXiJ7kPgCMaww4VB5QZ2xVpVQRIsY7Isp0q39gbrjvsa/JrfEQm9SP4ID/MFxbczflf9itfgSAZiOPwK5gxvnzbfZvezR3zXh7/NxP6z7+RLIgfcgkidjxgZzkSbbHX1/oSdhANDODgNsd40F6VGz3/Bbsa9mBmmUSLCJO7jw2vJFSNBBah0mQ4UQ==
PublicExponent: AQAB
Engine: cGtjczExAA==
Label: bGFiZWxfT3BlbkROU1NFQwA=
Created: 20140201122624
Publish: 20140201122624
Activate: 20140201122624