Re: [Freeipa-devel] LDAP schema for PKCS#11
On 12.03.2014 16:31, Jan Cholasta wrote: On 12.3.2014 16:14, Stef Walter wrote: On 05.03.2014 18:02, Jan Cholasta wrote: On 5.3.2014 13:20, Stef Walter wrote: On 03.03.2014 15:24, Jan Cholasta wrote: On 3.3.2014 15:07, Stef Walter wrote: On 03.03.2014 15:03, Jan Cholasta wrote: If you plug a PKCS#11 module into p11-kit, will p11-kit use NSS trust objects from the module? No. This is the spec for storing trust policy in PKCS#11 that we've been working on: http://p11-glue.freedesktop.org/doc/storing-trust-policy/ It's a far more extensible and future proof model. The p11-kit-trust module stores/loads these sorts of objects, and additionally also generates NSS trust objects on the fly so that NSS can consume the information. It doesn't do that last bit for third party sources, but it could given code :) Code is not a problem :) What would be the best way to provide trust policy to p11-kit from a third party PKCS#11 module, if not NSS trust objects? I obviously think that using the new stuff linked above would be best. It's future proof and models this comprehensively. That would allow extracting compat trust anchors to files (for crypto libraries that don't yet support looking it up trust via PKCS#11). But I understand if you're hesitant to commit to this spec that's in development (albeit already implemented). Actually, I like it. Is everything mentioned at http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-pkcs11.html going to be standardized? Yes, that's the goal. Several people have been involved in reviewing the spec, and I'm going through a second batch of reviews from the NSS guys. Great! Do you expect any big changes to happen during the review, or can the spec be considered stable enough to base an LDAP schema on it? I'd like to think so. Yes. Stef ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAP schema for PKCS#11
On 05.03.2014 18:02, Jan Cholasta wrote: On 5.3.2014 13:20, Stef Walter wrote: On 03.03.2014 15:24, Jan Cholasta wrote: On 3.3.2014 15:07, Stef Walter wrote: On 03.03.2014 15:03, Jan Cholasta wrote: If you plug a PKCS#11 module into p11-kit, will p11-kit use NSS trust objects from the module? No. This is the spec for storing trust policy in PKCS#11 that we've been working on: http://p11-glue.freedesktop.org/doc/storing-trust-policy/ It's a far more extensible and future proof model. The p11-kit-trust module stores/loads these sorts of objects, and additionally also generates NSS trust objects on the fly so that NSS can consume the information. It doesn't do that last bit for third party sources, but it could given code :) Code is not a problem :) What would be the best way to provide trust policy to p11-kit from a third party PKCS#11 module, if not NSS trust objects? I obviously think that using the new stuff linked above would be best. It's future proof and models this comprehensively. That would allow extracting compat trust anchors to files (for crypto libraries that don't yet support looking it up trust via PKCS#11). But I understand if you're hesitant to commit to this spec that's in development (albeit already implemented). Actually, I like it. Is everything mentioned at http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-pkcs11.html going to be standardized? Yes, that's the goal. Several people have been involved in reviewing the spec, and I'm going through a second batch of reviews from the NSS guys. Stef ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAP schema for PKCS#11
On 12.3.2014 16:14, Stef Walter wrote: On 05.03.2014 18:02, Jan Cholasta wrote: On 5.3.2014 13:20, Stef Walter wrote: On 03.03.2014 15:24, Jan Cholasta wrote: On 3.3.2014 15:07, Stef Walter wrote: On 03.03.2014 15:03, Jan Cholasta wrote: If you plug a PKCS#11 module into p11-kit, will p11-kit use NSS trust objects from the module? No. This is the spec for storing trust policy in PKCS#11 that we've been working on: http://p11-glue.freedesktop.org/doc/storing-trust-policy/ It's a far more extensible and future proof model. The p11-kit-trust module stores/loads these sorts of objects, and additionally also generates NSS trust objects on the fly so that NSS can consume the information. It doesn't do that last bit for third party sources, but it could given code :) Code is not a problem :) What would be the best way to provide trust policy to p11-kit from a third party PKCS#11 module, if not NSS trust objects? I obviously think that using the new stuff linked above would be best. It's future proof and models this comprehensively. That would allow extracting compat trust anchors to files (for crypto libraries that don't yet support looking it up trust via PKCS#11). But I understand if you're hesitant to commit to this spec that's in development (albeit already implemented). Actually, I like it. Is everything mentioned at http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-pkcs11.html going to be standardized? Yes, that's the goal. Several people have been involved in reviewing the spec, and I'm going through a second batch of reviews from the NSS guys. Great! Do you expect any big changes to happen during the review, or can the spec be considered stable enough to base an LDAP schema on it? Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAP schema for PKCS#11
On 03.03.2014 15:24, Jan Cholasta wrote: On 3.3.2014 15:07, Stef Walter wrote: On 03.03.2014 15:03, Jan Cholasta wrote: If you plug a PKCS#11 module into p11-kit, will p11-kit use NSS trust objects from the module? No. This is the spec for storing trust policy in PKCS#11 that we've been working on: http://p11-glue.freedesktop.org/doc/storing-trust-policy/ It's a far more extensible and future proof model. The p11-kit-trust module stores/loads these sorts of objects, and additionally also generates NSS trust objects on the fly so that NSS can consume the information. It doesn't do that last bit for third party sources, but it could given code :) Code is not a problem :) What would be the best way to provide trust policy to p11-kit from a third party PKCS#11 module, if not NSS trust objects? I obviously think that using the new stuff linked above would be best. It's future proof and models this comprehensively. That would allow extracting compat trust anchors to files (for crypto libraries that don't yet support looking it up trust via PKCS#11). But I understand if you're hesitant to commit to this spec that's in development (albeit already implemented). There's a third simple way to store trust, which is using standard PKCS#11. It's very limited: * Store certificates with the CKA_TRUSTED attribute set to CKA_TRUE and CKA_CERTIFICATE_CATEGORY set to 2. This method covers storing certificate authority anchors only. The above spec is a superset of this simple way of storing trust. NSS trust objects are not. So I would suggest implementing this simple mechanism and then implement the full spec later. If you want to have a call/hangout about this and discuss, I'd be happy to. Cheers, Stef ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAP schema for PKCS#11
In your descriptions, can you translate all acronyms according to: http://www.cryptsoft.com/pkcs11doc/v220/group__SEC__5__SYMBOLS__AND__ABBREVIATIONS.html ...and... http://www.cryptsoft.com/pkcs11doc/v220/group__SEC__10__2__COMMON__ATTRIBUTES.html E.g., instead of saying pkcs11certificateCategory is represent CKA_CERTIFICATE_CATEGORY, can you say, Categorization of the certificate: 0 = unspecified (default value), 1 = token user, 2 = authority, 3 = other entity or whatever the translation of that enumeration might be in LDAP. You have good descriptions throughout your spec, but don't put those descriptions into your rfc2252 LDAP attribute definitions where they belong. Also, how are you deciding on capitalization in all cases? E.g, pkcs11uniqueid vs. pkcs11uniqueId vs. pkcs11uniqueID. See #3.5, supposed to be pkcs11nsstrust (pkcs11nssTrust?), but it starts with ( ipapkcs11OID.2.5 NAME 'pkcs11certificate' . I guess the crux of my recommendation is: make your schema entirely independent of the PKCS#11 standard. In other words, incorporate more of the standard's language into your actual schema definition file, so that users don't have to constantly compare and contrast against separate documents. Removing or at least demoting PKCS#11 C library #define artifacts. Thanks, Derek On Mon, Mar 3, 2014 at 5:51 AM, Ludwig Krispenz lkris...@redhat.com wrote: Hi, starting a new thread, after a lot of discussion and feedback, which I tried to integrate into thecurrent draft at: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema Here are some design decisions I made and which need to be finally decided. 1] Add nss trust objects. These are not defined in the PKCS#11 standard, but Jan said they will be needed and I added them to the spec 2] Certificate representation In pkcs11 there is a certificate category (user, authority, ..) and certificate value. An alternate way to represent this would be to use the schema defined in rfc4523 and map (user, value) -- (objectclass: pkiUser, usercertificate) and (authority, value) -- (objectclass: pkiCA, cAcertificate) I kept the attributes pkcs11certificateCategory and pkcs11certificateValue and let the applications decide which format will be used. 3] Key attributes Like certificates keys can be stored ina single attribute as pkcs8 or bind.key format. In pkcs11 the keys are defined by their algoritthm specific attributes, I had defined RSA specific attributes (moduleus, exponent, ) and did not remove them. Maybe some app wants to create keys and store these attrs, having defined them does not force to use them, but allows flexibility without requiring new attribute definitions 4] Not needed attributes. Jan pointed out that some of the attributes like CKA_TOKEN will always be true, so no need to define them. I have not yet removed them, they don't nned to be used, but I can still remove them. 5] Attribute syntaxes I associated boolean attributes with the ldap boolean syntax, which requires TRUE/FALSE as values There are a couple of attributes with a limited range like key_type which has values like: CKK_RSA, CKK_DSA, CKK_DH. There are defines for these values which translate them to integers, which could be used, but I propose to use a syntax of directoryString and use the values directly eg pkcs11keyType: CKK_RSA. To me this is more readable than pkcs11keyType: 0 And it would have to be parsed anywy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAP schema for PKCS#11
On 5.3.2014 13:20, Stef Walter wrote: On 03.03.2014 15:24, Jan Cholasta wrote: On 3.3.2014 15:07, Stef Walter wrote: On 03.03.2014 15:03, Jan Cholasta wrote: If you plug a PKCS#11 module into p11-kit, will p11-kit use NSS trust objects from the module? No. This is the spec for storing trust policy in PKCS#11 that we've been working on: http://p11-glue.freedesktop.org/doc/storing-trust-policy/ It's a far more extensible and future proof model. The p11-kit-trust module stores/loads these sorts of objects, and additionally also generates NSS trust objects on the fly so that NSS can consume the information. It doesn't do that last bit for third party sources, but it could given code :) Code is not a problem :) What would be the best way to provide trust policy to p11-kit from a third party PKCS#11 module, if not NSS trust objects? I obviously think that using the new stuff linked above would be best. It's future proof and models this comprehensively. That would allow extracting compat trust anchors to files (for crypto libraries that don't yet support looking it up trust via PKCS#11). But I understand if you're hesitant to commit to this spec that's in development (albeit already implemented). Actually, I like it. Is everything mentioned at http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-pkcs11.html going to be standardized? There's a third simple way to store trust, which is using standard PKCS#11. It's very limited: * Store certificates with the CKA_TRUSTED attribute set to CKA_TRUE and CKA_CERTIFICATE_CATEGORY set to 2. This method covers storing certificate authority anchors only. The above spec is a superset of this simple way of storing trust. NSS trust objects are not. So I would suggest implementing this simple mechanism and then implement the full spec later. I'm afraid this is simple too much. If you want to have a call/hangout about this and discuss, I'd be happy to. Thanks! Cheers, Stef -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAP schema for PKCS#11
Hi, adding Stef Walter to CC, as he has extensive knowledge of PKCS#11. On 3.3.2014 12:51, Ludwig Krispenz wrote: Hi, starting a new thread, after a lot of discussion and feedback, which I tried to integrate into thecurrent draft at: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema Here are some design decisions I made and which need to be finally decided. 1] Add nss trust objects. These are not defined in the PKCS#11 standard, but Jan said they will be needed and I added them to the spec For the record, here are some details about NSS trust objects: http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-existing.html BTW, there are some additional attributes defined in /usr/include/nss3/pkcs11n.h besides these mentioned in the link above: CKA_TRUST_IPSEC_END_SYSTEM CKA_TRUST_IPSEC_TUNNEL CKA_TRUST_IPSEC_USER CKA_TRUST_TIME_STAMPING CKA_TRUST_STEP_UP_APPROVED Can you please add them as well? 2] Certificate representation In pkcs11 there is a certificate category (user, authority, ..) and certificate value. An alternate way to represent this would be to use the schema defined in rfc4523 and map (user, value) -- (objectclass: pkiUser, usercertificate) and (authority, value) -- (objectclass: pkiCA, cAcertificate) I kept the attributes pkcs11certificateCategory and pkcs11certificateValue and let the applications decide which format will be used. Applications talking to PKCS#11 do not need to be concerned with this and applications talking to LDAP will be only us. This only adds complexity, as there will have to be two code paths to handle certificates (plus code for handling conflicts between them, etc.) in the module instead of just one. I would prefer if pkcs11certificateValue and pkcs11certificateCategory were removed. They can be re-added later if someone needs them (we don't). 3] Key attributes Like certificates keys can be stored ina single attribute as pkcs8 or bind.key format. In pkcs11 the keys are defined by their algoritthm specific attributes, I had defined RSA specific attributes (moduleus, exponent, ) and did not remove them. Maybe some app wants to create keys and store these attrs, having defined them does not force to use them, but allows flexibility without requiring new attribute definitions These attributes do not add flexibility, because they are RSA only, they only add complexity, because (again) there will have to be two code paths in the module to handle keys. Again, I would prefer if the extra attributes were removed. 4] Not needed attributes. Jan pointed out that some of the attributes like CKA_TOKEN will always be true, so no need to define them. I have not yet removed them, they don't nned to be used, but I can still remove them. Please do. It just makes no sense to have an LDAP attribute for CKA_TOKEN. 5] Attribute syntaxes I associated boolean attributes with the ldap boolean syntax, which requires TRUE/FALSE as values There are a couple of attributes with a limited range like key_type which has values like: CKK_RSA, CKK_DSA, CKK_DH. There are defines for these values which translate them to integers, which could be used, but I propose to use a syntax of directoryString and use the values directly eg pkcs11keyType: CKK_RSA. To me this is more readable than pkcs11keyType: 0 And it would have to be parsed anywy +1, but I would prefer just pkcs11keyType: rsa (i.e. camel-cased and stripped of CKK_ prefix) rather than pkcs11keyType: CKK_RSA. The attribute is named pkcs11keyType, not pkcs11CKA_KEY_TYPE after all. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAP schema for PKCS#11
On 3.3.2014 15:07, Stef Walter wrote: On 03.03.2014 15:03, Jan Cholasta wrote: If you plug a PKCS#11 module into p11-kit, will p11-kit use NSS trust objects from the module? No. This is the spec for storing trust policy in PKCS#11 that we've been working on: http://p11-glue.freedesktop.org/doc/storing-trust-policy/ It's a far more extensible and future proof model. The p11-kit-trust module stores/loads these sorts of objects, and additionally also generates NSS trust objects on the fly so that NSS can consume the information. It doesn't do that last bit for third party sources, but it could given code :) Code is not a problem :) What would be the best way to provide trust policy to p11-kit from a third party PKCS#11 module, if not NSS trust objects? -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAP schema for PKCS#11
On 03.03.2014 15:03, Jan Cholasta wrote: This link definitely should be somewhere in design docs. BTW, there are some additional attributes defined in /usr/include/nss3/pkcs11n.h besides these mentioned in the link above: And this too... Feel free to upload the file to wiki if you didn't find any on-line repo suitable for direct linking from design docs. CKA_TRUST_IPSEC_END_SYSTEM CKA_TRUST_IPSEC_TUNNEL CKA_TRUST_IPSEC_USER CKA_TRUST_TIME_STAMPING CKA_TRUST_STEP_UP_APPROVED Can you please add them as well? 2] Certificate representation In pkcs11 there is a certificate category (user, authority, ..) and certificate value. An alternate way to represent this would be to use the schema defined in rfc4523 and map (user, value) -- (objectclass: pkiUser, usercertificate) and (authority, value) -- (objectclass: pkiCA, cAcertificate) I kept the attributes pkcs11certificateCategory and pkcs11certificateValue and let the applications decide which format will be used. Applications talking to PKCS#11 do not need to be concerned with this and applications talking to LDAP will be only us. I would like to emphasis Rob's idea that this schema is IPA-specific for now but we should assume that other PKCS#11-LDAP implementations can exist. And also NSS specific, given the storage of NSS trust. I think we can make that conditional, i.e. by using an environment variable or the reserved argument in C_Initialize (like NSS does). If you plug a PKCS#11 module into p11-kit, will p11-kit use NSS trust objects from the module? No. This is the spec for storing trust policy in PKCS#11 that we've been working on: http://p11-glue.freedesktop.org/doc/storing-trust-policy/ It's a far more extensible and future proof model. The p11-kit-trust module stores/loads these sorts of objects, and additionally also generates NSS trust objects on the fly so that NSS can consume the information. It doesn't do that last bit for third party sources, but it could given code :) Stef ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAP schema for PKCS#11
On 03.03.2014 14:30, Petr Spacek wrote: On 3.3.2014 13:49, Jan Cholasta wrote: On 3.3.2014 12:51, Ludwig Krispenz wrote: starting a new thread, after a lot of discussion and feedback, which I tried to integrate into thecurrent draft at: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema I have added couple links and typo fixes to the document. Please add externals links when referring to some other standard so other people don't need to dig related links again and again. (I have added links for PKCS#8 and PKCS#11.) What is this for? This seems pretty wild :) Here are some design decisions I made and which need to be finally decided. 1] Add nss trust objects. These are not defined in the PKCS#11 standard, but Jan said they will be needed and I added them to the spec For the record, here are some details about NSS trust objects: http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-existing.html Right, the NSS trust objects are definitely not an extensible scheme. What's your use case. Don't you already have other ways in LDAP of indicating trust in a certificate? This link definitely should be somewhere in design docs. BTW, there are some additional attributes defined in /usr/include/nss3/pkcs11n.h besides these mentioned in the link above: And this too... Feel free to upload the file to wiki if you didn't find any on-line repo suitable for direct linking from design docs. CKA_TRUST_IPSEC_END_SYSTEM CKA_TRUST_IPSEC_TUNNEL CKA_TRUST_IPSEC_USER CKA_TRUST_TIME_STAMPING CKA_TRUST_STEP_UP_APPROVED Can you please add them as well? 2] Certificate representation In pkcs11 there is a certificate category (user, authority, ..) and certificate value. An alternate way to represent this would be to use the schema defined in rfc4523 and map (user, value) -- (objectclass: pkiUser, usercertificate) and (authority, value) -- (objectclass: pkiCA, cAcertificate) I kept the attributes pkcs11certificateCategory and pkcs11certificateValue and let the applications decide which format will be used. Applications talking to PKCS#11 do not need to be concerned with this and applications talking to LDAP will be only us. I would like to emphasis Rob's idea that this schema is IPA-specific for now but we should assume that other PKCS#11-LDAP implementations can exist. And also NSS specific, given the storage of NSS trust. Cheers, Stef ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
