#6529 ipaldap: handle binary encoding option transparently
Closed: Invalid None Opened 7 years ago by ftweedal.

Per RFC 4523, particular attribute syntaxes require use of the
';binary' attribute option. Attributes using these syntaxes include
'userCertificate' and 'cACertificate'. Our handling of this
requirement is inconsistent with no library support (i.e. it was up
to individual plugin authors to "do the right thing".

Also, because 389 DS currently does not always use this encoding
option (which is a defect), whether you need to read the
'userCertificate' or 'userCertificate;binary' attribute - or both -
is often unclear. But technically, these both refer to the same
attribute, because the 'binary' option does not specify an attribute
subtype.

Plugin code should be able to just refer to the attribute
without including the binary encoding option, and ipaldap should
automatically add it when sending attribute to the server, and
strip it when reading attributes in search results.

This issue came to light during an attempt to simplify the
cert_request code that adds the newly issued cert to the principal's
userCertificate attribute. It is problematic because user plugin
looks for userCertificate;binary whereas service/host plugins look
for userCertificate.


Proof of concept that puts the logic in ipaldap:
https://github.com/freeipa/freeipa/pull/298/files

Why ipaldap? It is part of the LDAP protocol and should apply
to all code that reads/writes LDAP, directly or indirectly.

See also related 389ds ticket: https://fedorahosted.org/389/ticket/49059

I agree that https://fedorahosted.org/389/ticket/49059 is valid. I put https://fedorahosted.org/freeipa/ticket/6530#comment:2 and https://fedorahosted.org/freeipa/ticket/6530#comment:3 some incoherent results.

Now I have not found in ipa something already broken because of https://fedorahosted.org/389/ticket/49059

Assuming https://fedorahosted.org/389/ticket/49059 will be fixed, to prepare freeipa to this fix, IMHO freeipa should rather use 'RFC 4523', add ';binary' in stored value, requested attributes and filter attribute also expect to receive ';binary' attribute when they are returned.

https://github.com/freeipa/freeipa/pull/298/files removes ';binary' that looks good for now. But do we need that fix now as I think it goes in the opposite was of https://fedorahosted.org/389/ticket/49059

Thierry, https://github.com/freeipa/freeipa/pull/298/files does not remove the 'binary' option;
the change is to automatically add it/remove it as necessary. Therefore the user code just
reads/writes the 'certificate' attribute (this is why the ';binary' part is removed in lots of places).

Fraser, just to be sure. Is https://github.com/freeipa/freeipa/pull/298/files fixing an existing problem or is it hardening of the current code ?

Thierry, it does not fix any actual bug, but it does resolve the inconsistent handling
of the attribute within FreeIPA (which IMO is a bit of a problem).

Metadata Update from @ftweedal:
- Issue assigned to ftweedal
- Issue set to the milestone: 0.0 NEEDS_TRIAGE

7 years ago

Login to comment on this ticket.

Metadata