W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 1999

Re: Some possible rqmt/design points

From: David Solo <david.solo@citicorp.com>
Date: Wed, 16 Jun 1999 10:26:02 -0400
Message-Id: <199906161334.JAA19787@egate3.citicorp.com>
To: Phillip M Hallam-Baker <pbaker@verisign.com>
Cc: IETF/W3C XML-DSig WG <w3c-ietf-xmldsig@w3.org>
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
Received on Wednesday, 16 June 1999 10:23:55 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:06 GMT