[Freeipa-devel] DNSSEC design page
Martin Kosek
mkosek at redhat.com
Fri Feb 28 07:28:30 UTC 2014
On 02/27/2014 05:46 PM, Rich Megginson wrote:
> On 02/27/2014 09:37 AM, Petr Spacek wrote:
>> On 27.2.2014 17:24, Ludwig Krispenz wrote:
>>>
>>> On 02/27/2014 03:56 PM, Jan Cholasta wrote:
>>>> On 27.2.2014 15:23, Ludwig Krispenz wrote:
>>>>>
>>>>> On 02/27/2014 02:14 PM, Jan Cholasta wrote:
>>>>>> 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.
>>>>> not sure I understand what exactly you want here. If we don't store
>>>>> certificates using the pkcs#11 schema we don't need to define them, but
>>>>> on the other hand you talk about the usage of CKA_CERTIFICATE_CATEGORY.
>>>>> Do you mean to have a pkcs11 cerificate object with
>>>>> CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes
>>>>> userCertificate and cACertificate to store them ?
>>>>
>>>> Hopefully an example will better illustrate what I mean. We could map
>>>> PKCS#11 objects like this:
>>>>
>>>> CKA_CLASS: CKO_CERTIFICATE
>>>> CKA_CERTIFICATE_TYPE: CKC_X_509
>>>> CKA_CERTIFICATE_CATEGORY: 1
>>>> CKA_VALUE: <cert>
>>>> <other attrs>
>>>>
>>>> to LDAP entries like this:
>>>>
>>>> dn: pkcs11uniqueId=<id>,<suffix>
>>>> objectClass: pkcs11storageObject
>>>> objectClass: pkiUser
>>>> pkcs11uniqueId: <id>
>>>> userCertificate;binary: <cert>
>>>> <other attrs>
>>>>
>>>> and PKCS#11 object like this:
>>>>
>>>> CKA_CLASS: CKO_CERTIFICATE
>>>> CKA_CERTIFICATE_TYPE: CKC_X_509
>>>> CKA_CERTIFICATE_CATEGORY: 2
>>>> CKA_VALUE: <cert>
>>>> <other attrs>
>>>>
>>>> to LDAP entries like this:
>>>>
>>>> dn: pkcs11uniqueId=<id>,<suffix>
>>>> objectClass: pkcs11storageObject
>>>> objectClass: pkiCA
>>>> pkcs11uniqueId: <id>
>>>> caCertificate;binary: <cert>
>>>> <other attrs>
>>>>
>>>> In other words, the value of CKA_CERTIFICATE_CATEGORY is implied from
>>>> objectClass, "CKA_CERTIFICATE_CATEGORY: 1" <=> "objectClass: pkiUser" and
>>>> "CKA_CERTIFICATE_CATEGORY: 2" <=> "objectClass: pkiCA".
>>> so you want to directly use the pkiUser|CA objectclass, that would be ok
>>>>
>>>>>>
>>>>>> Also the above got me thinking, is there any "standard" LDAP schema
>>>>>> for private keys? If so, can we use it?
>>>>> I didn't find any, the only keys in ldap I found is a definition for
>>>>> sshPublicKey for openssh.
>>>>
>>>> And even this schema is for public keys only :-) OK, nevermind then.
>>>>
>>>>>>
>>>>>> 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>.
>>>>>>
>>>>>>
>>> so this is a nss extension to pkcs11, not in the standard ? If we add trust
>>> objects, should the naming reflect this like pkcs11nss<attr> or
>>> pkcs11ext<attr> ?
>>>>>>
>>>>>>
>>>>>> 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).
>>>>> I have not yet rewritten the objectcalss definition after the latest
>>>>> discussion, but I think if we have one structural objectclass
>>>>> pkcs11storageObject with only a uniqueid and auxiliary objectclasses for
>>>>> publickey,privatekey, certificate where the attributes (maybe
>>>>> withexception of label, id) are optional there will be no redundancy,
>>>>> store only what is needed.
>>>>> you could use these aux objectclass also in other entries instead of
>>>>> using pkcs11storageObject.
>>>>
>>>> OK, great. BTW, CKA_LABEL and CKA_ID are both optional in PKCS#11, so I
>>>> think they should be optional in LDAP as well.
>>>>
>>>>>>
>>>>>> 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
>>>>> in progress
>>>>>>
>>>>>> * CKA_TOKEN - this is CK_TRUE for persistent objects and objects in
>>>>>> LDAP are always persistent, so there is no need for pkcs11token
>>>>> ok
>>>>>>
>>>>>> * CKA_CERTIFICATE_TYPE - this will always be CKC_X_509, no need for
>>>>>> pkcs11certificateType
>>>>> ok
>>>>>>
>>>>>> * CKA_CERTIFICATE_CATEGORY - if this is mapped to RFC 4523 object
>>>>>> classes (see above), we don't need an LDAP attribute for it
>>>>> see above, where do you want to define the mapping. Do we then need
>>>>> cert attrs at all ?
>>>>
>>>> If we use userCertificate and cACertificate, we don't need
>>>> pkcs11certificateValue, if that's what you are asking.
>>> I was asking if we need the pkcs11certificate objectclass and the certificate
>>> metadata since you were using the pkiUser and pkiCA objectclasses to store the
>>> cert, but you probably want the startdate, enddate and other attrs at least
>>> available
>>>>
>>>>>>
>>>>>> * 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
>>>>> ok
>>>>>>
>>>>>> * CKA_URL - do we want to support certificates with URL instead of
>>>>>> value?
>>>>> don't know, there are just some other attrs required when a URL is used
>>>>
>>>> If you mean CKA_HASH_OF_{SUBJECT,ISSUER}_PUBLIC_KEY, they are not required
>>>> AFAIK, it's just that URL-only certificates do not make much sense without
>>>> them.
>>>>
>>> yes, It says:CKA_HASH_OF_{SUBJECT,ISSUER}_PUBLIC_KEY Can only be empty if
>>> CKA_URL <http://www.cryptsoft.com/pkcs11doc/v220/pkcs11__all_8h.html#aCKA_URL>
>>> is empty.
>>
>> I have a note about naming attribute:
>> - I don't like nsUniqId here because you can't read it in LDAP browser by
>> naked eye
>> - I propose to use
>> -- dn: CKA_CLASS=...+CKA_LABEL=...
>> -- dn: CKA_CLASS=...+CKA_ID=...
>> One of them should be present almost always and the writing 'entity'
>> (effectively PKCS#11 module generating a new key or storing a new
>> certificate) can fall back to uniqueId if there is neither LABEL nor ID.
>>
>> Honza told me that PKCS#11 module/user have to always do a LDAP search so
>> this change should be 'cosmetic'.
>>
>> We are not LDAP experts. Ludwig, what do you think about compound names? Are
>> they okay for general use?
>
> They are problematic. I would prefer to avoid having multi-component RDNs.
+1, I would prefer that as well if possible - it seems to me as very unusual
and hard-to-grasp way of making a DN. I am also thinking we might not have a
support of multi-component RDNs in FreeIPA framework either, making it even
more difficult to prepare a support for it.
Martin
More information about the Freeipa-devel
mailing list