Re: Some possible rqmt/design points

Phill,

My objection to the criticality flag is both philosophical and
practical.  On the philosophical front, if the information is part of
the document, such as terms and conditions of a contract, it should be
part of the signed thing rather than an external attribute (see my reply
to Barb).  Also, beyond the basic mathematics, I will continue to argue
that the decision to "accept" a signed thing is based on the rules of
the relying party, not the signer (although quite possibly dictated by
external agreement); hence the assertion of criticality by the signer is
misplaced.

On the practical front, the experience with criticality in X.509 has
been a nightmare.  Problems range from interoperability (I can't include
an extension/attribute with a critical flag unless I'm sure all RP
software will handle it); ambiguous semantics (does the meaning of the
attribute change based on criticality); migration/deployment problems;
whether all attribute/extension processing is done at the same time;
etc.

This was, as I recall, part of the rationale for removing criticality
from the CMS attribute fields.

Dave

Phillip M Hallam-Baker wrote:
> 
> I would like to know the reasoning for prohibiting
> criticality flags.
> 
> The semantics "if you do not understand X then you
> do not understand this signature" appears to me to be
> essential.
> 
> For example X might be 'check that this document has
> not subsequently been revoked and superceeded using
> a (specified) OCSP type mechanism'.
> 
> This type of semantics is essential if signed documents
> are to be used to represent signed negotiable documents
> such as a letter of credit of a bill of lading.
> 
>                 Phill