[Freeipa-devel] DNSSEC design page
Rich Megginson
rmeggins at redhat.com
Thu Feb 27 21:15:45 UTC 2014
On 02/27/2014 01:10 PM, Petr Spacek wrote:
> 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.)
>
That's fine.
More information about the Freeipa-devel
mailing list