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.
+1, I would prefer that as well if possible - it seems to me as very unusual and hard-to-grasp way of making a DN. I am also thinking we might not have a support of multi-component RDNs in FreeIPA framework either, making it even more difficult to prepare a support for it. Martin _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel