[Freeipa-devel] LDAP schema for PKCS#11

[Ludwig Krispenz]

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