Re: Request for Dependency Resolution or Review

At 15:48 99/09/17 -0500, Paul Grosso wrote:
 >You are soliciting a commitment, but you don't suggest a timeframe for
 >response.  Specifically, I don't know how to make any commitment in
 >the name of a WG that doesn't yet exist and doesn't expect to exist
 >for perhaps many months.  Is is acceptable that you wait for any
 >response to your request for commitment until the WG exists, or do 
 >you have a different suggestion?

We'll play it by ear, obviously we won't wait till you guys finish, we'll
design our own very simple version, though our requirements would still be
relevant to a general XML packaging standard. However, I see packaging is
going to be discussed at the Plenary, and if it somehow gets bumped up, it
might make sense to play it out differently.

 >shouldn't be co-chair of the XML Packaging WG!  But whenever it becomes
 >time to consider the dependencies you list, someone will have to explain
 >to me what they mean.  But I guess there is no need to do that now if
 >the plan is to wait for the WG to exist before going any further.
 >
 >paul
 >
 >>   Dependency: logical/assertion semantics of
 >>   package must be explicit.

We have to know what the semantics behind a package. Can it be viewed as a
series of assertions in a predicate logic? If I munge two things together in
a package (like a document and style sheet) is that an assertion that those
two resources also corresponded to some URI? Who made that assertion, same
person as the package creator, or the guy who dereferenced the URIs? (Maybe
they are the same, maybe not.) If there are statements in a a package that
signatures and trust engines (applications) care about, are those assertions
AND'd together, or OR'd together for evaluation?

If this isn't clear, hopefully it'll become so as the signature work moves
forward.

 >>   Dependency: expectations regarding the processing (e.g., white space)
 >>   of content within a package must not violate signature or XML content
 >>   semantics.
 
Drats, I forget what this means exactly. I think it referred to having a
signed piece of XML (the signature wraps the XML content
<signature><content/></signature>) stay a valid signature, even when you
wrap it within a package.. <package><object
id="1><signature><content/></signature></object>...</package>

 >>   Dependency: signed content in/over packages. How to combine element
 >>   IDs?

If I have an XML blob with an name attribute of value 3, and package it up
with another blob with that also has a name attribute of value 3, what do I
do? Change the values? This might break a pre-existing signature.

 >>   Dependency: how to show the relative relationships of package parts.
 >>   For example, how to include XML content with stylesheets and related
 >>   resources used for rendering.

Assume people want to securely package an XML document and its style sheet
together in a package, sign it, and send it off. How do you prevent the
following? A bad guy packages an XML document with a nice style sheet that
is identified by URI.nice. However, within the XML document itself, there is
a reference to a style sheet found at URI.evil. The signature/trust
application sees that URI.nice is a trusted URI and that the style sheet is
a safe one, and hands that package off to the XML parser/renderer. The XML
application finds a reference to URI.evil in the XML document and uses that
to render the document "maliciously." Who's responsibility is it to make
sure this doesn't happen. The package application? The user application?

_________________________________________________________
Joseph Reagle Jr.   
Policy Analyst           mailto:reagle@w3.org
XML-Signature Co-Chair   http://w3.org/People/Reagle/

Received on Friday, 17 September 1999 17:25:57 UTC