See also: IRC log
<scribe> Agenda: http://lists.w3.org/Archives/Public/public-xmlsec/2008Nov/0001.html
25 November, 23 December, 30 December 2008 Teleconferences have been cancelled
http://www.w3.org/2008/xmlsec/Group/Overview.html#upcoming-meetings
13-14 January, Redwood City, CA F2F. Folks should plan for travel
<shivaram> SSTC: what is the general practice in the field
<shivaram> WS-Policy: there will be an errata regarding C14N and no revision of the spec itself
<shivaram> they will be approved next week after getting input from other teams
http://www.w3.org/2008/xmlsec/Drafts/transform-note/Overview.html
http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/0047.html
<shivaram> Bal: states that there is lot of history here. There are benefits to stating that "I am signing exactly this..."
<shivaram> Konrad: expressed concern on referencing data in transformations
<shivaram> Don't intermingle selection, etc with exactly what is being signed
<jwray> The goal is to reduce complexity, while including the maximum number of use cases
+1 to jwray
jwray notes that could sign the xslt and then apply it on the document to avoid attack issues
<shivaram> Request Pratik Datta to look into transform note
<klanz2> what do you mean by "reselection"
<shivaram> klanz2 would like to see a minor revision to 1.0 XML Sig and not break too much compatibility, but, use a more restricted set
<csolc> want to simplify so you can reduce complexity and this leads to more performant implementations
<csolc> it also reduces the attack surrface.
klanz noted that we could have two ds:Reference elements, one old style, one new
<scribe> ACTION: klanz to email proposal regarding 2 ds:References, old and new [recorded in http://www.w3.org/2008/11/04-xmlsec-minutes.html#action02]
<trackbot> Created ACTION-100 - Email proposal regarding 2 ds:References, old and new [on Konrad Lanz - due 2008-11-11].
<bal> +q
bal dont see xslt as essential to xml signature transform chain, view as security risk
+1
<csolc> +1
discussion of whether signature over presentation or data..
<shivaram> Bal notes that he is more concerned about data and not much about the presentation aspects for Signature objects
<shivaram> There is discussion oh the implication of what is signed and how it is presented and the implication of verification of presentation layer
csolc: why not perform xslt processing before Reference processing then sign xslt transform as well as what else is required for auditing. This simplifies xml signature processing, reduces risks, and brings transformation closer to application layer
<shivaram> shivaram: states that may be we should separate out Data and Presentation use of Signing and create appropriate best practices
konrad notes that xslt is not a risk if xslt instance is trusted and reviewed
<shivaram> Use case: if there a XSLT that is trusted and tested, then one should be able to use it
<shivaram> fjh: states piece mealing spec items so that we can get them resolved faster & better. Then we can piece it together to make it into our requirements doc
<shivaram> fjh requests suggestions and comments on best ways to achieve the same
<shivaram> ACTION: fjh to provide a detailed roadmap on getting to the end game of Requirements [recorded in http://www.w3.org/2008/11/04-xmlsec-minutes.html#action04]
<trackbot> Created ACTION-101 - Provide a detailed roadmap on getting to the end game of Requirements [on Frederick Hirsch - due 2008-11-11].
http://www.w3.org/2008/xmlsec/track/actions/open
<klanz2> http://www.w3.org/2008/xmlsec/track/actions/13
<klanz2> http://lists.w3.org/Archives/Public/public-xmlsec/2008Jul/0034.html
<klanz2> ACTION-13
action 13 done, will add email
set deadline for action 13 to next week for shivaram
action 24 2008-12-01
set deadline for action 24 to end november
<klanz2> The proposal basically was to use hints to stipulate how a chain of transforms will behave in terms of streaming processing
the action 52 went into transform primitives
action-52 closed
<trackbot> ACTION-52 Attempt summarizing recent discussions as input for design document closed
konrad, derive requiements for simple transform
add transform primitives to requirements document?
need to discuss list of transforms, or canonicalization
<klanz2> http://www.w3.org/TR/xptr-element/
add to next week agenda discussion of transform primitives, xpointer element
<klanz2> maybe also http://www.w3.org/TR/xptr-xmlns/
<klanz2> could be an easy way to be used for selection ...
set date for 55 to next week
part of material for action-66 from norm
http://lists.w3.org/Archives/Public/public-xmlsec/2008Nov/0002.html
set date for 85 to next week
kelvin will work on algorithms first then 86
planning to look at 88 end dec
to close either 86 or 90, duplication
<jcruella> very initial draft in: http://lists.w3.org/Archives/Public/public-xmlsec/2008Nov/0006.html
close action-91
<trackbot> ACTION-91 Provide a draft for the requirements document for long term signatures. closed
kelvin provided list of uris at f2f
close action-92
<trackbot> ACTION-92 Propose text for note providing an index to XML Security URIs closed
discussion of action-94, algorithms for 1.1
<klanz2> could you please, type to the chat ...
<klanz2> http://tools.ietf.org/html/rfc4050
<klanz2> http://tools.ietf.org/html/rfc4051
<klanz2> 4050 is INFORMATIONAL ...
<klanz2> bal: inelegant markup ... ?
<klanz2> proposal? -> harmonize 4050 and XMLDSIG ?
bal and kelvin note that RFC 4051 is Eastlake list of algs, RFV 4050 definitions of ECC in dsig. Noted that RFC 4050 is translation of ASN.1 spec, structures do not mix well with xml dsig, cannot just merge DTDs. Question: do we want to define DTDs going forward?
4050 not elegant, may wish to define structures as appropriate in XML Security, not necessarily matching 4050
depend on 4050 as much as possible
need - samples of ecc signatures, what is supported from 4050, what is actually used
request to implementers for input on this issue
<klanz2> we support ECC ...
<esimon2> I Is the W3C maintaining the DTD spec? Will future XML versions introduce features not properly expressible by DTDs?
<bal> do you know how much of 4050 you support?
kelvin notes could merge schema, but would require two dtds
kelvin notes might want to simplify schema, improve
<shivaram> klanz2 has offered to help kyiu with samples
kelvin, name curve ok, maybe simplify explicit
<shivaram> ACTION: fjh to check on DTDs with W3C [recorded in http://www.w3.org/2008/11/04-xmlsec-minutes.html#action05]
<trackbot> Created ACTION-102 - Check on DTDs with W3C [on Frederick Hirsch - due 2008-11-11].
<klanz2> klanz2 zakim, who is on the phone?
action-97 closed
<trackbot> ACTION-97 Add transforms requirements material to requirements draft closed
frederick incorporated material from pratik into transform draft
action-98 closed
<trackbot> ACTION-98 Draft database certificate use case and requirements for document, share on mail list closed
http://lists.w3.org/Archives/Public/public-xmlsec/2008Nov/0007.html
close action-99
<trackbot> ACTION-99 Email list with specifics on this performant implementaiton closed
http://www.w3.org/2008/xmlsec/track/issues/open
konrad notes that we may wish to review issues list for which items can be in v1.1 and addressed sooner, have quick impact
konrad putting algorithms out in draft note earlier to get feedback as well?
<shivaram> Sean and Juan Carlos are working on this
<klanz2> re previous topic ... I'd advocate for putting a list of small "useful" transforms, transform primitives ...
http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/0020.html
action jcc to provide updated email on best practices issue
<trackbot> Created ACTION-103 - Provide updated email on best practices issue [on Juan Carlos Cruellas - due 2008-11-11].
http://www.w3.org/2008/xmlsec/Drafts/xmlsec-reqs/Overview.html
<shivaram> fjh: Seperate requirements and design work. Publish note on design work after requirements
<klanz2> sounds good
<klanz2> do we have a link or something to anchor this ...
magnus notes that have not seen encodings other than DER
scott notes that that raises interop issue, why not require DER
scott notes DSig maybe should require DER
bal notes reference 5280, requires DER for computing hash, but not serialized that way
bal asks if PKIX to require DER
scott notes difference of asn1 library and certificate library, and limitation of cert library
scott either need encoding attribute or processing rule in dsig to clarify encoding, why not in 1.1 require DER
issue require DER encoding in 1.1
issue: require DER encoding in 1.1
<trackbot> Created ISSUE-70 - Require DER encoding in 1.1 ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/70/edit .
issue: change section titles in best practices to match practices
<trackbot> Created ISSUE-71 - Change section titles in best practices to match practices ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/71/edit .
magnus suggests requiring supporting encoding, concerned about requiring DER, prefer change in base spec
scott notes with schema change we can nail down encoding, or provide encoding attribute
allow other encodings through use of extensions
scott - huge burden to implement many encodings
bal prefers text in spec, rather than new attribute