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