RE: Proofread of XOP draft

Thanks for the quick review.

Martin Gudgin writes:

> > Note, however, that a signature over the Infoset does not
> > necessarily protect against modifications of other aspects of the XOP
> > packaging;  for example, an Infoset signature check might not protect
> > against an exchange of position of two non-root parts. 
> 
> I'd stop right here. In fact, I might change 'an exchange of position of
> two non-root parts' to 're-ordering of non-root parts'
> 
> > To 
> > protect against
> > such modifications, the serialization of the multipart 
> > related or other
> > package would have to be signed, but no standard means is 
> > here proposed for
> > computing package-level signatures." 
> 
> I would NOT include this text. It's unclear to me what attack is
> possible. I understand that two MIME parts might get swapped, 
> order wise at the MIME level but at the infoset level they'd still be in
> the 'right' order.

I'm fine with stopping where you suggest. 

As to what attacks are possible:  we allow a variety of optional content 
at the multipart level.  Although I was not particularly in favor, and 
would discourge their use especially with SOAP, I believe we do allow 
parts that are not referenced by xop:Include.  Presumably a creative user 
of xop could also find ways to use MIME headers to transmit out of band 
information.  Also presumably, if these are used, then they are there for 
the benefit of someone at the receiving end.  I just think it's important 
that we not somehow imply that these things are protected by a dsig at the 
"input Infoset" level. 

Anyway, that's just answering your question.  I have no problem at all 
"stopping" at the point you suggest.

> > 
> > * Section 3.1: Suggest:  "Any other namespace qualified attribute
> > information items with a [namespace name] different of
> > "http://www.w3.org/2003/12/xop/include". " -> "Other 
> > attribute information
> > items; these MUST have a [namespace name] the value of which 
> > MUST NOT be
> > "http://www.w3.org/2003/12/xop/include"."
> 
> I think 'Other namespace qualified attribute information items;' as
> [namespace name] can be present but have no value ( for unqualified
> attributes ). This is also more consistent with your suggested text for
> elements above.

Thank you for clarifying.  I had been unclear on Infoset rules for unqual. 
attributes and was offline at the time.  So, I think I agree with the 
spirit of your comment, but am having a bit of trouble figuring out 
exactly what text you recommend.  How about: ""Other namespace qualified 
attribute.   Any such element information item MUST have a [namespace 
name] and that name MUST NOT be "http://www.w3.org/2003/12/xop/include".". 
 Is that what you were suggesting?



--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Wednesday, 19 May 2004 10:42:59 UTC