- From: Thomas Roessler <tlr@w3.org>
- Date: Tue, 12 Aug 2008 16:13:52 +0200
- To: public-xmlsec@w3.org
Minutes from our meeting on 2008-07-29 were approved and are
available online here:
http://www.w3.org/2008/07/29-xmlsec-minutes.html
A text version is included below the .signature.
--
Thomas Roessler, W3C <tlr@w3.org>
[1]W3C
XML Security Working Group Teleconference
29 Jul 2008
[2]Agenda
See also: [3]IRC log
Attendees
Present
Frederick Hirsch, Konrad Lanz, Juan Carlos Cruellas, ChrisSolc,
Gerald Edgar, Sean Mullan, Brad Hill, Scott Cantor, Ed Simon,
Prateek Datta, John Wray, Shivaram, Kelvin Yiu
Regrets
Rob Miller, Bruce Rich, Anil Saldhana
Chair
Frederick Hirsch
Scribe
Scott Cantor
Contents
* [4]Topics
1. [5]Administrative
2. [6]Meeting Planning
3. [7]XPath 2
4. [8]Web Pages
5. [9]Products List
6. [10]Minutes Approval
7. [11]Issues List Management
8. [12]Canonicalization Requirements
9. [13]Namespaces and Namespace Undeclarations
10. [14]EXI
11. [15]Algorithm Requirements
12. [16]Transforms
13. [17]Schema Validation after adding a signature
14. [18]Action Items
* [19]Summary of Action Items
__________________________________________________________________
Administrative
<fjh>
[20]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
Meeting Planning
fjh: next call 8/12/08
<fjh> TPAC [21]http://www.w3.org/2008/10/TPAC/Schedule
fjh: FtF scheduled Oct 20-21
<fjh> F2F planning
<fjh> [22]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.
XPath 2
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
[23]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].
Web Pages
<fjh> public [24]http://www.w3.org/2008/xmlsec/Overview.html
fjh: updated public and admin pages, please review
<fjh> administrative
[25]http://www.w3.org/2008/xmlsec/Group/Overview.html
Products List
<fjh>
[26]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> [27]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
Minutes Approval
fjh: minor revisions sent out
klanz2: appropriate to wait another week
<fjh>
[28]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>
[29]http://lists.w3.org/Archives/Member/member-xmlsec/2008Jul/0035.html
<klanz2>
[30]http://lists.w3.org/Archives/Member/member-xmlsec/2008Jul/att-0035/
16-xmlsec-minutes.html
Issues List Management
<fjh> [31]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
Canonicalization Requirements
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
[32]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
[33]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 [34]http://www.w3..org/2008/xmlsec/track/issues/38/edit ..
Namespaces and Namespace Undeclarations
<fjh>
[35]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> [36]http://lists.w3.org/Archives/Public/public-xml-core-wg/
<fjh> issues list [37]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
[38]http://www.w3..org/2008/xmlsec/track/issues/39/edit ..
EXI
<fjh> EXI documents published - [39]http://www.w3.org/News/2008#item128
<scottc> ACTION: esimon2 to review EXI docs that were published
[recorded in
[40]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
[41]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 [42]http://www.w3..org/2008/xmlsec/track/issues/41/edit ..
<fjh> ACTION: frederick to contact EXI re signature/verification use
cases [recorded in
[43]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?
Algorithm Requirements
<fjh>
[44]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>
[45]http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0036.html
<fjh>
[46]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
Transforms
<fjh>
[47]http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0016.html
<fjh> (sean)
<fjh>
[48]http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0031.html
<klanz2> We could distinguish three cases here:
<fjh>
[49]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>
[50]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>
[51]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
[52]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
[53]http://www.w3..org/2008/xmlsec/track/issues/43/edit ..
<scribe> ACTION: scantor to review schema for improvements [recorded in
[54]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
Schema Validation after adding a signature
fjh: capability to envelope a Signature as a generic feature in
schemas?
<fjh>
[55]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
[56]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
[57]http://www.w3..org/2008/xmlsec/track/issues/44/edit ..
Action Items
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> [58]http://www.w3.org/2007/xmlsec/Drafts/xmldsig-bestpractices/
Summary of Action Items
[NEW] ACTION: esimon2 to review EXI docs that were published [recorded
in [59]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
[60]http://www.w3.org/2008/07/29-xmlsec-minutes.html#action01]
[NEW] ACTION: frederick to contact EXI re signature/verification use
cases [recorded in
[61]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
[62]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
[63]http://www.w3.org/2008/07/29-xmlsec-minutes.html#action02]
[NEW] ACTION: scantor to review schema for improvements [recorded in
[64]http://www.w3.org/2008/07/29-xmlsec-minutes.html#action08]
[End of minutes]
__________________________________________________________________
Minutes formatted by David Booth's [65]scribe.perl version 1.133
([66]CVS log)
$Date: 2008/08/12 14:11:55 $
__________________________________________________________________
References
1. http://www.w3.org/
2. http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0040.html
3. http://www.w3.org/2008/07/29-xmlsec-irc
4. http://www.w3.org/2008/07/29-xmlsec-minutes.html#agenda
5. http://www.w3.org/2008/07/29-xmlsec-minutes.html#item01
6. http://www.w3.org/2008/07/29-xmlsec-minutes.html#item03
7. http://www.w3.org/2008/07/29-xmlsec-minutes.html#item04
8. http://www.w3.org/2008/07/29-xmlsec-minutes.html#item05
9. http://www.w3.org/2008/07/29-xmlsec-minutes.html#item06
10. http://www.w3.org/2008/07/29-xmlsec-minutes.html#item07
11. http://www.w3.org/2008/07/29-xmlsec-minutes.html#item08
12. http://www.w3.org/2008/07/29-xmlsec-minutes.html#item09
13. http://www.w3.org/2008/07/29-xmlsec-minutes.html#item10
14. http://www.w3.org/2008/07/29-xmlsec-minutes.html#item12
15. http://www.w3.org/2008/07/29-xmlsec-minutes.html#item13
16. http://www.w3.org/2008/07/29-xmlsec-minutes.html#item14
17. http://www.w3.org/2008/07/29-xmlsec-minutes.html#item15
18. http://www.w3.org/2008/07/29-xmlsec-minutes.html#item16
19. http://www.w3.org/2008/07/29-xmlsec-minutes.html#ActionSummary
20. http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0040.html
21. http://www.w3.org/2008/10/TPAC/Schedule
22. http://www.w3.org/2002/09/TPOverview.html#Future
23. http://www.w3.org/2008/07/29-xmlsec-minutes.html#action01
24. http://www.w3.org/2008/xmlsec/Overview.html
25. http://www.w3.org/2008/xmlsec/Group/Overview.html
26. http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0019.html
27. http://www.w3.org/2008/02/xmlsec-charter.html#deliverables
28. http://lists.w3.org/Archives/Member/member-xmlsec/2008Jul/0034.html
29. http://lists.w3.org/Archives/Member/member-xmlsec/2008Jul/0035.html
30. http://lists.w3.org/Archives/Member/member-xmlsec/2008Jul/att-0035/16-xmlsec-minutes.html
31. http://www.w3.org/2008/xmlsec/Group/Overview.html#issues
32. http://www.w3.org/2008/xmlsec/track/issues/37/edit
33. http://www.w3.org/2008/07/29-xmlsec-minutes.html#action02
34. http://www.w3.org/2008/xmlsec/track/issues/38/edit
35. http://lists.w3.org/Archives/Member/member-xmlsec/2008Jul/0025.html
36. http://lists.w3.org/Archives/Public/public-xml-core-wg/
37. http://www.w3.org/2008/xmlsec/track/issues/
38. http://www.w3.org/2008/xmlsec/track/issues/39/edit
39. http://www.w3.org/News/2008#item128
40. http://www.w3.org/2008/07/29-xmlsec-minutes.html#action05
41. http://www.w3.org/2008/xmlsec/track/issues/40/edit
42. http://www.w3.org/2008/xmlsec/track/issues/41/edit
43. http://www.w3.org/2008/07/29-xmlsec-minutes.html#action06
44. http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0035.html
45. http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0036.html
46. http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0038.html
47. http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0016.html
48. http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0031.html
49. http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/att-0033/00-part
50. http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0034.html
51. http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/att-0033/00-part
52. http://www.w3.org/2008/xmlsec/track/issues/42/edit
53. http://www.w3.org/2008/xmlsec/track/issues/43/edit
54. http://www.w3.org/2008/07/29-xmlsec-minutes.html#action08
55. http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0018.html
56. http://www.w3.org/2008/07/29-xmlsec-minutes.html#action09
57. http://www.w3.org/2008/xmlsec/track/issues/44/edit
58. http://www.w3.org/2007/xmlsec/Drafts/xmldsig-bestpractices/
59. http://www.w3.org/2008/07/29-xmlsec-minutes.html#action05
60. http://www.w3.org/2008/07/29-xmlsec-minutes.html#action01
61. http://www.w3.org/2008/07/29-xmlsec-minutes.html#action06
62. http://www.w3.org/2008/07/29-xmlsec-minutes.html#action09
63. http://www.w3.org/2008/07/29-xmlsec-minutes.html#action02
64. http://www.w3.org/2008/07/29-xmlsec-minutes.html#action08
65. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
66. http://dev.w3.org/cvsweb/2002/scribe/
--
Thomas Roessler, W3C <tlr@w3.org>
Received on Tuesday, 12 August 2008 14:14:33 UTC