[Freeipa-devel] DNSSEC design page
Jan Cholasta
jcholast at redhat.com
Thu Feb 27 16:53:58 UTC 2014
On 27.2.2014 17:49, Ludwig Krispenz wrote:
>
> On 02/27/2014 05:48 PM, Jan Cholasta 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
>>
>> I think it would make sense after all, if that's OK by the present
>> LDAP gurus :-)
>>
>>>>
>>>>>>
>>>>>> 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> ?
>>
>> Yes, it's a NSS vendor-specific extension. I like the prefix "pkcs11nss".
>>
>>>>>>
>>>>>>
>>>>>> 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
>>
>> Yes, I don't want to lose any of the metadata, anything but CKA_VALUE
>> should still be available in pkcs11certificate.
>>
>>>>
>>>>>>
>>>>>> * 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.
>>>
>>
>> Well, the PKCS#11 spec says:
>>
>> "The CKA_HASH_OF_SUBJECT_PUBLIC_KEY and CKA_HASH_OF_ISSUER_PUBLIC_KEY
>> attributes are used to store the hashes of the public keys of the
>> subject and the issuer. They are particularly important when only the
>> URL is available to be able to correlate a certificate with a private
>> key and when searching for the certificate of the issuer."
>>
>> I can see the word "important", but not the word "required".
>>
> I was referring to note-4 in this doc:
> http://www.cryptsoft.com/pkcs11doc/v220/group__SEC__10__6__3__X__509__PUBLIC__KEY__CERTIFICATE__OBJECTS.html
Ah, right, the footnote is in the spec too. Sorry for the fuss then,
apparently I need to improve my reading skills.
--
Jan Cholasta
More information about the Freeipa-devel
mailing list