RE: Some possible rqmt/design points

>  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.

OK Dave, I accept the point that the interpretation of the work is
performed by the recipient. I don't however accept that this means
that the sender should not have the means to fully express their 
original intentions.

The semantics 'If you don't understand X then you don't understand 
this signature' are pretty basic.


> 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)

This is not a bug - it is the intention of the feature!

Unlike the traditional IETF projects signed XML will not be an
arena where everything SHOULD interoperate with everything
else.

I have an XML document in one hand which represents a Bill
of Lading. Do I want that document to be accepted unquestioned
by the application that handles Letters of credit?

The purpose of the signature attributes is to prevent
a signature issued to one context being erroneously
interpreted by another. See Bruce S's paper on protocol
substitution attacks.


Unless it is possible to bind the context of the signature 
unambiguously to the signature we will encounter a whole
rack of legal problems.

This is of course exactly the solution that the hermeneuts
have taken in philosophy. Faced with the problem of interpretation
of the text the likes of Derrida have asserted that the text
may be interpreted in an infinite number of ways - each relative
to a different context. If you want to constrain the interpretation
of the text you have to specify the context in which to interpret it.


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

Which is a fundamental mistake in the CMS document.

Presumably people are interested in doing something with Signed-XML
which S/MIME cannot address. My interests would be enabling supply 
chain integration, e-commerce, dematerializing documents and such.


		Phill

Received on Wednesday, 16 June 1999 10:53:25 UTC