[Freeipa-devel] DNSSEC design page
Petr Spacek
pspacek at redhat.com
Thu Feb 27 16:37:05 UTC 2014
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?
--
Petr^2 Spacek
More information about the Freeipa-devel
mailing list