XML Signature WG

99-October-21
Chairs: Donald Eastlake and Joseph Reagle
Note Taker: Joseph Reagle [ascii]

Participants

• Donald Eastlake 3rd, IBM
• Joseph Reagle, W3C
• Mark Bartel, JetForm
• John Boyer, UWI
• David Solo, Citigroup
• Peter Norman, FactPoint
• Ed Simon , Entrust Technologies Inc.
• Barbara Fox, Microsoft
• Todd Vincent, GSU
• Rich Himes,

Review of Outstanding Action Items

[The status of these issue will be addressed in tomorrow's author call.]

• 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.
• Do we include or exclude the Object tags in the digest. continue with excluding such that the signature passes for an object or an external resource. ACTION Solo: reflect in his edit.
• 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 *?
• Solo: This section [KeyInfo] is presently heavily under specified. Add a comment that it requires significant additional work. ACTION Solo: will add ANSI reference if he can find it.
• ACTION Simon: beginning thinking about the "normative" example such that we can test resulting signature values generated from different applications.
• ACTION Reagle: create document that covers syntactical, default, and algorithm/parameter conventions such that (1) we come to agreement and (2) the document has consistency.

Agenda

Signature Syntax & Processing draft questions:

• Status
  Posted W3C TR and Internet-Draft, will try for another update on Friday.
  Internet-Draft is linked to IETF Charter page. Brown Draft will be unlinked from IETF Charter page but copy on W3C web site will remain.
• Syntax of algorithms - < 10 minutes
  • Parameter/Value elements?
  • Handling signature result.

  Sentiment on call is AGAINST having a general Value element but instead having SignatureValue and DigestValue elements that (of course for signature but also for digest) are not nested inside the SigntureXxx or DigestXxx elements.
  Mark agrees with David's present sort of syntax described above.
  People propose .
  On parameters to functions, sentiment favored a Parameter element with a Type URI attribute, algorithm specific in most cases. On having an Encoding attribute in Parameter, most felt that the encoding could be fixed for a particular Algorithm and parameter type.

  Norman, people should be able to define an encoding, but we shouldn't enforce it on people. (optionally optional) That is, while an encoding attribute can syntactically be present, only algorithms that need that flexibility would pay attention to it.

  ACTION: Eastlake will represent the position on the list.

• Null Canonicalization - < 5 minutes
  Drop it?

  Eastlake: Remove the syntactical "null" but if it isn't present, then don't touch the bytes. Sentiment FOR dropping Null but want very clear language.

• Syntax for items eligible to be attributes - < 10 minutes
  IE, how do you decide if something is to be an element or an attribute?

  Eastlake: if something needs to have content in it, then it must be an element. Also attributes get white space normalized in certain circumstances. URI could always be placed as an attribute.
  No disagreement with placing things which are always syntactically IDs, IDREFs, URIs, XLinks, or MIME types in attributes.
  Need more thought on how to deal with something (data type) that might be a MIME type or URI. These are distinguishable (scan for / or :, if you get a / first it's a MIME time, a : first, it's a URI) and syntactically fine as attribute values but it is a bit messy.

• Transformations - < 10 minutes
  One Transform element or multiple Generic/Canonicalize/XSLT/etc. elements?

  An advantage of different elements is that different attribute defaults could be specified for them; however, people favored a single Transform element, for simplicity and uniformity, which has a Type attribute to indicate what algorithm it is and optionally additional parameters.

  Reagle wants the ability for others to include externally qualified-name elements so that it will be extensible.

• Type/charset - < 10 minutes
  unnecessary? option input? passed along?

  Eastlake: will put options on list to the degree that transforms are passed along.

  Norman: (only person on con call supporting type data passed along the transformation chain, for flexibility for runtime determined types, generic type dependent algorithms.) Further support for that proposal will come from people on the list.

  Eastlake: does anyone object to type/charset info as option attribute input to algorithm? This also allows use of generic type dependent algorithms but with static type input. (no objection)

• KeyInfo - <10 minutes
  Who will do draft of next level of detail? Should recipient identification information not necessary to key agreement be provided for?

  Eastlake: This section needs substantial more work and some decisions. For instance, should we have information that identifies the recipient?

  Since the entire element is optional, there was a question as to whether any particular content could be mandatory. People leaned towards making support of an opaque key identifier mandatory if KeyInfo is implemented.

  Making X.509 certificates or anything else requiring ASN.1 mandatory was reject but use of such certificates is so common that an optional standard interoperable syntax for including them needs to be specified.

  Allowing recipient identification information not required for key agreement in KeyInfo was rejected. If desired, it should be elsewhere, perhaps in some Object; however, since user specified KeyInfo content elements will be permitted, someone can do this if they really want.

  Fox: will volunteer to write a paragraph on some of this.

  WG: this is a tricky issue, we don't want to place key info and cert issues on the critical path.

  Eastlake: we probably need to work on KeyInfo for a while, talk about it, and do what we can in the time given.

• Object/Manifest/Package/Attributes. - < 10 minutes
  • Are the later three always inside an Object?
  • Should we define "Signed"Attributes?
  • If so should we define a signing time attribute?

  Don't really mean "Attribute"s in XML sense but signature properties like signing time or serial number of crypto hardware used. Must pick a different name like Properties...

  WG continues to agree to place these things in the content of an Object tag. Create an auxillary syntax part of the document where we can place these things.

• Other open issues
    vocabulary: non-repudiation

Some objections to this term. "Technical non-repudiation" suggested to avoid possible confusion with legal, business, etc., uses of the term.

Boyer: Suggest "Author Authentication"

Not resolved but lead to a discussion of having definitions in Syntax document. Those on call favor definitions at the end, generally opposed to having them at the beginning, and perhaps neutral on having them in sequence when the word is first used.

ACTION: Reagle send Eastlake minutes. Eastlake will augment and send back out.

ACTION: Fox will send paragraph on KeyInfo to Eastlake.

ACTION: Todd will send his rough definitions to the list.

ACTION: Authors will call each other at 11 tomorrow to generate a last minute draft.