[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

  99-September-99
  Chairs: Donald Eastlake and Joseph Reagle
  Note Taker: Joseph Reagle [4]text]

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

Participants

     * Donald Eastlake 3rd, IBM
     * Joseph Reagle, W3C
     * Ed Simon , Entrust Technologies Inc.
     * Todd Vincent, GSU
     * Peter Norman, FactPoint,
     * Mark Bartel, JetForm
     * John Boyer, UWI
     * Richard Brown, Globeset

Minutes

  Requirements

     * Brown
          + 2.3.1&2 why are the sub-headings? Reagle: groups them, but
            not necessarily.
          + 2.3.* Formal statements are somewhat confusing. Reagle:
            correct, will fix.
          + 3.2.2 A capability, not a requirement over all signature.
            Reagle: true.
          + ACTION DON: will reword and send to list.
          + ACTION BROWN: send comments to list.
          + ACTION REAGLE: tweak final time and move forward.

  Syntax Draft

    Capitalization

     * Capitalize all words and joined words.
     * Peter Norman, does RDF reserve the first letter as capitalized
       for conventions.
     * ACTION REAGLE: Check with everything capitalized, bounce of
       Ralph

    Closure

     * Peter wants to add something to the native document where he
       doesn't have control over it nor the DTD, needs to use a <?PI>
       to define the scope and ensure it will always be ignored by
       Signature applications.
          + Reagle: Let's not speak of PIs because of the property that
            they were ignored by a particular c14n algorithm. (That
            algorithm has now changed and won't ignore them.) It does
            make sense to speak of <PIs> if you need to arbitrarily
            insert some content irregardless of the content model.
     * Scenario: a document with three paragraphs, assume you want to
       sign the second paragraph.
       <root>
         <p>this is a paragraph </p>
         <p>this is a longer paragraph</p>
         <p>this is the longest paragraph</p>
       </root>
       Can use XPath ' /child::para[position()=2] '
       Now if someone inserts text resulting in a new document
       <root>
         <p>this is a paragraph </p>
         <p>new paragraph this is </p>
         <p>this is a longer paragraph</p>
         <p>this is the longest paragraph</p>
       </root>
       The signature would break. Is this a good thing or bad thing? If
       you permit something like:
       <root>
         <p>this is a paragraph </p>
       <?dsig type="begin" id="1">
         <p>this is a longer paragraph</p>
       <?dsig type="end"  id="1">
         <p>this is the longest paragraph</p>
       </root>
       and use
       /descendant-or-self::node()
       [
       ancestor-or-self::node()/previous-sibling::processing-instructio
       n([@type="begin"][@id="1"])
         and
       ancestor-or-self::node()/following-sibling::processing-instructi
       on(@type="end"][@id="1"]
       ]
       Your signature might be less likely to break.
       The breaking or keeping of the signature is a good/bad thing as
       defined by the application. Boyer's closure requirement means
       that applications have the expressitivity/power to define
       whether its a good or bad thing.
     * Am I signing a section or a transformed document? Good to think
       of this as a transformed document as [5]Tim said, "When we talk
       about signing parts of a document, then they only way I can see
       of giving meaning to this is to say that we are signing a some
       document which is not actually given, but is formed by making a
       particular transformation on the document given.... Life is then
       simplified. A signature is over a document. The document can be
       referred to, and/or enclosed, directly, or specified as a
       manipulation function. So long as both parties know how to do
       it, any function can be used. This puts the (xpath, say)
       function into a very similar position to the canonicalization
       function."
     * Don and Joseph will try to structure discussion with a series of
       poll/questions if necessary to come to "closure" on this issue
       if necessary. Otherwise continue on list.

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