[Freeipa-devel] LDAP schema for PKCS#11

[Jan Cholasta]

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