Re: Controls and criticality

[Kurt Zeilenga <Kurt@OpenLDAP.org>]

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

> Kurt Zeilenga wrote:
> > 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.
>
> Yes.  But this is a consequence of the fact that some controls'  
> specs seem to overload the criticality flag with some additional  
> semantics.

Though there are certainly one or two such specifications, a spec  
which simply says a client MUST specify mark a particular control as  
critical does not create such an overload.  This is because a client  
MUST does not impart any requirement upon the server.

-- Kurt