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:
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.)

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:
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.


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.

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.
This does not contradict my previous statement :-) Other PKCS#11 module implementations have to follow what we define here and I also prefer to keep it simple and extend it later as needed.

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.
I agree.

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.

Petr^2 Spacek

Freeipa-devel mailing list

Reply via email to