W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > July to September 1999

990923 Minutes (More on Closure)

From: Joseph M. Reagle Jr. <reagle@w3.org>
Date: Thu, 23 Sep 1999 16:42:38 -0400
Message-Id: <3.0.5.32.19990923164238.04211e20@localhost>
To: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
Corrections and additions are welcome

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

                     [1]IETF [2]W3C   [3]XML Signature WG
                                       
  99-September-99
  Chairs: Donald Eastlake and Joseph Reagle
  Note Taker: Joseph Reagle [[4]ascii]
  
Participants

     * Donald Eastlake 3rd, IBM
     * Joseph Reagle, W3C
     * Ed Simon , Entrust Technologies Inc.
     * Todd Vincent, GSU
     * Peter Norman, FactPoint,
     * Mark Bartel, JetForms
     * 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-instruction(
       [@type="begin"][@id="1"])
         and
       ancestor-or-self::node()/following-sibling::processing-instruction
       (@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.

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/990923-tele,text
   5.
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/1999JulSep/0312.html



_________________________________________________________
Joseph Reagle Jr.   
Policy Analyst           mailto:reagle@w3.org
XML-Signature Co-Chair   http://w3.org/People/Reagle/
Received on Thursday, 23 September 1999 16:42:29 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:07 GMT