The routines used by the client and tl-certtool to convert the subject or issuer to a string aren't correctly implemented. They assumed that every value can be represented as a DirectoryString, which is not what RFC 4514 states. The proper way is to encode it according to the LDAP "syntax" definition for the given type. The encodings are given in RFC 4517 section 3.3 (there are 34 of them). They are fairly straight forward, so it's just a matter of following the RFC and putting the work in. However we also need a mapping between the type OID and the corresponding syntax. We need the LDAP schema for all relevant OIDs for that.
We could look at stealing this from some existing LDAP project, e.g. OpenLDAP. They clearly have some DN to string routines, and hopefully they are RFC 4514 compliant.
OpenLDAP seems to have a lot of parsing and validation routines, but oddly enough few output routines. So it looks like we'll have to write this ourselves.
Apparently GnuTLS has a parser and encoder for RFC 4514. Unfortunately it seems to be out of spec. I've sent a message to their mailing list for comments.
After digging around with this, I think we may need to take a few steps back and have a look at the bigger picture. RFC 4514 allows many different encodings for the same DN. As such it is really fundamentally incompatible with what we are using it for. passwdaliases does dumb string comparison, which would require a canonical string representation. And RFC 4514 _does not_ provide that. One key point in this is the list of attributes we have. Right now we have a checked in copy from 2009. The current version is from last year has more entries and an update would hence change what many strings look like. The proper way is to parse the string representation and compare the structures. So we should really specialise passwdaliases to a "certaliases". That however still leaves the problem of when the encoder and parser have different attribute lists. Generally speaking, the encoder must have a subset of the list the parser has. The safe approach would be to keep the encoder list small (RFC 4514 defines a minimum), and the parser list as up to date as we can.
The nightly build is now able to properly parse the certificate on FMV's cards.
Jenkins build trends shows that buld of client increased from 1 h 12 min to 3 h 10 min with jenkins build number #325. This build is triggered by commits on this bug. [1] https://jenkins.lkpg.cendio.se/view/All/job/ThinLinc%20-%20Client%20Bundle/buildTimeTrend
Build times are back to normal (approximately 1 hr 15 minutes) after r31944. Good!
