XML Security Working Group Teleconference
27 Oct 2009

Agenda

Attendees

Present:: Frederick_Hirsch, Hal_Lockhart, Gerald_Edgar, Sean_Mullan, Ed_Simon, Brian_LaMacchia, Bruce_Rich, Chris_Solc, Cynthia_Martin, Pratik_Datta, Shivaram_Mysore
Regrets:: Aldrin D'Souza, Thomas Roessler, Scott Cantor
Chair:: Frederick Hirsch
Scribe: Hal Lockhart

· Topics

5. Renaining 1.1 Issues

6. Relax NG

7. Requirements Issues

8. Open Actions and Issues

· Summary of Action Items

<trackbot> Date: 27 October 2009

<fhirsch> Scribe: Hal Lockhart

<scribe> ScribeNick: hlockhar

Administrative

<fhirsch> registration for TPAC http://www.w3.org/2002/09/wbs/35125/TPAC09/registrants#xmlsec

fjh: TPAC next week
... may have to adjust TPAC agenda

<fhirsch> group questionnaire http://www.w3.org/2002/09/wbs/42458/tpac2009/results

<fhirsch> draft agenda

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2009Oct/0059.html

Draft TPAC Agenda

fjh: big topic of eliptic curve
... trying to get new informaiton
... will try to resolve it if we can
... also some last call items

<fhirsch> f2f draft agenda

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2009Oct/0059.html

fjh: have to make last call decisions
... proposals today for requirements updates, if agreed need to update before f2f
... welcome suggestions for changes or additions

pdatta: made internal presentations on sig 2.0
... could present it at TPAC and edit it and make it generally available

fjh: could do near end of 1st day
... will be chairing another group early next week so better to contact me this week

<fhirsch> upcoming meetings

<fhirsch> http://www.w3.org/2008/xmlsec/Group/Overview.html#upcoming-meetings

<fhirsch> Call for Exclusions for Canonical XML 2.0, XML Signature 2.0

<fhirsch> http://lists.w3.org/Archives/Member/member-xmlsec/2009Oct/0021.html

Minutes Approval

<fhirsch> http://lists.w3.org/Archives/Member/member-xmlsec/2009Oct/att-0019/XML_Security_Working_Group_Teleconference_--_20_Oct_2009.htm

RESOLUTION: Minutes from 20 Oct approved

Editorial Updates

<fhirsch> FPWD of Canonical XML 2.0 and XML Signature 2.0 published

<fhirsch> http://www.w3.org/News/2009#entry-8635

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2009Oct/0058.html

fjh: thanks to editors

Renaining 1.1 Issues

<fhirsch> action-406?

<trackbot> ACTION-406 -- Magnus Nystrom to make proposal on list to address SP80056AConcatKDF in XML Encryption 1.1 concern -- due 2009-10-27 -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/actions/406

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2009Oct/0065.html

magnus: responding to pdatta comments to simplify

fjh: this addresses clarification requested by pdatta

magnus: could clarify that alg id is one byte
... do we need supplementary info?

bal: worry that it won't conflict with a use of NIST XML DSIG

magnus: orginal issue remains, need to be clear

bal: need to lengthen field of define seperator char

magnus: I proposed one solution

bal: NIST is targeting a smime env
... has to be some contribution from each side for mutual auth
... may not be good to profile out

magnus: could identify party u with certificate

bal: may not be able to guarentee introp
... not sure we can narrow it down

magnus: if we don't narrow it down, we still have to define how to parse the subtrees

bal: how does platform support multiple usecases?
... need to adress separability of fields

fjh: 2 questions
... choice between xml and binary, chose binary because we are processing certs?

magnus: yes

fjh: are we going to be ready for last call if we make these changes?
... what are interop implications?

bal: if creator provides 5 data items, impl must make use of them
... don't have to test every combination

fjh: need to clarify how binary is laid out
... is everybody ok with approach?

magnus: go back to 800-56 make clear encoding
... deployments need private agreements
... state that encoding is as specified by 800-56
... will have to know what to expect in sub fields

fjh: its like certs, don't define cert layout

bal: about concern to separate fields: when do you ned to do that?

pdatta: need clarity on encoding

bal: agree, but don't have to split binary stream

pdatta: we have to leave it up to application

magnus: need to make it clear that encoding is as in 800-56, but not specifying field contents - app specific
... its the best we can do

<fhirsch> magnus proposal - encoding as in 800-56, sender and receiver need to agree, and can use encoding as needed, this spec does not define encoding

pdatta: need to clarify encoding - not clear

bal: need to say they are already encoded when put in hex binary

<fhirsch> pratik suggests stating that already length encoded when placed into hex binary

pdatta: +1

magnus: app knows length of fixed length fields

pdatta: seems too loose for interop

magnus: brian and I could work on proposal for discussion at f2f

magnus: brian & I will propose text saying encoding is as 800-56 and apps must know field contents

<fhirsch> action-406:propose text saying encoding is as 800-56 and apps must know field contents

brian: we need to instruction enc implementors

<fhirsch> action-406: instructions to potential implementers so they get it right, already length encoded

<trackbot> ACTION-406 Make proposal on list to address SP80056AConcatKDF in XML Encryption 1.1 concern notes added

brian: just need to concatenate fields and feed to alg

<fhirsch> action-406: propose text saying encoding is as 800-56 and apps must know field contents

<trackbot> ACTION-406 Make proposal on list to address SP80056AConcatKDF in XML Encryption 1.1 concern notes added

bal: need to clarify text

fjh: need to agree for last call

Relax NG

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2009Oct/0036.html

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2009Oct/0048.html

Ed: looked over schema, not too detailed, didn't see anything wrong
... nice thing in spec is RelaxNG has more expressiveness in several ways
... might be a good idea to derive normal schema from RelaxNG
... does author have access to our mailing list?

