Minutes of 990909-tele

Please comment or send me corrections.

http://www.w3.org/Signature/Minutes/990909-tele.html
 
Participants

     * Donald Eastlake 3rd, IBM
     * Joseph Reagle, W3C
     * David Solo, Citigroup
     * Ed Simon , Entrust Technologies Inc.
     * Todd Vincent, GSU
     * Peter Norman, FactPoint,
     * Mark Bartel
     * Barb  Fox, Microsoft
     * Paul Lambert
     * (late) John Boyer, UWI
     * (regrets) Richard Brown, GSU
       
Notes:

     * Reference Documents: 
          +
     * Resulting Document: 
          +
       
  Review Outstanding Action Items
  
     * URI versus XLink in core/manifest syntax.
     * Other core syntax questions
     * Canonicalization algorithms
     * Status of "scenarios" document?
     * Status of "requirements document?
     * Status of Data Model document?
     * Interoperability scenarios
       
   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.
     * 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.
     * 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.
     * dsig one-pass-processing: get feedback to people on implementation
       side as to whether this is useful. (not clear that there is
       additional utility.)
       
  Agenda and Open Issues
  
    URI versus XLink in core/manifest syntax, c14n,
    
     * Solo and Eastlake: extraction is part the core signature syntax
       though optional.
     * Reagle:proposal: punt all Xptr and XSLT to the manifest, limit the
       core syntax to encoding and c14n. Use URI or local fragmentID.
     * Group :No one opposes, Solo says that it seems ok.
     * 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.
     * ACTION BOYER: write proposal on extraction/selector XPtr subset
       syntax.
     * Norman: This thread is similar to that captured in [6]Don's latest
       response on use of exclude tags.
     * Consensus: we need the syntax for our XPtr extraction, so if we
       can do it and do it fast, maybe it'll go in the core, otherwise
       lets plan to make it part of the manifest spec.
     * Reagle: We may need to look to something else if the DOM
       dependencies become too great, but for now, lets push forward with
       this. (Agreed by WG).
     * Ed Simon: has looked at James Clark implementation, will write up
       his proposal. When c14n the prologue and whole document from UTF-2
       to UTF-8. ACTION SIMON: will send up something today with the
       issues he is encountering.
       
   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.
       
    Status of scenarios document?
    
     * Probably advance as NOTE.
       
    Status of requirements document?
    
     * ACTION REAGLE: Respond to [8]Don's comments on RD, tweak for
       changes in work and post a new version to list before advancing to
       Information RFC and such.
       
    Status of Data Model document?
    
     * The core will need a very simple data model. The more extensive
       data model of the manifest package will be captured in the
       Manifest/Package XML Application 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.
       
    Interoperability scenarios
    
     * Eastlake: we need to think up a couple of scenarios, 5 or 6
       scenarios. Don't need to have the results published, some may not
       mind. Participants should write up experience and confusing areas
       of the specification.

References

   1. http://www.ietf.org/
   2. http://www.w3.org/
   3. http://www.w3.org/Signature/Overview.html
   4. http://www.w3.org/Signature/Minutes/990909-tele,text
   5. http://www.w3.org/Signature/Minutes/Irvine-Minutes.html
   6.
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/1999JulSep/0256.html
   7.
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/1999JulSep/0256.html
   8.
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/1999JulSep/0257.html



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

Received on Thursday, 9 September 1999 13:59:52 UTC