RE: Some possible rqmt/design points

Dave,

I think that we need to support detached signatures as the default. Wrapped
is fine, but the discussion has been trending dangerously close to
recreating CMS in XML. Attributes have a long history as semantic carriers
in that world, so I would like to see us set the design goal of using XML to
make qualified statements about XML blobs. My vote: Attributes = just say
NO. 

I also didn't see any discussion (flames?) on my comment about criticality
flags. I believe that WEBDAV has already made that call (ignore) for XML, so
I think criticality flags should be another NO in our design. 

Finally, I think we're also spending way too much time on semantics where
the short-term focus should be just getting the syntax right.  

--Barb

-----Original Message-----
From: David Solo [mailto:david.solo@citicorp.com]
Sent: Wednesday, June 16, 1999 6:32 PM
To: Barb Fox (Exchange)
Cc: IETF/W3C XML-DSig WG
Subject: Re: Some possible rqmt/design points


Barb,

Why do you think that wrapped vs. detached signatures impacts the need
(or lack thereof) of associating attributes with the signature (vs. the
content)? It seems to me that the argument should be the same.  For what
its worth, I think we need to handle both.

Dave

Barb Fox (Exchange) wrote:
> 
> Dave/Phill:
> 
> On attributes: I don't think we're heading towards a default of wrapped
> signature for XML. Detached makes a lot more sense to me.
> 
> On criticality flags: WEBDAV has already thought this through (ck out RFC
> 2518) and have chosen to have clients ignore elements they do not
> understand.
> 
> --Barb
> 
> -----Original Message-----
> From: Phillip M Hallam-Baker [mailto:pbaker@verisign.com]
> Sent: Wednesday, June 16, 1999 7:54 AM
> To: david.solo@citicorp.com
> Cc: IETF/W3C XML-DSig WG
> Subject: 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 Thursday, 17 June 1999 10:36:25 UTC