[ 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.
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
John Dennis <jden...@redhat.com>
Looking to carve out IT costs?
Freeipa-devel mailing list