000817 Draft Minutes

Please send discussion/corrections to the list.

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

                     [1]IETF [2]W3C   [3]XML Signature WG

      [1] http://www.ietf.org/
      [2] http://www.w3.org/
      [3] http://www.w3.org/Signature/Overview.html

  2000-August-17
  Chairs: Donald Eastlake and Joseph Reagle
  Note Taker: Joseph Reagle [[4]ascii]

      [4] http://www.w3.org/Signature/Minutes/00817-tele.html,text

Participants

     * Donald Eastlake, Motorola
     * Joseph Reagle, W3C
     * Ken Goldman, IBM
     * Brian LaMachia, Microsoft
     * John M. Boyer, PureEdge
     * Merlin Hughes, Baltimore
     * regrets: Ed Simon , Entrust Technologies Inc.

  Status of documents < 5 minutes

     * Requirements - Informational RFC
     * Syntax and Processing - awaiting C14N resolution, Enveloped and
       X509Data issue should also be resolved.
     * Canonicalization - finish substantive issues, prepare the Last
       Call Issues document, then ask to go to CR

  Canonicalization < 15 minutes

     * Namespaces
       Not sure what is meant. When URI=#X, what is the namespace context
       that is also be transferred? One application may do something,
       another may do something else.
       Extraction needs to dump all the namespaces of the original
       document into the transformed one.
       Boyer: are we in control of how the fragment is resolved? Reagle:
       The MIMEType defines what it means, but we can define what the
       meaning means for our application.
       LaMachia: concerned about efficiency, how many times will I have
       to do c14n?
       Eastlake: you don't have to do all of it, you could just
       proprogate the namespaces in the resulting octects/xml.
       Boyer: Transforms that can take an octect stream as input, and
       those that take an nodeset.
       LaMachia: two types of transforms: (1) c14n for nodeset to octects
       (2) parser for octects to nodeset.
       Reagle: they are different, in that in the xml transform, you
       might have your original xml parsing context.
       Boyer: can't run the enveloped transform as the fourth.
       Reagle: so this is what we are looking at, for each of the URI
       and/or transform you sign:
         1. URI="foo.xml" sign octects returned in HTTP
         2. URI="foo.xml#bar" Transform="c14n" parse octects, select, and
            c14n
         3. URI="foo.xml#bar" meaningless
       Merlin: what about going back to the clean-URI and not permitting
       #xpointer in the URI?
       Boyer: we already considered that ... but we didn't have our
       processing model as clean, so it is an option.
       Reagle: However, this would probably counter are changes that
       addressed Dan and Martin's comments and isn't necessary.
       Introducing the fact that there might be two types of transforms
       doesn't necessitate moving to clean-URIs, but it re-opens the
       possibility.
       Eastlake: if we know its XML because of a null URL with a fragment
       "#bar" that implies one transform which is canonicalization.
       LaMachia: Don, you are saying, "if a barename XPointer is present
       ("#bar") and there are no other transforms, then there is an
       implicit c14n transform"?
       [some disgreement]
       Eastlake: I'm saying, if we require explicit c14n, why not a parse
       transform then?
       Reagle: ok, whether we return to barenames, or whether there's
       implicit-explicit parse/serialize transforms is orthogonal to the
       idea that there are two types. Action Boyer: Let's let John write
       up a proposal, then discuss these issues further then.

  Syntax and Processing

     * X509Data
     * Retrieval Method
       Why not [5]remove encoding and just stick transforms in there?
       Action Eatlake: propose this to the list.
     * here() / Enveloped Signatures
       if we can include the idea of xml processing, this may be solved.
       postponed.

      [5]
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0300.html

  Other

     * Boyer: shoulding we add an XHTML transform. Motivation: sign HTML
       such that it doesn't break.
     * Reagle: sounds like a neat idea though most of the HTML out there
       is invalid so won't transform well. Regardless, this isn't
       critical path and needn't be included in the spec, but if someone
       wants to write it up and have the WG consider it being optionally
       referenced in the spec, that seems fine.





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

Received on Thursday, 17 August 2000 16:06:30 UTC