[Freeipa-devel] DNSSEC design page
Ludwig Krispenz
lkrispen at redhat.com
Thu Feb 27 16:55:19 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.
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|..]
>
>
>
More information about the Freeipa-devel
mailing list