Re: Minutes of 990909-tele

From:  "Joseph M. Reagle Jr." <reagle@w3.org>
Message-Id:  <3.0.5.32.19990909135951.00b34940@localhost>
Date:  Thu, 09 Sep 1999 13:59:51 -0400
To:  "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>

>Please comment or send me corrections.
>
>http://www.w3.org/Signature/Minutes/990909-tele.html
...

>   Issues from [5]Irvine FTF:
>     * Boyer: we use the "<?" at the beginning of the document to
>       determine the encoding, but what if we only have a part of an XML
>       document? Reagle: good question! Boyer raises point that if the
>       canonicalizer strips out the DTDs, you won't know which attributes
>       are IDs anymore. Another good question. ACTION REAGLE: wrap this
>       up into the DOM/XPtr issues email with help of Boyer.

I don't think this is our problem.  If you are receiving a complete
XML document over some channel where a variety of encodings can be
used, you need the "<?" at the beginning to figure it out.  If you
have or receive a part of an XML document then you had better already
know the encoding.  A partial document where you don't know the
encoding doesn't work the way XML is defined.  This is not our
problem.  It's part of XML.

On the ID question, is this actually relavent for anything other than
fragments?

>     * Vincent: we need a good way of binding the XML, style sheets,
>       schemas, and DTDs. For instance, was the URI of the style sheet
>       referenced in the manifest with the URI of the XML document, the
>       same URI that is actually in the XML document? Group members may
>       work on a paper addressing the legal issues of this and potential
>       package requirements but not critical path.

If there are standard auxiliary documents affecting meaning that are
pointed to out of an XML document, the best thing would be a
canonicalization algorithm that incorporated the auxiliary document
into the main document so it could all be treated as a single entity.

>     * Fox: will XML content be too small sometimes (particularly if
>       signature is also over siginfo, pretty static information) in
>       order to permit a dictionary attack, do we need padding and salt?
>       Solo: jokes XML is never small. ACTION FOX: talk to
>       crypto-weenies.

As others have pointed out, a dictionary attack pertains primarily to
confidentiality which we are not doing.  But the effort to add an
optional <nonce> with ANY content seems pretty trivial.

> ...
>
>  Agenda and Open Issues
>  
>    URI versus XLink in core/manifest syntax, c14n,
> ...   
>     * Norman: if that content is only available from a DOM, that means
>       some things have already been lost and you can no longer NOT
>       canonicalize it. Implication: If you want to use XPtr and get
>       content returned through DOM that means you can't do null-level
>       canonicalization. (Does using XPtr necessarily imply you are
>       getting data through the DOM? Perhaps not.) ACTION REAGLE: confirm
>       if this is the case.

I continue to believe that a canoncialization based on DOM should be
the default.  Anyone that does processing of any significance on XML
will do something very much like parsing it into a DOM tree.  It's
fine if some people want null or minimal canonicalization but they are
not really dealing with XML, just with binary character data that
happens to be XML.  If you want to do extraction from character data,
I would think you should be using an awk script or something, not
XPointer.

> ...
>       
>   Reagle post-facto thinking: It seems we are toying with a couple of
>   variables with respect to extract, Xptr, DOM, and core versus some
>   other spec.
>    1. Reagle wants to keep the core small and easy since we need to
>       start implementing in about a month's time. Argues for removing
>       Xptr/extract to manifest level and only permitting simple URIs at
>       the higher level.
>    2. Solo wants symmetry between the signature reference and manifest
>       reference, such that one could use either without the signature
>       breaking. This argues for core and manifest references to look
>       alike.
>    3. Boyer wants the ability to force the client to validate the thing
>       actually being signed. You can only do this by  placing it in the
>       object. If you place it in the manifest, its up to the application
>       to decide what to validate, Boyer lost his ability to define what
>       is critical. (Reagle reconsiders the idea of flags in the manifest
>       which state whether the resource needs to be checked or not so as
>       to achieve point 1.) Also, if you reference the actual resource
>       (instead of a manifest) in the object, then you naturally need
>       Xptr to extract from it, which conflicts with point 1.
>    4. [7]Don's doesn't seem to think exclude tags are out of contention.

I don't think I'm pushing "exclude tags", just the idea of elements
that can, for applications that need this, be sprinkled into XML to
act as markers for use in Xpoint/Xpath/whatever extraction.

There are people who want to do really lightweight stuff for simple
protocols.  It doesn't seem reasonable that they should be burdened
with a requirement to implement XPointer.

> ...
>       
>    Status of Data Model document?
>    
> ...
>
>     * Eastlake: I was calling the document the "auxiliary document" in
>       contract to the "core". Reagle, I think the Manifest/Package
>       should be its own little XMLspec with a namespace.. Is there going
>       to be a separate Processing Rules? Lets finish writing them up and
>       then figure out where they go.

I understand that it allows separate update/evolution but I'm not sure
the complexity of an additional namespace is worth it.

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

Donald
===================================================================
 Donald E. Eastlake 3rd   +1 914-276-2668   dee3@torque.pothole.com
 65 Shindegan Hill Rd, RR#1  +1 914-784-7913(w)     dee3@us.ibm.com
 Carmel, NY 10512 USA

Received on Tuesday, 14 September 1999 09:54:55 UTC