XML Signature WG

99-October-07
Chairs: Donald Eastlake and Joseph Reagle
Note Taker: Joseph Reagle [text]

Participants

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

Minutes

Review of Outstanding Action Items

• ACTION Bartel: send AlgID by Monday
• ACTION Eastlake: propose something on URI and MIME types. WG: discuss.
• ACTION Reagle: finish edits to RD and send on its way.
• ACTION Reagle: check RFC2119 to see if it defines mandatory, recommended, should.
• ACTION Reagle: reflect these minutes in document and post by end of Friday.

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

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/Schaad. 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.