IETF W3C   XML Signature WG

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

Participants

Status of documents < 5 minutes

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 to cover both terms.

    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. [The magic phrase is "a well-formed external general parsed entity", a phrase which occurs in the XSLT Recommendation <http://www.w3.org/TR/1999/REC-xslt-19991116>.]

      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, doubt we will need this level of formality.

    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
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).