See also: IRC log
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0040.html
sidenote from later in meeting: use your W3C login name as an IRC handle for ease of assigning actions
fjh: next call 8/12/08
<fjh> TPAC http://www.w3.org/2008/10/TPAC/Schedule
fjh: FtF scheduled Oct 20-21
<fjh> F2F planning
<fjh> http://www.w3.org/2002/09/TPOverview.html#Future
fjh: next year, 4 FtF mtgs
fjh: soliciting hosts for ftf meetings
<shivaram> Feb/March may be a better time in Seattle
<shivaram> due to weather
<gerald-> I could look into hosting the meeting here the first portion of 2009, I could work with Kelvin on this.
fjh: talked to XML coord group,
offer to get presentation but need guidance
... need to respond late this week / early next
klanz2: relationship between data
models in v1 and v2
... understand differences
<fjh> klanz2: impact of namespace prefix undeclarations on the XPath model
<fjh> ... relationship to xml 1.1
<scottc> core features that we would not want to profile out
<fjh> jccruellas: views on main relationships with xml signature for xpath 2.0
<fjh> ... most used features of XPath 2.0
<fjh> ... connections with xpath filter 2.0
klanz: implementation experience with performance, with respect to namespace processing
jccruellas: insight into XPath processing performance related to features, XPath 2.0 vs 1.0, and metrics used
<scribe> ACTION: fjh to draft message about XPath 2 presentation to mailing list [recorded in http://www.w3.org/2008/07/29-xmlsec-minutes.html#action01]
<trackbot> Created ACTION-20 - Draft message about XPath 2 presentation to mailing list [on Frederick Hirsch - due 2008-08-05].
<fjh> public http://www.w3.org/2008/xmlsec/Overview.html
fjh: updated public and admin pages, please review
<fjh> administrative http://www.w3.org/2008/xmlsec/Group/Overview.html
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0019.html
fjh: separate errata from new versions
jccruellas: any product related to XPath Filter 2?
<fjh> http://www.w3.org/2008/02/xmlsec-charter.html#deliverables
fjh: yes, listed in deliverables, add to product list
jccruellas: add product for XPath filter
RESOLUTION: approved product list with addition of XPath Filter
fjh: minor revisions sent out
klanz2: appropriate to wait another week
<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2008Jul/0034.html
fjh: please check member list and send a note if anybody missing
<pdatta> I was there on the 2nd half on both days
fjh: several people missing who dialed in, so please report if you're missing
<klanz2> Check here as well please:
<klanz2> http://lists.w3.org/Archives/Member/member-xmlsec/2008Jul/0035.html
<klanz2> http://lists.w3.org/Archives/Member/member-xmlsec/2008Jul/att-0035/16-xmlsec-minutes.html
<fjh> http://www.w3.org/2008/xmlsec/Group/Overview.html#issues
gerald-: reviewed issues and
actions
... resulting list seemed appropriate, but should review
... need relationship between issues captured in some way
fjh: some work on tracker ...
gerald-: seems to work now
... actions are specific tasks for people, issues are general
topics for discussion
issues might lead to actions
fjh: issue of substance to the standards, related to our deliverables ...
scottc: no final decision to use
tracker, but manual no good
... want to use tracker for actions, but issues could be handled
other ways
gerald-: other tools needed to track relationships
fjh: Agenda reviews are always implicit ...
<klanz2> re issues: maybe use titles to reflect relation ships
jccruellas: regrets for scheduled
meeting as scribe
... next meeting, 8/12
<fjh> regrets, klanz 8/12
scottc: happy to provide Jira instance if that's helpful for issues. will send email to fjh about it
fjh: identified at ftf as a core
issue
... avoiding big or breaking changes is helpful to adoption
... understand issues, priorities, but still limit changes when
possible
seems like one use case or requirement is to signal inline what degree of c14n might be needed
relationship between serialization and c14n
fjh: streaming is another consideration
<csolc> canonicalization as a final transform could output something other than a nodeset or an octect stream.
klanz2: improving of robustness when editing unsigned parts of document
<klanz2> potentially including reindention ...
pdatta: whitespace between element tags
pdatta: ignoreable-white-space that has not been ignored ...
csolc: schema define ordered relationship of elements
<klanz2> xs:all ?
csolc: schema communicates semantics, c14n only about the bytes
scottc: schema conveys semantics that c14n doesn't understand
<EdS> In my view, schema communicates structure -- namespace communicates semantics.
<EdS> Namespace defines the semantics (meaning of XML elements); schema defines the structural relationship of the XML elements (and points to their semantics (namespace)); and XML instances are instances of an XML schema.
scottc: yes, but much of the semantic comes from the connection between elements, which is a schema
<EdS> I would say, in reference to Scott's point above, that schemas provide semantics in the sense that they indicate a hierarchy of elements which implies a semantically-meaningful grouping relationship.
scottc: xml doc communicates information - expectation that sig should verify when the same, despite details
csolc: e.g. schema says order doesnt matter, c14n takes element order important, processor may reorder before c14n, then unexpected verification failure
klanz: line breaks in base64 are horrible
scottc: schema type normalization is a common source of breakage
<fjh> possible issue: simplified c14n for signing versus more general c14n, e.g. not produce compliant xml document
<fjh> issue: simplified c14n for signing versus more general c14n, e.g. not produce compliant xml document
<trackbot> Created ISSUE-37 - Simplified c14n for signing versus more general c14n, e.g. not produce compliant xml document ; please complete additional details at http://www.w3..org/2008/xmlsec/track/issues/37/edit ..
pdatta: other transforms depend on c14n1, e.g. STR
<gerald-> I need to leave, unfortuantely, talk to you all at the next meeting.
Kelvin: too many dependencies on
XML specs, making impls too complex and big
... goal to minimize and simplify dependencies
... reduces threat surface
<scribe> ACTION: Kelvin to propose ways to reduce dependencies on XML specs [recorded in http://www.w3.org/2008/07/29-xmlsec-minutes.html#action02]
<trackbot> Created ACTION-21 - Propose ways to reduce dependencies on XML specs [on Kelvin Yiu - due 2008-08-05].
bhill: in use cases, distinction
between need for XML signing and need for signing in XML
... simplified cases where you want the XML processor involved,
but not necessarily in a fully robust XML context
<fjh> issue: profile for signature processing for non-XML or for contrained XML requirements
<trackbot> Created ISSUE-38 - Profile for signature processing for non-XML or for contrained XML requirements ; please complete additional details at http://www.w3..org/2008/xmlsec/track/issues/38/edit ..
<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2008Jul/0025.html
scottc: is namespace prefix undeclaration a breaking change?
klanz2: other changes due to unicode as well
... some xml 1.1 features may go into 1.0
... useful to send comments/questions to xml core wg
<klanz2> http://lists.w3.org/Archives/Public/public-xml-core-wg/
<fjh> issues list http://www.w3.org/2008/xmlsec/track/issues/
<fjh> issue: Namespace Undeclarations and canonicalization
<trackbot> Created ISSUE-39 - Namespace Undeclarations and canonicalization ; please complete additional details at http://www.w3..org/2008/xmlsec/track/issues/39/edit ..
<fjh> EXI documents published - http://www.w3.org/News/2008#item128
<scottc> ACTION: esimon2 to review EXI docs that were published [recorded in http://www.w3.org/2008/07/29-xmlsec-minutes.html#action05]
<trackbot> Created ACTION-22 - Review EXI docs that were published [on Ed Simon - due 2008-08-05].
<fjh>: need to review where they mention signing, verification
EdS: expect exi goals to include efficient signing/verification of exi
jccruellas: exi another serialization, so are c14n and other concerns the same?
<EdS>: Will take approach that EXI requirements for signing will be based on EXI use cases and high efficiency.
jccruellas: does the usual 1 to many relationship exist between c14n and the source XML?
<fjh> issue: appropriate signing/verification position in EXI workflow, expectations and correctness review
<trackbot> Created ISSUE-40 - Appropriate signing/verification position in EXI workflow, expectations and correctness review ; please complete additional details at http://www.w3..org/2008/xmlsec/track/issues/40/edit ..
scottc: could be orthogonal, but may be ways to take advantage of EXI, e.g. XML nesting issues?
<fjh> issue: signing compact EXI representation of XML - is that reproducable for verification
<trackbot> Created ISSUE-41 - Signing compact EXI representation of XML - is that reproducable for verification ; please complete additional details at http://www.w3..org/2008/xmlsec/track/issues/41/edit ..
<fjh> ACTION: frederick to contact EXI re signature/verification use cases [recorded in http://www.w3.org/2008/07/29-xmlsec-minutes.html#action06]
<trackbot> Created ACTION-23 - Contact EXI re signature/verification use cases [on Frederick Hirsch - due 2008-08-05].
klanz: could transmission of EXI break signatures?
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0035.html
<klanz2> wonders if SUN has FastInfoset people interested in similar matters as EXI?
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0036.html
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0038.html
sean: concerned about relaxing
MUSTs
... existing signatures need to continue to validate
<jccruellas> +1
jccruellas: diff. requirements on signing vs. verifying seems like a good solution
<klanz2> -1
klanz: disagrees, diff between the
two is a small gap, so doesn't help implementations
... maybe change MUST to SHOULD, but agrees with sean
generally
csolc: need sig 2.0 indicator to make real changes
<fjh> ack 2nd edition
<fjh> ack 2nd
Kelvin: does w3c have guidance for
how to deprecate things?
... timelines for dropping
... would like to see SHA 256 and at least one NIST ECC on the
mandatory list
scottc: some things might be important enough to force people to support them
Kelvin: stronger crypto may have use where interop with weaker crypto not an issue
<klanz2> keep in mind that XAdES needs legacy algorithms for a long time, secured by stronger algorithms
<fjh> ... move SHA1 algs to recommended list.
<klanz2> ... and timestamps
<klanz2> .. cf. XAdES ArchiveTimestamp
sean: separate implementation reqs from spec reqs
<klanz2> deprecation for outdated algorithms on signing, " ... the implementation must issue a warning or so .... "
scottc: could have different levels of conformance, separate doc
jccruellas: one doc with the core
stuff, algorithm specifics, and rules for what to implement may
not be ideal
... algorithms often specific to deployment context
jccruellas: core + one or more algorithm docs that include xml syntax related to algorithm and requirementss
klanz: often a need to verify old
signatures
... emitting warnings on older algorithms, but not the same as
not computing them any more
<jccruellas> +1
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0016.html
<fjh> (sean)
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0031.html
<klanz2> We could distinguish three cases here:
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/att-0033/00-part
<klanz2> 1. New and Legacy
Processing would produce the same DigestInput
... 2. Processing that isn't backwards compatible
... 3. New Processing Models
... first case limits us to existing transforms
... second allows us to introduce new identifiers
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0034.html
scottc: prefer not to use transform to signal
data, could be misuse of feature
... could use hints
... not necessarily xml processing instruction
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/att-0033/00-part
pdatta: preserving forward
compatibility via adding attributes, will it break people?
... could add attributes to existing elements without breaking
existing implementations that do not expect it
... xpath implies DOM, but provide a hint that some transforms
could be streamed
<klanz2> +1
<klanz2> to see how far we get with hints
<fjh> issue: backward and forward compatibility
<trackbot> Created ISSUE-42 - Backward and forward compatibility ; please complete additional details at http://www.w3..org/2008/xmlsec/track/issues/42/edit ..
<EdS> I suggest calling it 1.1 if we restrict ourselves to non-breaking changes and call it 2.0 if/when we decide to go for breaking changes.
scottc: correcting the schema is important
<fjh> issue: improvements to XML Signature schema
<trackbot> Created ISSUE-43 - Improvements to XML Signature schema ; please complete additional details at http://www.w3..org/2008/xmlsec/track/issues/43/edit ..
<scribe> ACTION: scantor to review schema for improvements [recorded in http://www.w3.org/2008/07/29-xmlsec-minutes.html#action08]
<trackbot> Created ACTION-24 - Review schema for improvements [on Scott Cantor - due 2008-08-05].
<EdS> +1 to Scott's schema review
fjh: capability to envelope a Signature as a generic feature in schemas?
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0018.html
fjh: does new xsd provide something new here?
EdS: wildcard opens up to security threat
... special schema attribute in a signature?
... design for document should include signature in schema if
anticipated signing
<fjh> ... best practice for schema?
<fjh> ACTION: frederick to give feedback on xml schema best practice in xml-cg [recorded in http://www.w3.org/2008/07/29-xmlsec-minutes.html#action09]
<trackbot> Created ACTION-25 - Give feedback on xml schema best practice in xml-cg [on Frederick Hirsch - due 2008-08-05].
klanz: 2 cases
... signature is a first class object so designer needs to be
aware of it
... layered approach where the signature is separate from the XML
content
eds: only speaking of enveloped signatures
<csolc> the schema validation could ignore the signatures.
Kelvin: agrees that signature is first class citizen, but maybe add more flexible approach to detached signatures
eds: agrees, add support for a pointer to a signature in the schema
scottc: in other words, an xsi:sig attribute?
EdS: or xml:sig
<EdS> Idea is that a special attribute, perhaps in XML Schema or perhaps even better in the XML spec, for referencing a signature (detached or maybe not) that applies to the element.
<fjh> issue: requirement to enable signatures on documents that do not anticipate signatures in the schema
<trackbot> Created ISSUE-44 - Requirement to enable signatures on documents that do not anticipate signatures in the schema ; please complete additional details at http://www.w3..org/2008/xmlsec/track/issues/44/edit ..
fjh: if completed, please send to list
with ACTION-# in the body and title indicating status of action
fjh: look at old best practices document from earlier WG
<fjh> http://www.w3.org/2007/xmlsec/Drafts/xmldsig-bestpractices/
[NEW]
ACTION: esimon2 to review EXI docs that were
published [recorded in http://www.w3.org/2008/07/29-xmlsec-minutes.html#action05]
[NEW] ACTION: fjh to draft
message about XPath 2 presentation to mailing list [recorded in
http://www.w3.org/2008/07/29-xmlsec-minutes.html#action01]
[NEW] ACTION: frederick to
contact EXI re signature/verification use cases [recorded in
http://www.w3.org/2008/07/29-xmlsec-minutes.html#action06]
[NEW] ACTION: frederick to give
feedback on xml schema best practice in xml-cg [recorded in
http://www.w3.org/2008/07/29-xmlsec-minutes.html#action09]
[NEW] ACTION: Kelvin to propose
ways to reduce dependencies on XML specs [recorded in http://www.w3.org/2008/07/29-xmlsec-minutes.html#action02]
[NEW] ACTION: scantor to review
schema for improvements [recorded in http://www.w3.org/2008/07/29-xmlsec-minutes.html#action08]
[End of minutes]