Re: Mandated non-critical controls (was: Protocol: control specifications.)

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

I don't think this is a good enough reason to mandate that of 
control specifications.   I am sure someone could come up with
a reasonable control extension which should never be marked
critical, for instance one specifically designed to test that
servers are properly ignoring non-critical controls.  I think
it better to leave whether such a mandate, if one is ever
proposed in a control specification, is appropriate or not
should be left to review/consideration of that specification
for publication (whether by the IETF or other party).

I think this kind of consideration (and I think it really just
something extension authors/reviewers need to consider) is best
left to a document detailing guidelines to authors of extensions.

Kurt

At 01:33 PM 3/11/2004, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>
>> what happens when a new security consideration arises that
>> suggests that a control, whose previous specification said be
>> non-critical, should not be critical in a some cases.  A sender
>> verification requirement would disallow simply changing the guidance
>> provided to the client developer (or user), but force the introduction
>> of a replacement control.
>
>Good point.  That applies to both client verification of user-supplied
>criticality, which [Protocol] does allow, and server verification of
>criticality.  It looks like X.500 knows what it is doing in only
>allowing mandates of TRUE criticality.
>
>I suggest we forbid control specs to mandate a request control to be
>non-critical.
>
>Leave response criticality as it is, since it is ignored, and since RFCs
>2649 and 2891 already mandate response controls to be non-critical.
>
>If there are existing control specs that mandate a request criticality
>of FALSE, we could forbid both servers and clients to verify that,
>but the real fix is to update the control specs.
>
>-- 
>Hallvard