Bug 5805 - certificate routines do not encode distinguished name correctly
Summary: certificate routines do not encode distinguished name correctly
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Smart card (show other bugs)
Version: pre-1.0
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.8.0
Assignee: Pierre Ossman
Keywords: relnotes, samuel_tester, thomas_tester
Depends on:
Reported: 2016-02-24 14:57 CET by Pierre Ossman
Modified: 2017-03-24 16:17 CET (History)
4 users (show)

See Also:
Acceptance Criteria:


Description Pierre Ossman cendio 2016-02-24 14:57:15 CET
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.
Comment 1 Pierre Ossman cendio 2016-02-24 14:58:08 CET
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.
Comment 4 Pierre Ossman cendio 2016-03-08 14:33:06 CET
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.
Comment 5 Pierre Ossman cendio 2016-07-15 12:03:04 CEST
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.
Comment 6 Pierre Ossman cendio 2016-07-15 12:41:06 CEST
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.
Comment 13 Pierre Ossman cendio 2016-11-18 12:39:50 CET
The nightly build is now able to properly parse the certificate on FMV's cards.
Comment 15 Henrik Andersson cendio 2016-12-08 12:36:35 CET
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
Comment 17 Karl Mikaelsson cendio 2016-12-09 12:26:31 CET
Build times are back to normal (approximately 1 hr 15 minutes) after r31944. 


Note You need to log in before you can comment on or make changes to this bug.