[Freeipa-devel] DNSSEC design page
Petr Spacek
pspacek at redhat.com
Thu Feb 27 20:10:03 UTC 2014
On 27.2.2014 17:55, Ludwig Krispenz wrote:
>
> 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.
> agreed, they are not very common. You can make any allowed attribute the
> naming attribute, so you have the choice eg "dn: pkcs11label=....., ". It
> should be some attr available in all the objects. You can also use the
> suggested attribute pkcs11uniqueid and do not use the ipaUniqueid strings, but
> soemthing readable.
> We can als define an other attr which does not sound like uniqueid eg
> pkcs11object[id|name|..]
Okay. I have talked again with Honza about that and the current schema
proposal combines public and private keys to one object so collision on LABEL
or ID-level should not happen.
Is it okay to mix objects with DNs like:
pkcs11label=...
pkcs11id=...
pkcs11uniqid=...
in one sub-tree? (Assuming that our client can handle that.)
--
Petr^2 Spacek
More information about the Freeipa-devel
mailing list