URL: https://github.com/freeipa/freeipa/pull/298
Title: #298: ipaldap: handle binary encoding option transparently

frasertweedale commented:
@jcholast I disagree.  If `ipaldap` is a generic LDAP client, it should obey 
the RFCs and always transfer the relevant attributes (`userCertificate`, 
`cACertificate`, etc) with the `;binary` encoding option, and it should expect 
to see it when reading the relevant attributes from the server.  IMO `ipaldap` 
should handle this transparently because it is part of the LDAP protocol.  
There is no 389DS-specific hack in my proposed change (but I'm curious about 
what part of it you feel is).

This would also avoid inconsistent handling of relevant attributes between 
different plugins, which is the situation we currently have.  But apart from 
the inconsisency (which is a nusiance) we have a bigger problem - in several 
plugins we specifically try to read `userCertificate`, but a RFC 4522  
compliant server (which 389DS is not now, but hopefully one day will be) will 
always return `userCertificate;binary`.  So, our current code breaks if/when 
that happens.  Furthermore, other RFC 4522-compliant programs that correctly 
use the `;binary` transfer encoding option to, e.g. write certificates to user 
entries, will cause those certificates to be unreadable but *currenty* IPA 
code.  This is not good enough.

> Also note that the real bug in 389 DS is that it defines the attribute types 
> to use octet string syntax, rather than the certificate syntax as defined in 
> RFC 4523. It actually behaves correctly, not enforcing the binary transfer 
> option on attribute types with octet string syntax.

389DS does not behave correctly; it's treatment of `;binary` is wrong in 
several ways, apart from the incorrect attribute syntax for relevant attributes.

See the full comment at 
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to