Bugzilla – Bug 5805
certificate routines do not encode distinguished name correctly
Last modified: 2017-03-24 16:17:42
You need to
before you can comment on or make changes to this bug.
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
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
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
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
Build times are back to normal (approximately 1 hr 15 minutes) after r31944.