Reagle's supplementary notes. These notes are not normative.
Chairs: Donald Eastlake and Joseph Reagle
- Mark Bartel, JetForm Corporation
- John Boyer, PureEdge
- Mariano P. Consens, University of Waterloo
- Donald Eastlake 3rd, Motorola
- Barb Fox, Microsoft
- Mack Hicks, Bank of America
- Gregor Karlinger, IAIK
- Brian LaMacchia, Microsoft
- Joseph Reagle, W3C
- Ed Simon , Entrust Technologies Inc.
- Raghavan "Rags" Srinivas, Sun
- David Solo, Citigroup
Status of documents < 5 minutes
- Requirements - in RFC editors que.
- Syntax and Processing - Last Call ended, obviously dealing with comments, then should do
another draft for WG and reviewer consideration
- quick clarity on semantics
- how to deal with conflicting IDs
- SPKI data
- Mariano - manifest
- should we use 0D or D, c14n spec uses D
- the manin difference between XPath and C14N is how namespace nodes is handled.
- management: should we take the editing of this spec over?
- technical - is it well formed, or a list of elements
- philosophical - are we gonna get off the fence?
Are we prepared to go the XML Toolkit route, and say this isn't necessarily the most
mature signature technology?
Simon: once you pass the content through DOM/SAX, you loose a lot of the information
that minimalization wanted to preserve.
Consens: FSML is using a minimal canonicalization. Environments where a parser is not a
given. Not forcing one to work at the DOM level should still be an option.
Simon: what if you put it in a comment, you need a parser or you end up with security
Solo: is there an environment where minimal might be useful?
LaMacchia : whether this is from the creator or signature?
Minimal is required, do we make it optional. Yes: move C14N as required, minimal as
optional. Focuss efforts on toolkits, and verifying those.
Bartel: don't use full canonicalization, simple implementations should just consume and
generate the output of what would look like c14n XML. (Canonical XML Form).
Fox: we are not discussing what out's there today, but what we can use today, so don't
get too lost with what is right out there now.
Boyer volunteers to take over Canonical XML.
If you do an XPath and serialize it, and a succeeding transform expects well formed
XML, then a succeeding thing should do it. Canonical XML should work on any nodeset.
Connolly and Martin mentioned making character normalization (Normalized Form C)
orthogonal to element/attribute C14N.
- Boyer: presently XPath serialization says UTF8.
- C14N+ should not deal with character composition and decomposition. IFF it should be a
- Simon: and we take the Clark approach and not even do it.
- LaMacchia : where is this going to be an issue in SignedInfo anyway? Maybe URIs, maybe
- C14N will put into UTF-8, a seperate transform.
- Bartel: have a transform that checks for Normalized Form C. LaMachai: throwing an
exception won't help, makes it problematic for building an automated service. Do or do
not, do not try.
- So are we doing expection throwing, or is this API design? Solo: I was unable to
complete validation (with some data). Don't define unverifiable versus invalid.
Tom Gindin's point: if you combine documents, and there IDs conflict, what do you do?
Discussion: please send an example to list. (Reagle: not something I think we can fix.)
[Fox and LaMacchia presentation]
- DTD or Schema, which is normative?
- concerned that schema is green.
- Is a DTD or schema necessary? No, if it fits the constraints of 7.1.
- Should we conintue to point out at XSLT. People say keep it, put in a comment saying
should be c14n'ized first, downgrade to optional, and add elemnts to transform element
- Lipp: do we remove the whole Signature element, or just parts of it? We can remove the
whole Signature (should be refelected in XPath section).
- Action Eastlake (and Bartel with help of John) will do this by May 1.
- Action Fox and LaMacchia: rewrite KeyInfo by May 1.
- Action Reagle: Put out a new ietf-draft and TR before WWW9.
- Actin Reagle: write the proposed text for the AlgorithmID that finds the nearest and
Joseph Reagle <firstname.lastname@example.org
Last revised by Reagle $Date: 2000/08/09 19:34:12 $