XML Signature WG

Participants

Issues from Irvine FTF:

Boyer: we use the "<?" at the beginning of the document to determine the encoding, but what if we only have a part of an XML document? Reagle: good question! Boyer raises point that if the canonicalizer strips out the DTDs, you won't know which attributes are IDs anymore. Another good question. ACTION REAGLE: wrap this up into the DOM/XPtr issues email with help of Boyer.
Vincent: we need a good way of binding the XML, style sheets, schemas, and DTDs. For instance, was the URI of the style sheet referenced in the manifest with the URI of the XML document, the same URI that is actually in the XML document? Group members may work on a paper addressing the legal issues of this and potential package requirements but not critical path.
Fox: will XML content be too small (too little entropy) sometimes (particularly if signature is also over siginfo, pretty static information) in order to permit a dictionary attack, do we need padding and salt? Solo: jokes XML is never small. ACTION FOX: talk to crypto-weenies. (Also see Re: Minutes of 990909-tele)
Solo: one-pass-processing: get feedback to people on implementation side as to whether this is useful. (not clear that there is additional utility.)

Solo and Eastlake: extraction is part the core signature syntax though optional.
Reagle:proposal: punt all Xptr and XSLT to the manifest, limit the core syntax to encoding and c14n. Use URI or local fragmentID.
Group :No one opposes, Solo says that it seems ok.
Norman: if that content is only available from a DOM, that means some things have already been lost and you can no longer NOT canonicalize it. Implication: If you want to use XPtr and get content returned through DOM that means you can't do null-level canonicalization. (Does using XPtr necessarily imply you are getting data through the DOM? Perhaps not.) ACTION REAGLE: confirm if this is the case.
ACTION BOYER: write proposal on extraction/selector XPtr subset syntax.
Norman: This thread is similar to that captured in Don's latest response on use of exclude tags.
Consensus: we need the syntax for our XPtr extraction, so if we can do it and do it fast, maybe it'll go in the core, otherwise lets plan to make it part of the manifest spec.
Reagle: We may need to look to something else if the DOM dependencies become too great, but for now, lets push forward with this. (Agreed by WG).
Ed Simon: has looked at James Clark implementation, will write up his proposal. When c14n the prologue and whole document from UCS-2 to UTF-8. ACTION SIMON: will send up something today with the issues he is encountering.

Reagle post-facto thinking: It seems we are toying with a couple of variables with respect to extract, Xptr, DOM, and core versus some other spec.

Reagle wants to keep the core small and easy since we need to start implementing in about a month's time. Argues for removing Xptr/extract to manifest level and only permitting simple URIs at the higher level.
Solo wants symmetry between the signature reference and manifest reference, such that one could use either without the signature breaking. This argues for core and manifest references to look alike.
Boyer wants the ability to force the client to validate the thing actually being signed. You can only do this by placing it in the object. If you place it in the manifest, its up to the application to decide what to validate, Boyer lost his ability to define what is critical. (Reagle reconsiders the idea of flags in the manifest which state whether the resource needs to be checked or not so as to achieve point 1.) Also, if you reference the actual resource (instead of a manifest) in the object, then you naturally need Xptr to extract from it, which conflicts with point 1.
Don's doesn't seem to think exclude tags are out of contention.

ACTION REAGLE: Respond to Don's comments on RD, tweak for changes in work and post a new version to list before advancing to Information RFC and such.

The core will need a very simple data model. The more extensive data model of the manifest package will be captured in the Manifest/Package XML Application document.
Eastlake: I was calling the document the "auxiliary document" in contract to the "core". Reagle, I think the Manifest/Package should be its own little XMLspec with a namespace.. Is there going to be a separate Processing Rules? Lets finish writing them up and then figure out where they go.

Eastlake: we need to think up a couple of scenarios, 5 or 6 scenarios. Don't need to have the results published, some may not mind. Participants should write up experience and confusing areas of the specification.