[Freeipa-devel] DNSSEC design page

[Jan Cholasta]

Hi,

here is a draft of the PKCS#11 design: 
<http://www.freeipa.org/page/V3/PKCS11_in_LDAP>.

On 24.2.2014 13:11, Ludwig Krispenz wrote:
> Hi,
>
> here is a draft to start discussion. Lt me know if it is the right
> direction and what you're missing.
> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema

IMO we don't need attribute types for key components 
(ipaPkcs11publicExponent, ipaPkcs11modulus, ipaPkcs11privateExponent, 
ipaPkcs11prime1, ipaPkcs11prime2) at all. As I said before, I don't 
think we need such granularity in LDAP and it would limit us to RSA only 
(unless we add attribute types for every other key type). We can store 
both private keys and public keys in single attribute as a DER blob (I 
would name the attributes ipaPkcs11privateKeyValue instead of 
ipaPkcs8privateKey for private keys, ipaPkcs11publicKeyValue for public 
keys, there already is ipaPkcs11certificateValue for certificates).

OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, CKA_SIGN, 
CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, CKA_EXTRACTABLE 
when generating new key pairs, and the PKCS#11 spec says that keys 
generated on a token should have CKA_LOCAL and CKA_KEY_GEN_MECHANISM 
set, so I think we should have attribute types for all of them.

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