[ I had a private email exchange with Rob concerning ticket 1201, we've had a long standing issue with how certificates are exchanged because in LDAP they are binary values. I told Rob I had a proof of concept working and Rob sent me a code snippet illustrating an earlier attempt he had made to fix the problem that didn't pan out. I wrote this reply as a response to Rob to explain my approach but it occurred to me this is a design issue which should be in open discussion thus this reply is to the devel list so others can review it and be in the loop. Apologies if you missed some earlier context. ]

-----------------------------------------------------------------

Thanks for the code snippet. I think the problem you might have run into is that you were doing the conversion at the point xmlrpc parameters are marshaled, that doesn't cover the json case (or other locations).

The way I'm planning on tackling this is to do the pem conversion at the moment it's read from LDAP. We already have a mechanism for that and you helped point me towards it when you mentioned wehandle some attributes specially based on it's LDAP syntax.

We "decorate" the find_entries() method in ldap2 with the @decode_retval() decorator. What this does is examine the values returned from the LDAP query and converts them to our preferred types. I stumbled upon this while doing the DN work, I didn't know it existed, it's not all that visible when reading the code this conversion is occurring. It calls into something called an Encoder object (in encoder.py) which is a parameterized mechanism setup in ldap2. In summary what it does is use a table ( _SYNTAX_MAPPING) to lookup the attributes syntax and as long as it's not in the table it gets promoted to unicode, otherwise it's left as a str.

With a few tweaks this mechanism could be a bit more flexible. Rather than just using the existence of the attribute in the table as the decision on whether to call a conversion routine on it (e.g. encoding to unicode) the value in the table could be a function pointer to a conversion routine. Thus the logic would become "if the attribute is in the table, call the converter on the value, otherwise fallback to the default conversion (which happens to be UTF-8 <-> unicode".

In short what will happen is the whenever a 'usercertificate' is returned from LDAP (DER format) it will be converted to PEM format as a unicode object (i.e. indicating it's text data) in the result.

I believe this is fine because most of the places we use certificates internally already pass PEM formatted versions and call into x509.normalize_certificate() which checks for PEM vs. DER encoding.

This then completes another aspect of the "always use PEM formatting" for certs code cleanup.

The only thing left to do is modify the javascript code to stop looking for usercerticate attributes as base64.

The command line tools which save a cert to a file perform a binary to PEM conversion at the point they write the file. At first blush you might think that logic should be removed since now certs will be returned in PEM format, hence no conversion is necessary. But I think I'm going to leave that logic in place, here's why: The code calls into x509.normalize_certificate() thus it can accept the cert either as binary or PEM. The command line might be connected to a server without the new modification, thus if we leave it as it currently is the command line will work with either an old or new server response. The javascipt code in the web UI is tied to the server so those changes will occur in lockstep.



--
John Dennis <jden...@redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to