[Freeipa-devel] Handling certificates in JSON/XML-RPC (was: ticket 1201 status)

[John Dennis]

[ 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 <jdennis at redhat.com>

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