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>

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

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;

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


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 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:31 UTC