Re: Controls and criticality

[Kurt Zeilenga <Kurt@OpenLDAP.org>]

On Nov 2, 2008, at 11:00 AM, Pierangelo Masarati wrote:

> Kurt Zeilenga wrote:
> > In short,
> > if the control is critical, the server cannot ignore it.  It must  
> > either make use of it as prescribed or fail.
> > if the control is non-critical, the server can choose to ignore  
> > it.  However, it should only do so before making use of it as  
> > prescribed.
> > Some controls specifications are simply broken.  No part of the  
> > 'making use of the control' should depend on the value of  
> > criticality.
>
> I'm not questioning this.  I'm questioning the fact that the DSA  
> allows a client to be happy with using a control with a criticality  
> that could endanger the data integrity or security (and, all in all,  
> violates the control's specs).
>
> Also, I understand that rejecting an operation because it was  
> performed with a non-critical control is in contrast with RFC4511.

Absolutely not.  In making use of the control, critical or not, the  
server can certainly return an error.
Now RFC 4511 does allow for a server to, if it can, process the  
operation without the control.  But the server certain cannot process  
a part the operation with the semantics implied by the operation and a  
part without.


> Handling of dontUseCopy needs to be fixed in slapd (see ITS#5785)  
> for conformance with RFC4511, although this would allow slapd to  
> process a control whose criticality setting is in violation of its  
> specs.

The server is not responsible for odd service if client fails to mark  
dontUseCopy critical.

> I'm even more concerned about handling of RFC4370, which is now  
> handled in full conformance of RFC4511, but I'd rather prefer that  
> slapd rejects it if requested with criticality set to FALSE.

The server shouldn't even consider criticality in its processing until  
after deciding not to make use of a control, whether to fail due or  
ignore the control.

> To me, slapd should reject those cases with protocolError.

This kind of breaks the separation between the controls criticality  
processing and control processing.

I tend to prefer 'be liberal in what you accept'.  However, if I were  
to redesign LDAP from scratch, I'd remove the concept of a non- 
critical control in favor of requiring the client to fall-back.   At  
present, most clients don't provide any fall-back.  But I digress.