XML Signature WG

Participants

Reference Documents:
- http://www.w3.org/1999/08/xmldsig-requirements-990820.html
- Drafts/xmldsig-scenarios-990818.html
Resulting Document:

Requirements Going to Last Call shortly.
FTF details/confirmation.
Canonicalization (should reagle collect and send comments and start discussion?)
Status of scenarios?
Discussion of Syntax proposal, how to create a first draft prior to FTF?
Data Model (Reagle should have a data model proposal by tomorrow)Open: Working Group

Seem to have convergence in that manifest is merely one case of some object that you are signing. For packages and manifests, we define additional constraints, other XML content is processed according to c14n, scripts, or XSLT, for encoded content, it's still XML just CDATA.
Should keyinfo be part of the signature? David: The goal should be that having it outside gives you the option of not having to have it part of the signature (For instance, the key has some ephemeral type of information not relevant to that signature (like email addresses in PGP.) Lamachia: that keyinfo might be carried by the protocol, and known by the application
Removing selections of XML. Should the ability to preclude sections be a mandatory to implement feature/requirement of selection/c14n. Peter Norman is proposing a dsig:element by which it can be inserted into XML and reference a section but ignored by the signature c14n algorithm.

Everyone should have a look at the latest. Himes proposed two more (How to sign the binary form of an encoded attachement, and how to protect against the collision ID of combined XML in a package.)

Reagle will post graph and explaination tonight, should post resulting syntax tomorrow. Work with Solo into integrating it into that proposal.