[Freeipa-devel] DNSSEC design page

[Petr Spacek]

On 25.2.2014 13:47, Jan Cholasta wrote:
> here is a draft of the PKCS#11 design:
> <http://www.freeipa.org/page/V3/PKCS11_in_LDAP>.

I don't understand the purpose of cn=crypto suffix. I thought that PKCS#11 
module will have to search for token with given TOKEN_ID or LABEL anyway, 
right? Do I miss something?

Where the token will be placed if someobody generates new key via PKCS#11? How 
it will determine the right sub-tree?

I would rather see keys stored under user account:
uid=admin,cn=users,cn=accounts,dc=ipa,dc=example

I like this approach because it allows you to manipulate with the user account 
easily without paying special attention to dangling references etc.

Key storage under service account like:
krbprincipalname=DNS/vm.example.com at IPA.EXAMPLE,cn=services,cn=accounts,dc=ipa,dc=example
doesn't solve problem with shared keys in DNS tree... I can imagine that 
objects in LDAP have TOKEN_ID and LABEL attributes indexed and the PKCS#11 
module will do full sub-tree search for particular ID or LABEL value, so the 
key can be always found.

On the other side, it would require special handling for replica deletion etc.

Petr^2 Spacek

> 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