XML Signature WG

99-December-16
Chairs: Donald Eastlake and Joseph Reagle
Note Taker: Joseph Reagle [text]

Participants

• Donald Eastlake 3rd, IBM
• Joseph Reagle, W3C
• Mark Bartel, JetForm
• Ed Simon , Entrust Technologies Inc.
• John Boyer, UWI
• Barbar Fox, Microsoft
• (regrets) Richard Himes, US District Court of New Mexico
• (regrets) David Solo, Citigroup

Review of Outstanding Action Items

• ...

Status of documents < 5 minutes

• Reagle editing, will post something be end of week.

Signature Syntax & Processing draft questions:

1. Renaming ObjectReferecne to Reference

   Telecon: ok. RESULT: ObjectReference --> Reference.

2. Grouping repeating elements (ObjectsReference inside SignedInfo).

   Telecon: Not very strong opinion: people not strongly opposed (but concerned about potential bloating) nor strongly in favor (though should provide cleaner in exposition). RESULT: Change to  Solo's suggested "References".

3. When Object is used for data (as specified in the Type attribute), do not include start/end tages in hash and auto-decode per any Encoding attribute. (If 5 and 6 below are adopted it might be possible to drop the Type attribute on Object and use it only for data, or change to a MimeType
   attribute or the data, which is what it was earlier. Currently the Type attribute is used up to distinguish between data/manifest/package/signatureproperties.)

   Eastlake: this would make the type reference in manifests mandatory.

   Simon: would like an attribute that says whether you want the container tags or not.

   Reagle: what happens if you have a ::child() and a reference with a strip="" attribute? Telecon: The application would strip the object, then find the child (basically take the granchildren of Object).

   Reagle: If our concern is referring to manifests, just use an ID in the Manifest element and refer to that! Concerns about moving an encoded object from within an object to elsewhere would be more tricky. Boyer: wrote an email to Himes on how to do this, will send to list.

   RESULT: no change, but clarify text that references can ref to Manifest directly.

4. Permits Object(s) inside SignedInfo.

   Might make the signature more compact, but might complicates things with respect to understanding how to process (flexibility = complexity). RESULT: no change.

5. Pull Manifest/Package up to the level of Object.
6. Pull SignatureProperties up to the level of Object.

   Eastlake: removes extra level of nesting.

   Reagle: likes to keep an Object as the bucket to place non-core syntax and semantics.

   Fox: wants a strong reason for us to make a change.

   RESULT: no change, but add some text that manifests and signature properties can appear anywhere the paren'ts content model permits; the signature content model only permits them in Object.

7. Accomplish 2 and 4 by using the existing Mainfest element.

   RESULT: no change (given above).

8. Proposed Comments text.

   Eastlake and Simon talked on list. If text is agreed to, will be sent to editors.

   Reagle: We still need to adopt a minimal canonicalization anyway (should we adopt Simon's?) Simon: wait till January.

   Bartel: we could add a summary to the c14n algorithms on how they treat comments and PIs.

9. Plenary discussion of attribute ordering.

   Need text on XPath ordering, c14n order seems to be the way to go. Boyer will send reagle text for inclusion.

Face to Face meeting arrangements < 10 minutes

• Meeting is in SanJose on the 21st, further logistics should follow within a day.