[Freeipa-devel] DNSSEC design page

[Jan Cholasta]

On 25.2.2014 14:52, Petr Spacek wrote:
> 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?

That's just a base DN for LDAP searches I came up with, it has no 
particular meaning.

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

In order to generate a key, you must have an open session (see 
C_GenerateKeyPair). When you open a session, you must specify slot ID 
(see C_OpenSession). This is where the association takes place.

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

Do you mean storing private keys in a single attribute in user's entry? 
We wouldn't be able to store per-key metadata that way.

If you mean storing private keys in entries under user's entry, there is 
nothing similar in our current schema, so I thought we just don't do 
that (there probably is a reason for that).

(Anyway, we don't need to solve this right away, DNSSEC and CA 
certificates are what matters now.)

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

References are managed automatically by the referint plugin.

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

The objects need to be associated with a particular token somehow. 
Having them in a token-specific sub-tree seems like the easiest way to 
do it to me.

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

-- 
Jan Cholasta