99-October-07 Minutes

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

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

     * Donald Eastlake 3rd, IBM
     * Joseph Reagle, W3C
     * Mark Bartel, JetForms
     * John Boyer, UWI
     * David Solo, Citigroup
     * Ed Simon , Entrust Technologies Inc.
     * Todd Vincent, GSU
       
Minutes

   Review of Outstanding Action Items
     * [DEL: ACTION Bartel: send AlgID by Monday :DEL]
     * [DEL: ACTION Eastlake: propose something on URI and MIME types.
       WG: discuss. :DEL]
     * [DEL: ACTION Reagle: finish edits to RD and send on its way. :DEL]
     * [DEL: ACTION Reagle: check [5]RFC2119 to see if it defines
       mandatory, recommended, should. :DEL]
     * [DEL: ACTION Reagle: reflect these minutes in document and post by
       end of Friday. :DEL]
       
     * ACTION Fox: do we need to add a nonce? Barb still has it on her
       queue, experts are travelling.
     * ACTION Brown: send requirements and syntax comments to list. Sent
       requirement comments. Still needs to send syntax comments.
     * [DEL: ACTION Reagle: Check with everything capitalized, bounce off
       Ralph. Evidently some scripting languages don't like '_'. We
       should probably just keep what we have and move on. :DEL]
       
  Algorithms
  
     * Mark has added text to sections 7, are people generally ok with
       this? Yes.
     * Should we stop saying non-repudiation? People seem comfortable
       speaking of it.
     * Remove MD5? Agreed. Also tweak references to AES.
       
  Syntax (Jim Schaad and Barbara Fox)
  
    1. All IETF drafts now require a patent statement a the top of the
       draft. Such a statement should be added to the document.
       ACTION Reagle: Add link in W3C status to patent statements now on
       Web site. We'll add the IETF disclosure to the IETF version when
       generated.
    2. Example in section 2.0 should be a DSS example as this is the
       mandatory example. I assume that at some point this will be come a
       verifiable example as well.
       WG Agrees.. ACTION Solo: will change example, and we will
       hopefully have a verifiable example at some point.
    3. Section 3.0 -- In the ATTLIST SignatureValue is misspelled.
       ACTION Reagle Fix.
    4. Section 3.0 -- SignatureValue is no longer an empty-tag element.
       ACTION Reagle Fix.
    5. Section 3.0 - Insert reference to Base64.
       ACTION Reagle Fix.
    6. Based on input from mailing list -- please change c14nAlg as an
       element to fully spelled out.
       ACTION Reagle: move from c14n to canonicalization. In the XML
       canonicalization. Text we can keep for the time being. Bartel
       would like Alg spelled out too. No agreement -- but no opposition
       either really.
    7. Section 4.3.1 - I know that we were one of the people who wanted
       to make the location optional. What we had in mind was the
       following statement: "If the location is omitted, then the content
       being signed is the first Object in the immediate surrounding
       Signature."
       Solo's scenario is closer to what Don sent than the Fox/Sheena.
       Clarify: if omitted assumed that the application knows what to do.
    8. Section 4.3.5 - This is no longer an empty-element tag.
       ACTION Reagle: fix.
    9. Section 5.0 -- there are two DTD definitions for Object here.
       ACTION Reagle: delete second one.
   10. Section 6.0 -- The DTD appears incorrect. ANY can only occur once
       and not with any of the current defined items. Should ANY be
       inside of the *?
       Agreed. Don says one can rewrite to do it right. ACTION Reagle:
       fix it.  Solo: This section is presently heavily underspecified.
       Add a comment that it requires significant additional work.
   11. Section 7.1 -- Please remove all references to MD5. We should not
       be pushing the older potentially bad hash algorithms (after all
       MD2 is not here either). SHA1 will cover our needs until the AES
       hash algorithm comes along
       Agree: remove MD5.
       Agree: remove AES from table, include sentence that we expect
       additional digest algorithms can be used in the future.
       ACTION Reagle: Fix the table.
       Eastlake: suggests changing ECDSA to optional.
       David will add ANSI reference if he can find it.
   12. Please remove references to AES algorithms. There will be a block
       cipher finalist next year and there is no hash yet.
   13. Section 8.1
           - Step 2 - "Calculate the digest over the result of the
       transformations."
           - Step 3 - formatting on objectreference is incorrect.
           - Step 4 - space between SignedInfo/Element
           - Step 5 - references step d
           - Step f) - should be moved to step 6.
   14. Section 8.2
           - Step 6 - references steps c and d.
           - Remove last sentence of step 6 -- this would go to
       description of canonicazation.
       ACTION Solo: clarify section 8.
   15. We assume that the editorial comments will be removed in the
       process of creating an IETF I-D.
       Action REAGLE: Move most comments to open issues section.
       
  Solo: Transformation Section:
  
     * Presently underspecified. Agreed Applied in the order in which
       they appear. Can you have more than one of a particular type
       (multiple encodings).
     * Need to specify defaults: 4.1/4.3.3 alludes to defaults. 4.1 is
       probably minimal. For signed_info, let's require the element, and
       people can specify whatever they want. minimal as the default if
       not present. If the element is not present, no transformation
       occurs.
     * remove third bullet in 7.5.2 mark and ed will propose alternative
       text.
     * do we include or exclude the object in the signature. continue
       with excluding such that the signature passes for an object or an
       external resource. ACTION Solo: reflect in his edit.
     * Reagle: what requirements will we have for the transformation:
     * Ed says REQUIRED  XSLT, perhaps recommended. Though can see that
       it might be a lot for some applications.
     * John says REQUIRED XPath, perhaps recommended + algorithm.
     * Eastlake, says RECOMMENDED (XSLT | XPath)
     * If XPath, we need to have an algorithm (then encode).
       
   ACTION Boyer: will write up a proposal for 7.6 using "Recommended"
   term.

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/991007-tele,text
   5. http://info.internet.isi.edu/in-notes/rfc/files/rfc2119.txt



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

Received on Thursday, 7 October 1999 19:45:53 UTC