San Jose XML Signature Notes [ascii]

Chairs: Donald Eastlake 3rd, Joseph Reagle Jr.
Author: Joseph Reagle Jr.

Attendees


9:00 AM Status, Changes to Agenda, etc.

Requirements document has been approved by the IESG except that it needs an Author's Address section and a one sentence Security Considerations section added.

There were no agenda changes.

9:10 AM W3C XML Canonicalization document

ACTION: Simon and Schaad to prepare a draft Signature WG report on Canonical XML by end of first week of February.

9:40 AM XML DSIG Implementation Experience & examples

Petteri Stenius: RPX Signature, Implementation of an XML Signature component [Slides]

Ed Simon, XSLT and XMLDSIG engines.

10:40 AM Break

11:00 AM Initial discussion of main points of contention

Manifest Syntax: Why are the Objects and References specified as they are? Do you always nee d a Ref? Can you just have two Objects? Is order important?

Eastlake: the purpose of the Manifest was to: 

  1. Defer digest validation
  2. Syntactical abbreviation for lots of signatures.

WG agrees: Move to (Ref*). (There is no need to include Objects within a Manifest w here they could just be directly referenced from SignedInfo.)

Introducing Signature Semantics:

Types

KeyInfo

Explicit algorithm parameters

NOON Lunch

1:00 PM Further discussions on Sections 2, 3, 4, and 5

IDREF

  1. Stop using IDREFs and permit people to put arbitrary expressions (e.g., "#expression") in their URI, but note that if they want to do it wel l, they should do it in a transform.
  2. Keep with what we have.

Transforms

WG very uncomfortable with the latter as it places sender specified behaviors upon the receiver that might be ignored regardless. (Similar to problems related to "criticality" in other security applications. Hallam-Baker: jokes that this would permit people to replicate "criticality fields" by specifying transforms via some URI that the receiver might not understand, and consequently can't process the signature.)

Boyer wants to define a set of documents that when combined with a set of transforms yields the same target content (TC).

X --T1--> TC
X'--T1--> TC

but not where some other document the originator never intended, when combined with some other transform yield the same target content.

Y--T2-->TC

For example,
A, B, C --(Select second)-->B
C,A,B,Y--(Select third)-->B

(In particular, Boyer wants to ensure that the permitted/signed transforms can be exclusive, removing content from an existing document instead of adding to it.)

Most want the semantic to be "this is what I did" and do not favor sender based requirements. Boyer want this to be a specification of what receiving applications MUST do. Reagle: option to write minority opinion as we move forward.

3:20 PM FAQ/Scenarios

4:30 PM Upcoming conference calls and meetings