Minutes from FTF 99/07/12-13

Minutes from the meeting are now available off our WG page. Please let me
know if you believe something is not accurately reflected.  Many thanks to
Peter Lipp for a nice job -- not too little, not too much, just right!

http://www.w3.org/Signature/Minutes/990713-oslo.html

               [1]XML Digital Signatures WG Meeting 99/07/12-13
                                       
   All the slides presented by any presenter are available from the WG's
   website - only relevant discussion is noted
   here.
     * [2]Reagle's Slides [[3]Notes]
     * Brown's Presentation (Similar to [4]workshop).
     * Fox and Solo's proposal (Will be posted to list shortly).
       
  Resulting Action Items:
  
     * Working Group Members to review comment
       (http://www.ietf.org/internet-drafts/draft-ietf-xmldsig-signature-
       comments-00.txt)
     * Don Eastlake/Joseph Reagle to propose a time for conference calls
       within a week
     * Don Eastlake to fix date and place for face to face meeting
     * Joseph Reagle produce another version of requirements document
       based on comments for consensus poll within 1.5 weeks.
     * Joseph Reagle to define how many documents are required and
       author/editor policy within 1.5 weeks.
     * Working Group Members to review canonicalization document when
       posted in two weeks.
     * Dave Solo to post Solo/Fox proposal
     _________________________________________________________________
   
   Date:
          July 12 1999
          
   Notes Author:
          Peter Lipp (tweaked and HTMLized by Reagle)
          
  1.AGENDA BASHING (5M)
  
   No discussion.
   
  2.JOINT WORKING GROUP STATUS (10M)
  
   This was the first meeting of the first joint W3C/IETF WG. Joseph
   Reagle (JR) and Don Eastlake (DE) presented
   the "history" of this WG. From the process point of view, regular
   conference calls are planned besides meetings at
   the IETF's and someplace in September.
   
   Paul Hoffman (PH): are those Conference and Meetings calls design or
   process meetings?
   DE: Conf.Calls for status and ad-hoc technical discussions, face to
   face for substantial work. But WG can decide.
   
  3.REQUIREMENTS (45M)
  
   Joseph presents requirements document.
   Mary-Ellen Zurko: what is meant by validity of a signature: valid now
   or court-validity.
   David Solo (DS): this is external to the draft.
   Semantics: only simple meaning - no trust semantics. Extensibility.
   Bob Blakeley: is concerned about the semantics extension mechanism.
   Those have to be protected too.
   JR: reason to push semantics out of scope: let other people define
   semantics.
   Paul Lambert (PL): concurs, push semantics off even further,
   concentrate on crypto-validity and make sure we do
   this all the way correctly.
   No specification of serialization or canonicalization:
   DE: necessary for interoperability. Need not too many of them, but not
   exactly one at least. Extensibility necessary and useful.
   Eric Rescorla (ER): options confuse security semantics.
   DE: canonicalizers can also remove information. NULL-canonicalizer
   will also be useful.
   DS: 2 places for canonicalization: canonicalization of the structure
   we create, canonicalization of the resources.
   Different. Canonicalization ensures: (a) given valid XML-document -
   produce single strong-representation (b) defer
   unique string-encoding for semantic value represenation.
   Bob Blakeley: Canonicalization algorithm must not be able to
   manipulate content. NULL is fine, others might not
   be. Constraints required - guidelines.
   ER: Canonicalization algorithm must be included into the signature.
   XLink: JR: XPointer provides for alot of ambiguity.
   PH: be explicit about if the thing some XLink points to is included
   within the signature or not. Ambiguity!
   ER: Iffy proposition to allow different Canonicalization-Algorithms
   with different security properties. Users don't
   see the difference - see key-symbol in Netscape for SSL. Programmers
   make mistakes like that too.
   DS: suggest to profile XML for use in browser to restricted choices
   but not generically. Application problem.
   PH: profile XLink/XPointer is fine, XPointer itself too generic
   Implementation Philosophy
   JR: do you want OID's? DS: unambiguous way to say what we mean (either
   URN or OID)
   Ryan Boats ATT (sp?): Michael Meally, NSI has done some work on URN's
   for OID's
   Crypto:
   Specify a few mandatory algorithms for interoperability
   PL: why have key exchanges and push of encryption? Controversial
   requirements
   Richard Brown (RB): no redefinition of these schemes. If people use
   DH-credentials they shall be able to use it (also
   for other symmetric stuff)
   PL: different properties for different algorithms. This is a slippery
   slope, maybe better move into separate
   documents.
   DE: gets nervous by hearing "management" or "negotiation". Just by
   allowing secret keys - maybe call it something
   else than a signature.
   RB: we need to provide people with a solution, like UOTP has symmetric
   stuff in the first proposal.
   PL: the diversion of validity and trust is not clear yet. Be careful!
   Discussion about inconsistencies of info within a BLOB (such as CMS)
   within an XML-signature and info within
   the XML-structure deferred until a better understanding is aquired.
   Christopher Smithies: points out importance of packaging all necessary
   info (intention, time, id, signature) which is
   what products by Penop do. Worth while replicating some of that info
   in the outside structure.
   Coordination
   PH points out the importance of internationalization issues and
   coordination with the internationalization WG
   
  4.SIGNATURE SYNTAX (45M)
  
   JR: Brown-Draft not a product of the WG, but possible to get there.
   RB presents his proposal.
   Bob Smart: is there an option to put in the public key or only a
   reference to it using the DN?
   RB: Not bound to that. Originator info might offer different ways. One
   common way needed.
   Denis Pinkas: can attribute certificates be included?
   RB: could be accomodated within the credentials within the originator
   information section.
   Denis Pinkas: no provision to support non-repudiation (e.g. include
   timestamp)
   RB: not part of spec because not necessarily part of signature
   process.
   JR: we don't support non-repudiation
   DS: we neither support nor not support it.
   Stefek Zaba: incorporation by reference - what if hash of resource
   does not verify?
   RB: application level problem, signature verifier verifies only
   manifest signature
   SZ: this needs to go into the draft
   Presentation of an evolutionary, non-counter-proposal by DS (co-edited
   with Barb Fox)
   No attributes within that proposal.
   DE: how to stop people from putting attributes within the resources?
   DS: we don't want to stop them. An attribute is just a resource -
   uniform syntax.
   [Reagle: later, we may wish to create restrictions as to the type of
   "invasive" semantics people can introduce using namespaces.]
   ER: what would you specify from the hash standpoint?
   DE: calculation of the hash of the manifest. Calc of hash of resource
   is resource-dependent. Signature validator logic
   never verifies that
   PL: we need to touch on semantics. Multiple signatures could be
   interpreted in different ways. Must be described
   well to know what it means.
   
  5.FIRST CONSIDERATION OF CONFERENCE CALLS AND SEPTEMBER
  FACE TO FACE MEETING (5M)
  
   DS: potential partitioning of the problem-space might influence that
   decision.
   DE: suggest a meeting on the west coast for geographic diversity.
   Meeting adjourned.
     _________________________________________________________________
   
   Date:
          July 13th 1999
          
   Notes Author:
          Peter Lipp (tweaked and HTMLized by Reagle)
          
  Syntax
  
   DS presents a slide sketching a more formal version of an alternative
   syntax proposal.
   Open problems are
     * whether to allow a bag of attributes as part of ressources and
       signature block
     * keying info; could contain certificates and references to them,
       symmetric key id's, key agreement exchanges etc.
       
   Proposal will be summarized and sent to the list.
   
   Q: David Burdette: should there be defaults like a default hash or
   canonicalizer for all ressources to avoid repetition?
   ER: saving a few bytes not worth it
   Chr. Smithies: how to make clear what was within the original document
   and what has been added during the signature process
   DE: Semantics could go into the attributes
   JR: no, semantics of signatures are statements and should go into the
   resources. [Reagle hindsight clarification: properties of the
   signature of the signature itself can be considered properties, but
   the manifest attributes are a resource themself.]
   Michael Myers: should the keyinfo be a subsection of the document or
   separate document(s)
   DS: not sorted out yet
   ER: is one-pass processing planned? Would be a nice feature
   DS: not sorted out yet
   RB points out that removing attributes from this proposal we would end
   up with something quite similar to the current specification
   DE: open question if users should be able to insert arbitrary
   attributes
   Don Smith: reminds us of things we went through in PKIX; lets have
   something where people can put in things otherwise those will come up
   later anyway. Poll: no oponents.
   
  Canonicalization
  
   Joseph presents draft of W3C-XML group (not publicly available at this
   time).
   Comments to the list.
   
  Logistics
  
   Roughly 16 people would come to a September meeting. Offers available
   from Micrsoft and UC-Irvine. Suggestion Aug 30/31.
   
   Conference Calls every other week, starting in week 30.
   RB points out that there is a separate comment document, input on this
   sought.

References

   1. http://www.w3.org/Signature
   2. http://www.w3.org/Talks/1999/0712-ietf45/
   3. http://www.w3.org/Talks/1999/0712-ietf45/all.htm
   4. http://www.w3.org/DSig/signed-XML99/present/brown.ppt


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

Received on Thursday, 15 July 1999 14:28:27 UTC