[Freeipa-devel] DNSSEC design page
Jan Cholasta
jcholast at redhat.com
Thu Feb 27 14:56:01 UTC 2014
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".
>>
>> 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>.
>>
>>
>> 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.
>>
>> * 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.
--
Jan Cholasta
More information about the Freeipa-devel
mailing list