[You can also read Reagle's supplemental notes (very redundant with what is already here).]
Management: XML Syntax WG handed off to core WG. C14N is a lower priority item and may take a while. Question as to whether we take over C14N/serialization draft. Namespace C14N (rewriting problems)? Fragment wrapping? Should we have multiple drafts? For processing signedInfo, do we expect XML processing or do we allow a "simpler" handling. Phil Hallam-Baker claims security issues. Kent concerned about having to implement something non-standard - parsers don't currently provide raw character stream access necessary to deal with "minimal C14N".
There are likely to be multiple environments, some where parsers are prevalent, but perhaps others with more of a messaging orientation where simplified processing is desired or where tools aren't available. Should the specification still support both cases (and both serializations) and allow application environments to specify?
Perhaps issue is minimal and full C14N are both mandatory. Is there an environment in which minimal is both necessary and appropriate?
Poll: (note: Full C14N assumes a "repaired" C14N draft that meets with our satisfaction)
Idea from Mark Bartel that signers wanting lightweight processing model should just always produce and (expect to) consume fully C14N'ized XML. Widespread support for this model
David Solo to draft paragraphs.
Should we change 4.3.1 to default to Full C14N?: Yes.
How to wrap a list of elements/attributes to create a single element -> How to take the output of XPath and create valid XML. If the output is not proper XML, should it be an error? No, but next processing step may generate an error. New C14N/serialization spec will work on any node set.
C14N of namespaces. Renaming labels is a problem John will propose a solution for (probably don't do any label changes). Is there such a thing as a normalized NS?
Perhaps separate charset normalization from other C14N/serialization?
Proposal to remove character representation issues from the C14N spec A second optional, unspecified transform for references to perform charset normalization could be defined later since no charset representation/composition normalization need be applied to signedInfo! C14N will still do UTF8 encoding. Maybe just a URI issue within signedInfo? No, because draft says use UTF-8 for URIs and then escape all non-ASCII characters that result. Question about recommending "normalized form C" for UTF-8 (always compose characters) because its relatively easy to create, but hard to convert. Need to run this by the I18N group.
Recommendation: Remove general charset representation from C14N A future transform could address UTF8 conversion to normalized form C. C14N will still do UTF-8 conversion Recommend documents use normalized form C (already a W3C guideline) with early normalization and W3C character model; including SignedInfo.
John Boyer will take on editing of C14N spec and propose recommendations for fragments and namespaces.
Reiterated document should not talk about invalid and un-verifiable signatures. Left to the individual implementation.
Problem raised by FSML regarding what happens if I have multiple signed documents with colliding IDs that I want to merge into a single signed document. Answer: if you have this problem, then you should be able to generate unique IDs. Please post examples to list where this solution is not satisfactory and how the Signature WG can easily remedy the problem.
KeyInfo mandatory to recognize, optional to include; KeyValue mandatory, X.509, PGP optional. KeyInfo is a "hint" to get the right public key for validation.
Past issues that are now non-issues:
Karlinger: Eastlake to fix 7.1 re XML 1.0 whitespace.
Internationalization: It is suggested that we change Transforms to TransformList, SignatureProperties to SignaturePropertyList, etc., for easier understanding. Participants appreciate concern but consensus at meeting is not to change due to existing examples and code.
XPath Identifier: To simplify the embedded siganture case, create an algorithm identifier defined to do the equivalent of an XPath expression that elininates the signature value of the signtaure it appears in. [Later investigation indicated that it may not be possible to do this with a generic XPath expression but an example can still be given.]
MimeType/Charset/Transfrom processing model. Martin Durst comments... Consensus: drop attributes and provide as parameters to transforms that need them. Eastlake to draft a new version of 4.3.3.1.
Conseus to Drop Quoted Prinable. It appears not to perform any function which could not be met with entities.
Syntax for open content: Instead of ANY or #PCDATA use %Object.ANY so content can be externally defined.
Consensus to state that if section 7.1 syntax constraints are followed, a validating pareser is not needed.
Is Schema or DTD normative? Schema should be normative.
XSLT: Leave in XSLT Transform. Comment that if output is going to be digested, it should be canonicalized first.
Reagle: need implementations. Can do on list or have web or other automated interface.
On the need for test vectors and interoperability cases. A complete matrix is probably not needed for a while if multiple people on different platforms bang on it.
People waiting for CR, but should start in the meantime (sending examples to the list).