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

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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