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.
userCertificate;binary
userCertificate
Proof of concept that puts the logic in ipaldap: https://github.com/freeipa/freeipa/pull/298/files
ipaldap
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).
Closing wontfix. Discussion at https://github.com/freeipa/freeipa/pull/298.
Metadata Update from @ftweedal: - Issue assigned to ftweedal - Issue set to the milestone: 0.0 NEEDS_TRIAGE
Login to comment on this ticket.