See also: IRC log
<trackbot> Date: 24 March 2009
<fjh> Scribe: Scott Cantor
<fjh> Agenda: http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0049.html
Public page updated with FPWDs
<fjh> updated public page
<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2009Mar/0018.html
<fjh> Please complete F2F Registration (12-13 May) Questionnaire
<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2009Mar/0017.html
<fjh> Minutes from 17 March 2009, for approval
<fjh> http://www.w3.org/2009/03/17-xmlsec-minutes.html
RESOLUTION: Minutes from March 17th approved
<fjh> Updated the Signature 1.1 Editors draft to make Exclusive
<fjh> Canonicalization omitting comments required
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0037.html
<fjh> sections 6.1 and 6.5 updated
magnus: updated 1.1 with schema changes and corrections
http://lists.w3.org/Archives/Member/member-xmlsec-commits/2009Mar/0024.html
fjh: lot of changes to widget sig doc
fjh: suggestion made to interop in phases
mullan: would be good to have
something for F2F to spend a couple hours looking at
... hasn't had time to start developing test cases
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0041.html
magnus: completed schema proposal
and some text
... mistake made, need to pull discussion of Seed
... suggest we still need to reference X9.62 because SEC-1 refers
to it
bal: feels goal of not having to
purchase specs to implement ours is a good one
... but it's not a policy
<scribe> ACTION: magnus to investigate alternative source for material in X9.62 [recorded in http://www.w3.org/2009/03/24-xmlsec-minutes.html#action01]
<trackbot> Created ACTION-239 - Investigate alternative source for material in X9.62 [on Magnus Nyström - due 2009-03-31].
RESOLUTION: adopt Magnus' text into 1.1
<scribe> ACTION: magnus to add proposed text to 1.1 [recorded in http://www.w3.org/2009/03/24-xmlsec-minutes.html#action02]
<trackbot> Created ACTION-240 - Add proposed text to 1.1 [on Magnus Nyström - due 2009-03-31].
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0047.html
magnus: suggestion is to add a comment to highlight possible use of ECKeyValue as wildcard content
<csolc> +1
discussion over whether to maintain DTDs
<fjh> magnus notes in favor of dropping dtd
mullan: note that the comment idea isn't necessarily being followed in other spots
tlr: suggest we take a position to
drop DTDs, and see if anybody objects
... best way to contact people is ask the CG, ask particular
communities, and put out a draft
<scribe> ACTION: fjh to reach out to people on DTD question [recorded in http://www.w3.org/2009/03/24-xmlsec-minutes.html#action03]
<trackbot> Created ACTION-241 - Reach out to people on DTD question [on Frederick Hirsch - due 2009-03-31].
fjh: sense of WG is to drop DTDs
<fjh> plan to check with stakeholders if any major concern with dropping DTDs, if none will drop
RESOLUTION: accept schema change to add comment regarding ECKeyValue
<scribe> ACTION: Magnus to add schema comment regarding ECKeyValue [recorded in http://www.w3.org/2009/03/24-xmlsec-minutes.html#action04]
<trackbot> Created ACTION-242 - Add schema comment regarding ECKeyValue [on Magnus Nyström - due 2009-03-31].
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0046.html
<fjh> Scott provided a proposal after the F2F to add new top level element to KeyInfo, name might need improvement
<fjh> scott noted that we need id attributes in various schema items that are added
<fjh> scott noted we should make sure other schemas do this
<fjh> how about SubjectBareKey
<bal> or DEREncodedPublicKey
<bal> because you don't want to say "X.509" because it's more than that
<fjh> bal notes need to add ECC and DH
<fjh> scott notes it is useful to list ones we know about, also to clarify that going forward need to be clear how new items should be added
<fjh> magnus asks if we need such a list
<fjh> scott or add sentence stating to go to RFC for new items
<fjh> suggest having list for algorithms in this document and then sentence on how to deal with others
<fjh> kelvin notes there is an RFC
<fjh> 4055
RESOLUTION: accept amended proposal with RFC enumeration
<scribe> ACTION: scantor to update 1.1 draft with DEREncodedKeyValue proposal [recorded in http://www.w3.org/2009/03/24-xmlsec-minutes.html#action05]
<trackbot> Created ACTION-243 - Update 1.1 draft with DEREncodedKeyValue proposal [on Scott Cantor - due 2009-03-31].
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0038.html
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0039.html
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0045.html
<fjh> scott notes questions like these could frame our steps going forward to 2.0
<fjh> scott notes helps answer are we ready to do this, do we understand implications
<fjh> q1 is Do the advantages of the proposed redesign outweigh the cost of creating a significantly different 2.0 specification?
<fjh> scott - need to address major issues, including streaming but also need to consider existing implementations
<fjh> q2 use case analysis, what could be done today that cannot be done going forward
<fjh> scott notes this brings the xslt discussion
<esimon2> yes, XSLT can produce any output you want.
<fjh> konrad notes you can use known and understood transform without being afraid
<fjh> klanz notes that transform and its output is important to know, since output can be adjusted
<fjh> q3 - is need for transforms limited to xslt and decryption, is workflow a suitable alternative
<fjh> q4 - is the extension model necessary and sufficient?
<fjh> scott asks how extension model work, does it require source modification, is it pluggable?
<fjh> scott would this extension model be workable, usable?
<fjh> sean asks how many vendors will have resources to implement new version. 1.0 had a lot of vendors.
<scantor> I agree with Konrad, but it's also the case that unless something's removed, we won't see implementations in new languages
<Gerald-e> We have a Python community here, and some are using XML Signatures now.
<Gerald-e> I am not sure how they are accessing signature capabilities
<klanz2> copied from /me:
<klanz2> [15:57] klanz2 wonders if minimum changes with maximum effect can be found ...
<klanz2> [15:58] klanz2 I like good transforms that make our life easier ... and remove pain like whitespace and what "people/users" really care about
<fjh> scott notes that c binding is not really good for python perl etc, better to have native implementation, therefore simplicity would help
<tlr> is xml one of these barriers?
<fjh> another question is what about open source communities
<esimon2> How much has PKCS been implemented in Python, etc.?
<klanz2> ;-)
<scantor> I think there's probably some of that stuff
(the PKCS stuff)
sometimes it's also on top of openssl though
<klanz2> @tlr: "is xml one of these barriers?" http://tinyurl.com/MT-Konrad-Lanz-OASIS-DSS#page=92
<fjh> sean asks whether we have enough commitment toward implementation
<klanz2> I still like my proposal with PIs ... start digest here ... stop digest here and a signature at the end of the document that collects all those digests
fjh: suggests people look at list of questions raised, perhaps raise others
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0038.html
pdatta: initially proposed
something using 1.0 syntax, with restricted form
... was encouraged to rework with new syntax, but could go
back
... or try to express using existing transform model
<fjh> not ready yet for a decision in my opinion
<klanz2> I would have to repaeat myself about the document use cases derived using transforms ...
<tlr> fjh, you can share things from the AC meeting on the member-confidential list
scantor: one source of effort to make change is that APIs tend to follow syntax
tlr: should proceed in tiers: first
develop restricted XPath, disallow XSLT inline, simplify
c14n
... could express with existing transform model, but if that's
all you ever do, throw away the old model and just do this
stuff
... the other way to proceed is with the new proposed markup
<klanz2> what is the deployment model for transforms?
<klanz2> if not a declarative leanguage
<tlr> fjh: major areas
<tlr> 1. transform model (still open)
<tlr> 2. canonicalization
<tlr> 3. algorithms (mostly ok, modulo MTI)
<tlr> 4. basic structure (seems kind of acceptable)
<tlr> 5. extensibility requirements
<tlr> 6. out of band signalling (PIs)
<klanz2> Requirement: Reproducibility ... A signer needs to be able to deploy a signature with well defined processing prescriptions using well established XML/WEB technologies so that a verifier can reproduce what a signer "intended" to sign.
<klanz2> "intended" needs a different wording
<tlr> klanz, I think that requirement is the fundamental mission statement for any XML Signature spec...
<klanz2> sure but we are removing that by removing the only declarative language currently optionally supported in XMLDSIG that allows real transformation rather than just document subset selection
RESOLUTION: adopt Prateek's clarifying text on extensions section 4.5 in transforms note
<scribe> ACTION: pdatta to update transforms note sec. 4.5 [recorded in http://www.w3.org/2009/03/24-xmlsec-minutes.html#action06]
<trackbot> Created ACTION-244 - Update transforms note sec. 4.5 [on Pratik Datta - due 2009-03-31].
<fjh> konrad notes that pi could be simplest approach toward performance improvement
klanz2: we don't necessarily have to produce XML Sig 2.0, could be something orthogonal
bal: lots of little versions, hard
to keep track, and as an implementer you only get limited windows
to make changes
... hard to articulate what you support at a given time
<fjh> q layering approach, core plus optional features vs radical rewrite
<fjh> brian noted this
<fjh> brian notes transition path needed for new release
<fjh> scott issue of changing namespace and requiring updates
scantor: we don't know for sure
that we couldn't do this with the existing Transform model
... but profiling/conformance issues also need to be
addressed
bal: key is the transition plan, however you do it
<fjh> brian notes need roadmap to get to new place
klanz2: let's create a product for
such a Transform within existing spec framework
... see where it can go
mullan: in Java, probably won't get
a chance to revise JSR API
... know we need to fix stuff, but think we need to live within
the API we have
brich: like Sean, seems like we're
covering the old ground
... seemed like XPath data model was the performance problem
<fjh> bruce notes XPath 2.0 data model is issue, would new transforms address that assumption
klanz2: thinks constraints would
address problems with c14n
... should try to draw some principles out of today's
material
fjh: think we have one chance to make real changes
scantor: I think we have at most one, not clear we have one
<tlr> I think we can have a declarative model in the old syntax, but we're at the top of the hour.
fjh: please consider list conversation to discuss issues
<Gerald-e> Please take a look at the issues sent out as part of the agenda today, can these be closed?
<Gerald-e> an item for next week...
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0038.html
[NEW]
ACTION: fjh to reach out to people on DTD
question [recorded in http://www.w3.org/2009/03/24-xmlsec-minutes.html#action03]
[NEW] ACTION: magnus to add
proposed text to 1.1 [recorded in http://www.w3.org/2009/03/24-xmlsec-minutes.html#action02]
[NEW] ACTION: Magnus to add
schema comment regarding ECKeyValue [recorded in http://www.w3.org/2009/03/24-xmlsec-minutes.html#action04]
[NEW] ACTION: magnus to
investigate alternative source for material in X9.62 [recorded in
http://www.w3.org/2009/03/24-xmlsec-minutes.html#action01]
[NEW] ACTION: pdatta to update
transforms note sec. 4.5 [recorded in http://www.w3.org/2009/03/24-xmlsec-minutes.html#action06]
[NEW] ACTION: scantor to update
1.1 draft with DEREncodedKeyValue proposal [recorded in http://www.w3.org/2009/03/24-xmlsec-minutes.html#action05]
[End of minutes]