[Freeipa-devel] DNSSEC design page

[Jan Cholasta]

On 18.2.2014 17:19, Martin Kosek wrote:
> On 02/18/2014 04:38 PM, Jan Cholasta wrote:
>> On 18.2.2014 16:35, Petr Spacek wrote:
>>> On 18.2.2014 16:31, Jan Cholasta wrote:
>>>>>>>
>>>>>>> 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.
>>>>>
>>>>> There won't be a separate public key, it's represented by the
>>>>> certificate.
>>>>
>>>> I'm not sure if this is the case for DNSSEC.
>>>
>>> Honzo,
>>>
>>> we really need the design page with some goal statement, high-level
>>> overview etc. There is still some confusion, probably from fact that we
>>> want to use the same module for cert distribution and at the same time
>>> for DNSSEC key storage.
>>>
>>
>> It's on my TODO list, I'll try to get it out ASAP.
>>
>
> +1, please do. We clearly need some design to start with.
>
> Martin
>

I already posted the link in other thread, but here it is anyway: 
<http://www.freeipa.org/page/V3/PKCS11_in_LDAP>.

Some more comments on the schema:

I think I may have been too quick to dismiss RFC 4523. There is 
CKA_CERTIFICATE_CATEGORY which can have values "unspecified", "token 
user", "authority" and "other entity". We could map entries with object 
class pkiUser to certificate object with CKA_CERTIFICATE_CATEGORY "token 
user" and entries with object class pkiCA to certificate object with 
CKA_CERTIFICATE_CATEGORY "authority". There are no object classes in RFC 
4523 for "unspecified" and "other entity", but we will not be storing 
any certificates using PKCS#11 anyway, so I think it's OK.

Also the above got me thinking, is there any "standard" LDAP schema for 
private keys? If so, can we use it?

I'm going to store NSS trust objects along with CA certificates, so I'm 
going to need an object class for that. You can find the details on 
CKO_NSS_TRUST at 
<http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-existing.html>.

If we store multiple related PKCS#11 objects in a single LDAP entry, 
there is going to be some redundancy. For example, public key value can 
be extracted from private key value, so we don't need to store both of 
the values. This can be bypassed by having separate object classes for 
data and for metadata. For a key pair entry, the object classes would be 
e.g. privateKey, pkcs11privateKey and pkcs11publicKey, where privateKey 
is an object class with private key data (without any PKCS#11 bits), 
pkcs11privateKey is an object class with PKCS#11 private key metadata 
and pkcs11publicKey is an object class with PKCS#11 public key metadata. 
In the PKCS#11 module, this entry would be visible as two separate 
objects (private key object and public key object).

Regarding PKCS#11 metadata attributes (i.e. excluding certificate, 
private key and public key value attributes), I think they all should be 
single-valued. Comments on specific attributes:

   * CKA_MODIFIABLE, CKA_SUBJECT, CKA_ISSUER, CKA_SERIAL_NUMBER, 
CKA_JAVA_MIDP_SECURITY_DOMAIN, CKA_DERIVE, CKA_LOCAL, 
CKA_KEY_GEN_MECHANISM, CKA_ALLOWED_MECHANISMS, CKA_VERIFY_RECOVER, 
CKA_SIGN_RECOVER, CKA_ALWAYS_SENSITIVE, CKA_NEVER_EXTRACTABLE, 
CKA_WRAP_WITH_TRUSTED, CKA_ALWAYS_AUTHENTICATE - there should be LDAP 
attributes for these, for the sake of completeness

   * CKA_TOKEN - this is CK_TRUE for persistent objects and objects in 
LDAP are always persistent, so there is no need for pkcs11token

   * CKA_CERTIFICATE_TYPE - this will always be CKC_X_509, no need for 
pkcs11certificateType

   * CKA_CERTIFICATE_CATEGORY - if this is mapped to RFC 4523 object 
classes (see above), we don't need an LDAP attribute for it

   * CKA_CHECK_VALUE, CKA_HASH_OF_SUBJECT_PUBLIC_KEY, 
CKA_HASH_OF_ISSUER_PUBLIC_KEY - can be generated on-the-fly from 
certificate value, no need for LDAP attributes

   * CKA_URL - do we want to support certificates with URL instead of value?

-- 
Jan Cholasta