fjh: not sure - will check

<fhirsch> ACTION: fjh check on status of Makoto email list access [recorded in http://www.w3.org/2009/10/27-xmlsec-minutes.html#action01]

<trackbot> Created ACTION-415 - Check on status of Makoto email list access [on Frederick Hirsch - due 2009-11-03].

Ed: looks like he is focussed on one app

<fhirsch> ed asks - should relaxng be normative and derive our XSD from it

Ed: example of customizing schema for a single app - good example of technique
... will use version of sig used by office open xml

<fhirsch> ACTION: fjh ask Makoto re 1.1 relax ng schema [recorded in http://www.w3.org/2009/10/27-xmlsec-minutes.html#action02]

<trackbot> Created ACTION-416 - Ask Makoto re 1.1 relax ng schema [on Frederick Hirsch - due 2009-11-03].

fjh: xsd is normative

Ed: wasn't suggesting RelaxNG be normative

<fhirsch> ed - non-normative relaxng - produce xsd which is normative

Ed: use editing strategy to produce schema from RelaxNG

fjh: know of tool to do this?

Ed: some tools available
... should be easy to write a XSLT stylesheet

fjh: are you volunteering?

Ed: would like to do, but have other higher priority items

fjh: let us know

Requirements Issues

<fhirsch> prefix rewriting

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2009Oct/0062.html

<esimon2> Specifically, I said that it should be easy to write an XML Signature-specific XSLT stylesheet for converting an XML Signature RELAX NG schema to an XML Signature XML Schema.

fjh: is this acceptable? will edit before f2f
... propose that if not comment by Thurs, will edit doc

<fhirsch> proposed resolution - accept proposed requirements change for prefix rewriting unless changes proposed in email by Thur

RESOLUTION: accept proposed requirements change for prefix rewriting unless changes proposed in email by Thur

<fhirsch> proposed requirements changes

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2009Oct/0063.html

fjh: propose we make current doc 1.1 requirements
... create 2.0 requirements
... remove long term sigs requirements
... remove wss stuff about 2.0
... general cleanup
... can we agree on that?

csolc: +1

<fhirsch> proposed resolution - accept "proposed changes to XML Security Requirements - revised"

RESOLUTION: accept "proposed changes to XML Security Requirements - revised"

<fhirsch> ACTION: fjh update requirements as proposed [recorded in http://www.w3.org/2009/10/27-xmlsec-minutes.html#action03]

<trackbot> Created ACTION-417 - Update requirements as proposed [on Frederick Hirsch - due 2009-11-03].

<fhirsch> issue-68?

<trackbot> ISSUE-68 -- Enable generic use of randomized hashing -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/68

<fhirsch> hal notes can solve problem by using stronger hash function, simpler

<fhirsch> bal notes theoretical advantages to randomized hashing - proofs possible

<fhirsch> not considering for 1.1, asking if needed as 2.0 feature

<fhirsch> proposed resolution - not considering randomized hashing for 1.1 or currently for 2.0, but could consider later

<esimon2> Can we open an Issue for deferred Issues? Basically an Issue solely for listing deferred issues?

RESOLUTION: not considering randomized hashing for 1.1 or currently for 2.0, but could consider later

<fhirsch> issue-68?

<trackbot> ISSUE-68 -- Enable generic use of randomized hashing -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/68

<fhirsch> action-402?

<trackbot> ACTION-402 -- Frederick Hirsch to document issue-136 requirement, prefix rewriting -- due 2009-10-20 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2008/xmlsec/track/actions/402

<fhirsch> issue-139?

<trackbot> ISSUE-139 -- Need to collect streaming XPath requirements -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/139

Ed: not going to make proposal
... just providing info
... establishing reqs is a good first step

<fhirsch> Plan to agree at TPAC F2F to publish update to Requirements at f2f

fjh: will leave Issue 139 open

Open Actions and Issues

<fhirsch> http://www.w3.org/2008/xmlsec/track/actions/open

<fhirsch> action-410 closed

<trackbot> ACTION-410 Review updated relaxng schema closed

<fhirsch> action-376 closed

<trackbot> ACTION-376 Start a discusson on the list to schema XMLDSIG-1.1 validation closed

<fhirsch> http://www.w3.org/2008/xmlsec/track/issues/open

<fhirsch> issue-142?

<trackbot> ISSUE-142 -- Is a single schema needed for XML Signature 1.1 to validate against, given that we have 2nd edition schema plus 1.1 additional schema -- OPEN

<trackbot> http://www.w3.org/2008/xmlsec/track/issues/142

<fhirsch> issue-142: resolved with proposal from henry thompson

<trackbot> ISSUE-142 Is a single schema needed for XML Signature 1.1 to validate against, given that we have 2nd edition schema plus 1.1 additional schema notes added

<fhirsch> isuse-142 closed

RESOLUTION: WG Thanks Kelvin Yiu for his work

<fhirsch> issue-142 closed

<trackbot> ISSUE-142 Is a single schema needed for XML Signature 1.1 to validate against, given that we have 2nd edition schema plus 1.1 additional schema closed

Summary of Action Items

[NEW] ACTION: fjh ask Makoto re 1.1 relax ng schema [recorded in http://www.w3.org/2009/10/27-xmlsec-minutes.html#action02]
[NEW] ACTION: fjh check on status of Makoto email list access [recorded in http://www.w3.org/2009/10/27-xmlsec-minutes.html#action01]
[NEW] ACTION: fjh update requirements as proposed [recorded in http://www.w3.org/2009/10/27-xmlsec-minutes.html#action03]

[End of minutes]

XML Security Working Group Teleconference 27 Oct 2009