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

RE: on criticality flags

From: Phillip M Hallam-Baker <pbaker@verisign.com>
Date: Thu, 29 Jul 1999 11:30:07 -0400
To: "Barb Fox (Exchange)" <bfox@Exchange.Microsoft.com>, "John Boyer" <jboyer@uwi.com>, "'DSig Group'" <w3c-ietf-xmldsig@w3.org>
Message-ID: <002001bed9d7$3c9ef900$6e07a8c0@pbaker-pc.verisign.com>
> I believe that Dave Solo and I both posted on this with strong feelings
> against criticality flags. My comment was that WEBDAV has already thought
> this through (ck out RFC
> 2518) and have chosen to have clients ignore elements they do not
> understand. I also share Dave's  "sub-optimal" experience with criticality
> flags in PKIX. Frankly, I thought we agreed to drop them at MIT
> and I don't
> recall any revival in Oslo.

That's probably because I could not make either meeting...

I think we do need a mechanism by which a client can be told that
it should not attempt to process a message it may not understand

One specific condition I have been considering is the case in
which an XML message represents a negotiable instrument (e.g.
a Bill of Lading). The conditions of validity for which can
only be understood in the context of a particular rule book.
In this case I would like to ensure that clients which are
not aware of the requirements of a specific rule book do not
erroneously validate the signature.

The problem with criticality flags is that they are too fine
grained and lead to overuse but the effect is on occasion usefull.

A better means of achieving the desired result would be a
specific criticality attribute which would reference a URI. E.g.

<critical uri="http://eterms.icc.org/private/2001/1583209">


Similar requirements pop up in the public space - literally.
Barb and I know a certain lawyer who is keen to have disclaimers
pop up to achieve 'constructive notice' of certain terms
and conditions.

I certainly don't think we need a system as fine grained as X.509v3
criticality flags. But we do need to recognise that in the case
of signatures restricted interoperability is sometimes explicitly

In terms of implementation difficulty this should not be too much
trouble. The 'check signature' property of the XML document object
simply flags a warning that everything has checked out but there
may be some problems.

Generic clients are also much better off since instead of 'there
may be a problem here but I'm not going to tell you what' they can
be refered to a source which can resolve the problem.

Received on Thursday, 29 July 1999 11:28:55 UTC

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