Victoria FTF Minutes Available

Please review and send correcttions/suggestions (if you were there) or
comment on the proposals (if you weren't).

http://www.w3.org/Signature/Minutes/000420-Victoria/

   [1]IETF [2]W3C

      [1] http://www.ietf.org/
      [2] http://www.w3.org/

                 [3]XML-Signature FTF 20 April 2000 [[4]ascii]

      [3] file://I/Overview.html
      [4]
http://www.w3.org/Signature/Minutes/000420-Victoria/Overview.html,text

Participants

     * Mark Bartel, JetForm Corporation
     * John Boyer, PureEdge
     * Mariano P. Consens, University of Waterloo
     * Donald Eastlake 3rd, Motorola
     * Barb Fox, Microsoft
     * Mack Hicks, Bank of America
     * Gregor Karlinger, IAIK
     * Brian LaMacchia, Microsoft
     * Joseph Reagle, W3C
     * Ed Simon , Entrust Technologies Inc.
     * Raghavan "Rags" Srinivas, Sun
     * David Solo, Citigroup

Session I: David Solo (tweaks by Eastlake and Reagle)

  Document Updates

     * IOTP documeents are expected to issue shortly as informational
       RFCs including the DOM-HASH document (will be RFC 2803) which
       defines a combined canonicalization and hashing.
     * Last Call comments/C14N/XPath
     * Syntax and Processing - Last Call ended, obviously dealing with
       comments, then should do another draft for WG and reviewer
       consideration

  XPATH

     * Draft essentially done.
     * Draft coordinated with XSL WG; outstanding issue is representing
       characters with a character code value less than 16 (i.e., CR &NL)
       with one byte or two bytes (0D or D). Consensus was to follow the
       W3C C14N draft and suppress leading zero (i.e. one byte)
     * Agreement to generally not be bound by the W3C C14N serialization
       (especially with reference to namespaces) although allowed as an
       option. Expectation that W3C C14N may align with our
       specification.
     * Does it have to be a document (single root element)? Limitation is
       can't handle a list of elements. Agree to replace "document" with
       "element" in draft.

  C14N

   Management: XML Syntax WG handed off to core WG. C14N is a lower
   priority item and may take a while. Question as to whether we take
   over C14N/serialization draft. Namespace C14N (rewriting problems)?
   Fragment wrapping? Should we have multiple drafts? For processing
   signedInfo, do we expect XML processing or do we allow a "simpler"
   handling. Phil Hallam-Baker claims security issues. Kent concerned
   about having to implement something non-standard - parsers don't
   currently provide raw character stream access necessary to deal with
   "minimal C14N".

   There are likely to be multiple environments, some where parsers are
   prevalent, but perhaps others with more of a messaging orientation
   where simplified processing is desired or where tools aren't
   available. Should the specification still support both cases (and both
   serializations) and allow application environments to specify?

   Perhaps issue is minimal and full C14N are both mandatory. Is there an
   environment in which minimal is both necessary and appropriate?

   Poll: (note: Full C14N assumes a "repaired" C14N draft that meets with
   our satisfaction)
     * Who would like full C14N to be only method: Yes-6/No-5
     * Who would like full C14N to be REQUIRED and minimal be OPTIONAL:
       Yes-11/No-0 . Add language about support for minimal (or other
       similar C14N algorithemss relating to security concerns (entity
       references; DTD linkage; spoofing through comments with SignedInfo
       tag)).

   Idea from Mark Bartel that signers wanting lightweight processing
   model should just always produce and (expect to) consume fully
   C14N'ized XML. Widespread support for this model

   David Solo to draft paragraphs.

   Should we change 4.3.1 to default to Full C14N?: Yes.

    Fragments

   How to wrap a list of elements/attributes to create a single element
   -> How to take the output of XPath and create valid XML. If the output
   is not proper XML, should it be an error? No, but next processing step
   may generate an error. New C14N/serialization spec will work on any
   node set.

    Namespace rewriting

   C14N of namespaces. Renaming labels is a problem John will propose a
   solution for (probably don't do any label changes). Is there such a
   thing as a normalized NS?

   Perhaps separate charset normalization from other C14N/serialization?

    Character normalization

   Proposal to remove character representation issues from the C14N spec
   A second optional, unspecified transform for references to perform
   charset normalization could be defined later since no charset
   representation/composition normalization need be applied to
   signedInfo! C14N will still do UTF8 encoding. Maybe just a URI issue
   within signedInfo? No, because draft says use UTF-8 for URIs and then
   escape all non-ASCII characters that result. Question about
   recommending "normalized form C" for UTF-8 (always compose characters)
   because its relatively easy to create, but hard to convert.  Need to
   run this by the I18N group.

   Recommendation: Remove general charset representation from C14N A
   future transform could address UTF8 conversion to normalized form C.
   C14N will still do UTF-8 conversion Recommend documents use normalized
   form C (already a W3C guideline) with early normalization and W3C
   character model; including SignedInfo.

   John Boyer will take on editing of C14N spec and propose
   recommendations for fragments and namespaces.

   Reiterated document should not talk about invalid and un-verifiable
   signatures. Left to the individual implementation.

   Problem raised by FSML regarding what happens if I have multiple
   signed documents with colliding IDs that I want to merge into a single
   signed document. Answer: if you have this problem, then you should be
   able to generate unique IDs. Please post examples to list where this
   solution is not satisfactory and how the Signature WG can easily
   remedy the problem.

Session II: Ed Simon (tweaks by Eastlake and Reagle)

  Key Info: Last Call Issues presented by Barbra Box and Brian LaMacchia

   KeyInfo mandatory to recognize, optional to include; KeyValue
   mandatory, X.509, PGP optional. KeyInfo is a "hint" to get the right
   public key for validation.

   Past issues that are now non-issues:
     * Key Value: Trust Managements Issue
     * Key Value: Semantically Neutral
     * DSA Parameters

    X.509 Data Choice

    1. Fix the schema to support X.509 data choice
    2. Need comment to say if you are enclosing multiple pointers to the
       same certificate, they should to in the same <X509Data> element.
       Pointers to different certificates should be in different
       <X509Data> elements. Barb Fox will fix draft text.

    Retrieval Method

     * Have <RetrievalMethod> specify location, method, and type info.
     * We need to specify a number of retrieval methods. Barb Fox will do
       this. A <RetrievalMethod> type that returna a <KeyInfo> element
       was proposed and agreed to.
     * Schema will allow both <X509Data> and <RetrievalMethod> elements
       to be specified in a <KeyInfo> element.

    Codings with KeyInfo

     * Need to define encoding issues for integers, bitstrings. Brian
       LaMacchia pointed out a number of <KeyInfo> attributes that need
       to be added (see <link to slides>). Brian and Barb will re-draft
       for May 1st.

    SPKI

     * Cal Ellison wants an <SPKIData> element. Consensus was to add but
       let SPKI WG decide schema for that element.

Session III (13:00): Donald Eastlake (tweaks by Reagle)

   Karlinger: Eastlake to fix 7.1 re XML 1.0 whitespace.

   Internationalization: It is suggested that we change Transforms to
   TransformList, SignatureProperties to SignaturePropertyList, etc., for
   easier understanding. Participants appreciate concern but consensus at
   meeting is not to change due to existing examples and code.

   XPath Identifier: To simplify the embedded siganture case, create an
   algorithm identifier defined to do the equivalent of an XPath
   expression that elininates the signature value of the signtaure it
   appears in. [Later investigation indicated that it may not be possible
   to do this with a generic XPath expression but an example can still be
   given.]

   MimeType/Charset/Transfrom processing model. Martin Durst comments...
   Consensus: drop attributes and provide as parameters to transforms
   that need them. Eastlake to draft a new version of 4.3.3.1.

   Conseus to Drop Quoted Prinable. It appears not to perform any
   function which could not be met with entities.

   Syntax for open content: Instead of ANY or #PCDATA use %Object.ANY so
   content can be externally defined.

   Consensus to state that if section 7.1 syntax constraints are
   followed, a validating pareser is not needed.

   Is Schema or DTD normative? Schema should be normative.

   XSLT: Leave in XSLT Transform. Comment that if output is going to be
   digested, it should be canonicalized first.

  13:45 - Interoperability

   Reagle: need implementations. Can do on list or have web or other
   automated interface.

   On the need for test vectors and interoperability cases. A complete
   matrix is probably not needed for a while if multiple people on
   different platforms bang on it.

   People waiting for CR, but should start in the meantime (sending
   examples to the list).

  13:55 - Calendar

     * W3C Canonical XML draft - Boyer to discuss with Reagle.
     * Key Info - new text by May 1st.
     * 4.3.3.1 - new text by May 1st.
     * Lastest Schema - before May 12th (when Joseph goes to Amsterdam)

  14:00 - Adjourn




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

Received on Friday, 28 April 2000 11:26:18 UTC