<div dir="ltr"><div><div><div><div><div><div>In your descriptions, can you translate all acronyms according to:<br><br><a href="http://www.cryptsoft.com/pkcs11doc/v220/group__SEC__5__SYMBOLS__AND__ABBREVIATIONS.html">http://www.cryptsoft.com/pkcs11doc/v220/group__SEC__5__SYMBOLS__AND__ABBREVIATIONS.html</a><br>
</div><div>...and...<br><a href="http://www.cryptsoft.com/pkcs11doc/v220/group__SEC__10__2__COMMON__ATTRIBUTES.html">http://www.cryptsoft.com/pkcs11doc/v220/group__SEC__10__2__COMMON__ATTRIBUTES.html</a><br><br></div>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.<br>
<br>You have good descriptions throughout your spec, but don't put those descriptions into your rfc2252 LDAP attribute definitions where they belong.<br><br></div>Also, how are you deciding on capitalization in all cases? E.g, pkcs11uniqueid vs. pkcs11uniqueId vs. pkcs11uniqueID.<br>
<br></div>See #3.5, supposed to be pkcs11nsstrust (pkcs11nssTrust?), but it starts with "(  <ipapkcs11OID>.2.5 NAME  'pkcs11certificate' ".<br><br><br></div>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.<br>
<br></div><br></div>Thanks,<br><br>Derek<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 3, 2014 at 5:51 AM, Ludwig Krispenz <span dir="ltr"><<a href="mailto:lkrispen@redhat.com" target="_blank">lkrispen@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
starting a new thread, after a lot of discussion and feedback, which I tried to integrate into thecurrent draft at:<br>
<a href="https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema" target="_blank">https://fedorahosted.org/bind-<u></u>dyndb-ldap/wiki/BIND9/Design/<u></u>pkcs11Schema</a><br>
<br>
Here are some design decisions I made and which need to be finally decided.<br>
<br>
1] Add nss trust objects.<br>
These are not defined in the PKCS#11 standard, but Jan said they will be needed and I added them to the spec<br>
<br>
2] Certificate representation<br>
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<br>
(user, value) --> (objectclass: pkiUser, usercertificate) and (authority, value) --> (objectclass: pkiCA, cAcertificate)<br>
I kept the attributes pkcs11certificateCategory and pkcs11certificateValue and let the applications decide which format will be used.<br>
<br>
3] Key attributes<br>
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<br>

<br>
4] Not needed attributes.<br>
Jan pointed out that some of the attributes like CKA_TOKEN will always be true, so no need to define them.<br>
I have not yet removed them, they don't nned to be used, but I can still remove them.<br>
<br>
5] Attribute syntaxes<br>
I associated boolean attributes with the ldap boolean syntax, which requires TRUE/FALSE as values<br>
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<br>

And it would have to be parsed anywy<br>
<br>
______________________________<u></u>_________________<br>
Freeipa-devel mailing list<br>
<a href="mailto:Freeipa-devel@redhat.com" target="_blank">Freeipa-devel@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/freeipa-devel" target="_blank">https://www.redhat.com/<u></u>mailman/listinfo/freeipa-devel</a><br>
</blockquote></div><br></div>