[Freeipa-devel] DNSSEC design page

[Ludwig Krispenz]

On 02/25/2014 01:47 PM, Jan Cholasta wrote:
> 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).
ok for me, if anybody agrees.
>
> 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.
ok.
>
>>
>> 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
>>>
>>
>
>