Minutes: 00-February-03

As always, comments, correction, and discussion are welcome.

http://www.w3.org/Signature/Minutes/000203-tele

  00-February-03
  Chairs: Donald Eastlake and Joseph Reagle
  Note Taker: Joseph Reagle

Participants

     * Donald Eastlake 3rd, IBM
     * Joseph Reagle, W3C
     * Ed Simon , Entrust Technologies Inc.
     * David Solo, Citigroup
     * Barb Fox, Microsoft
     * Mark Bartel, JetForm Corporation
     * Winchel "Todd" Vincent III, GSU
     * John M. Boyer, UWI.com
     * David Smiley, Sagasoftware
     * Mike Meyers, VeriSign
     * Bill Curtain, DISA

  Status of documents < 5 minutes

     * Requirements is now in RFC-editors queue.

  Signature Syntax & Processing draft questions:

    Editorial:

    1. Remove Core from title?
       ACTION Reagle: Remove core and try to label sections as required
       versus optional better.
       Simon: someone who read the document found it to be very
       intimidating, not sure what they needed to implement.
       Reagle: we need a lot of editorial/exposition work to make the
       document read better, so if you have any suggestions or get
       comments on that note, please let us know.
    2. Signature versus Authenticator?
       There is concern that if we support secret key MACs, it shouldn't
       be called a Signature but an Authenticator.
       Eastlake: put a sentence or two up front making the distinction
       between Signature and Authenticator and say we use Signature
       generally as public key will be the common case.
       Reagle: Connolly mentioned removing the HMAC specification. Fox:
       wants to retain HMAC, as does Bartel. ConCall wishes to retain
       "Signature" but use the term carefully; no one wants to remove
       HMAC either.

    FTF:

    1. - FAQ/Scenarios.
       People should send comments. Not a normative document, but before
       we populate it with examples, we should make sure we are in
       agreement.
    2. - C14N Report
         1. character model: multiple ways of representing the character
            model.
            Presently, normalize according to character model. Simon and
            Eastlake aren't keen on this.
            Simon: They really need feedback from implementors who have
            experience, but it isn't required for security purposes --
            though is likely to be more complex.
         2. How to treat XPath results that aren't well formed XML (e.g.,
            a series of attributes, or text string or a series of
            elements without a root.)
            Eastlake: I read of a well balanced fragment somewhere.
            Simon: that was in the Fragment spec, they specified that for
            any piece you will always send enough information so it can
            be understood.
            Simon: will write that we've identified this issue though it
            is not one the XML C14N need worry about.
            ACTION Simon: will send text on both these issues today. List
            has one week to discuss before it is prepared to be sent to
            the XML working group as this group's consensus position.
    3. Interopability
       Simon: an autoresponder would be neat, but presently the
       implementations out there are just keeping up with the spec.
       Eastlake: IPSec had a big 40 vendor test.
       Simon: a little early, but important two months from now.

    LIST:

    1. - URI/IDREF
       Slight discussion similar to email disussion. Eastlake: At FTF we
       agreed to go with present exposition and see what last call
       comments were.
       Reagle: it doesn't seem this issue isn't going anywhere on the
       basis of arguing about principle. Would be useful if someone feels
       strong enough to write a "plug-and-play" proposal such that we can
       look at it and say, "yes" that makes sense.

    DOCUMENT
    [5]http://www.w3.org/Signature/Edits.html

      [5] http://www.w3.org/Signature/Edits.html

    1. (Also relates to use of entities). 1.3 General issue - the
       question was raised as to whether since the version is implied by
       the namespace, do we need to make sure the version is explicitly
       bound under the signature (it may be already, I'm not sure whether
       there's a way to include the reference to the schema/DTD within
       signed info). If not, we might need to thing about recommending
       inclusion of a reference to the signature schema in cases where
       this is a concern.  1.3 last par (security comment) I don't like
       leaving a sentence like "we haven't assessed the risk" in for last
       call. I'd suggest an explicit recommendation that if null c14n is
       used for signedInfo, then all namespaces must be fully expanded.
       [P.S. there's no 1.4]
       Eatlake: but most everyone will canonicalize and this solves both
       of these problems.
       Reagle: but we haven't been able to require canonicalization so we
       have to address this problem -- even if some of us would like
       people to canonicalize by deafult.
       Reagle: I will remove this text and add two setences for the
       benefit of those that don't canonicalize.
    2. - Need to define HMAC output lengths and define element types.
       ACTION Bartel: will suggest some changes/text.

   Eastlake: Next call on February 17th.

   Reagle: I will generate a TR/ietf-draft end of week. If we list Feb
   21st as Last Call that gives us time enough for another interim draft
   and then we can ask the WG "are you comfortable with this going to
   Last Call" (speak now or forever hold your peace).




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

Received on Thursday, 3 February 2000 15:27:02 UTC