XML Security Working Group Teleconference
05 May 2009

 

 

<trackbot> Date: 05 May 2009

<fjh> Scribe: Bruce Rich

<fjh> Agenda: http://lists.w3.org/Archives/Public/public-xmlsec/2009May/0001.html

<fjh> ScribeNick: brich

Administrative

<fjh> Next meeting: F2F #4: 12-13 May, 9:00-18:00 ET each day

<fjh> Hosted by RSA (EMC), Bedford MA, logistics: http://lists.w3.org/Archives/Member/member-xmlsec/2009Mar/0015.html

<fjh> Main building, check in at reception

<fjh> Name needs to be registered in advance

<fjh> correct f2f address is 170 Middlesex Turnpike, Bedford, MA

Announcements

<fjh> Signature Properties published 30 April

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Apr/0067.html

<fjh> http://www.w3.org/TR/2009/WD-xmldsig-properties-20090430/

<fjh> Widget Signature LCWD published 30 April

<fjh> Please review and provide comment before 1 June 2009

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009May/0000.html

<fjh> SHA-1 collisions in 2^52

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Apr/0064.html

<fjh> tlr notes sha1 eroding faster than anticipated

bal: expect to see demonstration of sha1 collision by this summer

bal: second pre-image will be later (meaningful, purposeful exploitation)

<fjh> bal notes risk is large even though cannot collide with a given doc but CA attack occurred re intermediate ca

<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-AlgID

fjh: so what do we do about sha1 rqd?

hlockhar: birthday approach renders attacks feasible soon

<tlr> I think we say something like that already

hlocklar: rqd for back compat but not recommended

<fjh> Make RSAwithSHA1 Required but note that only for backward compatibility

<tlr> This specification defines several possible digest algorithms for the DigestMethod element, including REQUIRED algorithms SHA-256 and SHA-1. Use of SHA-256 is strongly recommended over SHA-1 because recent advances in cryptanalysis have cast doubt on the long-term collision resistance of SHA-1. However, SHA-1 support is REQUIRED in this specification to support interoperability with implementations of prior versions of this specification.

fjh: algorithm section 6.1 may require some adjusting

tlr: may want to warn about sha1, just as do md5

<fjh> Needs statement in 6.1 section as well

previous discussion is relative to sig 1.1

<fjh> Two proposed changes - in 6.1 state for RSAwithSHA1 Required , adding for interoperability, see section 6.2

<tlr> http://www.w3.org/TR/xmldsig-core1/#sec-MessageDigests

<fjh> also make HMACwithSHA256 required

RESOLUTION: Make RSAwithSHA1 required back-compat only and require HMACwithSHA256

<tlr> "IMPLEMENTATION required; use NOT RECOMMENDED"

<fjh> magnus text should say not recommended for new application

<scribe> ACTION: magnus to draft some text for revision of 1.1 per above resolution [recorded in http://www.w3.org/2009/05/05-xmlsec-minutes.html#action01]

<trackbot> Created ACTION-268 - Draft some text for revision of 1.1 per above resolution [on Magnus Nyström - due 2009-05-12].

<fjh> crypto conference in August might have collision demonstration

<fjh> tlr notes home page should call out change and reason related to SHA1

tlr: suggests may need erratum on Sig 1.0

<fjh> issue erratum for Signature 1.0 and use of SHA256 in favor of SHA1

<fjh> issue: http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-AlgID

<trackbot> Created ISSUE-118 - Http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-AlgID ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/118/edit .

<fjh> issue: erratum for Signature 1.0 and use of SHA256 in favor of SHA1

<trackbot> Created ISSUE-119 - Erratum for Signature 1.0 and use of SHA256 in favor of SHA1 ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/119/edit .

<fjh> ISSUE-118 closed

<trackbot> ISSUE-118 Http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-AlgID closed

<tlr> ACTION: thomas to propose SIgnature 1.0 erratum on SHA 256 - due 2009-05-30 [recorded in http://www.w3.org/2009/05/05-xmlsec-minutes.html#action02]

<trackbot> Created ACTION-269 - propose SIgnature 1.0 erratum on SHA 256 [on Thomas Roessler - due 2009-05-30].

Minutes approval

<fjh> http://www.w3.org/2009/04/28-xmlsec-minutes.html

<fjh> Add Shivaram Mysore to attendees list

RESOLUTION: Minutes from 28th April approved

Editorial update

<fjh> new ISSUE-117, Key Wrap

<fjh> ISSUE-117?

<trackbot> ISSUE-117 -- Key Wrap -- OPEN

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

<fjh> question as to whether text can be removed from XML Encryption if it is the same as RFC or is it different and needed?

<fjh> bal notes if text removed would need clear pointer to other reference

tlr: would need to compare current text with that in IETF docs to see if reference is appropriate

<tlr> I suggest 31 May as a due date, perhaps?

<scribe> ACTION: magnus to compare text of IEFT encryption to that in current draft - due 2009-31-05 [recorded in http://www.w3.org/2009/05/05-xmlsec-minutes.html#action03]

<trackbot> Created ACTION-270 - compare text of IEFT encryption to that in current draft [on Magnus Nyström - due 1970-01-01].

<tlr> action-270?

<trackbot> ACTION-270 -- Magnus Nyström to compare text of IEFT encryption to that in current draft -- due 1970-01-01 -- OPEN

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

<tlr> (time_t) 0

<scribe> ACTION: bal to compare text of IEFT encryption to that in current draft - due 2009-05-31 [recorded in http://www.w3.org/2009/05/05-xmlsec-minutes.html#action04]

<trackbot> Created ACTION-271 - compare text of IEFT encryption to that in current draft [on Brian LaMacchia - due 2009-05-31].

<fjh> DerivedKey schema posted by Magnus

<tlr> http://www.w3.org/2008/xmlsec/Drafts/derived-key/dkey-schema.xsd

tlr: would need an update to the spec with a formal reference to schema

<fjh> tlr notes need to include schema in updated publication of Derived Key, which would have TR URI for schema, so this URI should not be referenced

magnus: group interested in schema ok with draft reference for now

<scribe> ACTION: magnus to update editor's draft of Derived Key spec to reference the schema with TR URI [recorded in http://www.w3.org/2009/05/05-xmlsec-minutes.html#action05]

<trackbot> Created ACTION-272 - Update editor's draft of Derived Key spec to reference the schema with TR URI [on Magnus Nyström - due 2009-05-12].

Interop

mullan: has sent around zip file of generated signatures, looking for feedback, not yet in CVS

fjh: can modify script to deal with directory structure changes

tlr: those with access to drafts should have access to interop directory too

<fjh> agreement of interop participants to use interop directory structure that Sean sent

<fjh> http://www.w3.org/2008/xmlsec/wiki/InteropPlanning

mullan: do not expect to complete OCSP examples

<mullan> will add signatures testing new SHA DigestMethod & SignatureMethod algs

<mullan> maybe xpath 2.0 and exc c14n later in week

mullan: has no plan to add encryption

<fjh> sean notes no plans for encyption, AES Keywrap with padding

bal: expect to upload some testcases when has access

Algorithm URIs

postponing topic for now

F2F agenda

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

fjh: requests agenda review before meeting
... idea was that interop would be attempted before meeting
... Pratik sent out some performance numbers
... would be useful to demonstrate with numbers that we've improved things
... constrained c14n, pratik sent info to list already

Algorithm URIs

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

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009May/0006.html

tlr: additional URIs requested
... question need for "PLAIN" variant
... URI for WHIRLPOOL alg?

<tlr> tlr: URI for whirlpool?

<tlr> tlr: where do the plain variants come from?

<tlr> -1

<fjh> konrad suggests documenting plain variant so the choices are explicit and the wrong one is not used by mistake

<fjh> no info on why plain variant was proposed

<fjh> thomas concerned about bitwise concatenation

<fjh> thomas would rather ask that plain be removed entirely from the world

<scribe> ACTION: tlr to followup on PLAIN variant [recorded in http://www.w3.org/2009/05/05-xmlsec-minutes.html#action06]

<trackbot> Created ACTION-273 - Followup on PLAIN variant [on Thomas Roessler - due 2009-05-12].

<klanz2> http://www.w3.org/2007/05/xmldsig-more#ecdsa-ripemd160

<fjh> http://www.w3.org/2007/05/xmldsig-more#ecdsa-ripemd160 in use already according to konrad

<klanz2> that one should really stay, has been in draft and is in use

<tlr> +1

<fjh> action is for followup with BSI

Best practices

<fjh> action-127?

<trackbot> ACTION-127 -- Thomas Roessler to draft text on trade-off between different extensibility mechanisms, for BP draft -- due 2009-03-30 -- OPEN

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

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0003.html

fjh: anybody have any responses for this?

<fjh> tlr - meaning of well-known transforms versus xslt was question

<fjh> tlr: question regarding intermediaries verifying signatures, with xslt inline, but not with transform identified via uri?

<fjh> tlr asks if important use case or not

<fjh> tlr means verifier not soap intermediary

<fjh> hal appliance boxes can be configured. need to ask vendors

<fjh> brad notes most do not support xslt at all

<klanz2> http://www-01.ibm.com/software/integration/datapower/xa35/

<fjh> action-126?

<trackbot> ACTION-126 -- Ken Graf to call out local system access risks regarding XSLT -- due 2008-12-23 -- CLOSED

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

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0001.html

fjh: adopt now? talk about at F2F?

<fjh> Best Practice #: When XSLT is required disallow the use of user-defined extensions

klanz2: talked earlier about how to mitigate risk and have well-defined transforms

<klanz2> https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=90836#page=103

<klanz2> section 4.2.4

RESOLUTION: Adopt Ken's proposed addition to Best Practices

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0001.html

<scribe> ACTION: fjh to update best practices with this addition [recorded in http://www.w3.org/2009/05/05-xmlsec-minutes.html#action07]

<trackbot> Created ACTION-274 - Update best practices with this addition [on Frederick Hirsch - due 2009-05-12].

<fjh> Best practice on XPath Filter 2.0 preference

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

<klanz2> http://tinyurl.com/XSLT-in-XMLDSIG that was the tinyurl I had created for proper XSLT use, this however does not conflict with deprecated XSLT extensions

mullan: this practice was buried in some other discussions, wanted to highlight it

RESOLUTION: Adopt Sean's addition to best practices doc

<scribe> ACTION: fjh to update Best Practices doc, note that is RECOMMENDED [recorded in http://www.w3.org/2009/05/05-xmlsec-minutes.html#action08]

<trackbot> Created ACTION-275 - Update Best Practices doc, note that is RECOMMENDED [on Frederick Hirsch - due 2009-05-12].

<fjh> Best practices review comment

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/0030.html

<fjh> defer

XML Encryption 1.1

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0077.html

AES KeyWrap with padding

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0100.html

<fjh> Added to section 5.6.4 as OPTIONAL, time to revisit?

<fjh> Need to add to section 5.1 list of algorithms?

<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview.htm#sec-Alg-SymmetricKeyWrap

fjh: the question is optional or mandatory

<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview.htm#sec-AlgID

<tlr> yes, they should go into the list of algorithms

+1 to optional

<klanz2> abstain

<fjh> issue: keep AES KeyWrap with padding as optional

<trackbot> Created ISSUE-120 - Keep AES KeyWrap with padding as optional ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/120/edit .

<fjh> answer yes, keep as optional

<fjh> issue-120 closed

<trackbot> ISSUE-120 Keep AES KeyWrap with padding as optional closed

<tlr> ACTION: thomas to include keywrap-pad in 5.1 [recorded in http://www.w3.org/2009/05/05-xmlsec-minutes.html#action09]

<trackbot> Created ACTION-276 - Include keywrap-pad in 5.1 [on Thomas Roessler - due 2009-05-12].

<tlr> ACTION-276: xml encryption

<trackbot> ACTION-276 Include keywrap-pad in 5.1 notes added

fjh: would like TOC to go a level deeper to get better hyperlink access

<klanz2> tlr suggests reflexive links

<klanz2> right click copy link

Use case and requirements

<klanz2> what is the latest template/xslt styleshhet for notes

<fjh> will extend table of contents to deeper

<klanz2> I'd like to get going on c14n note

<fjh> Missing byte range use case and requirements

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Nov/0023.html

<klanz2> tlr do you have a link for me

<tlr> klanz, link to what?

<klanz2> the latest document templates for writing notes/specs etc ...

Action Item and Issue Review

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

fjh looking at public list

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009May/0003.html performance

pratik: comparing perf of different algorithms

<fjh> 3rd has 10 namespaces defined in beginning not used

pratik: will be checking these test files in
... nodeset example is the one where we see big variations in time
... using small (5k) file in all of these

<klanz2> how large is the portion of building up node-set

klanz2: bad perf may be in xpath processing itself

<fjh> pratik notes xpath evaluated for every node, hence a performance issue

<fjh> scantor notes that xpath and xslt should not be required to implement xml signature

<fjh> scantor notes it is more than a performance issue, also dependencies etc

mullan: took a while to get to these performance tweaks

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009May/0004.html pratik proposal

<fjh> key point to define in terms of subtrees not nodesets

pratik: note documents portions of spec that would need to change to accommodate subtree focus

<klanz2> why aren't the exclusion elements ordered?

<klanz2> why is the document at all out of order?

<klanz2> xml has a document order?

tlr: is there a testcase that causes subtree processing to "blow up"? like the nodeset "blows up" with many nodes

<klanz2> data structures used in such algorithms should be in document order

AOB

<klanz2> like the list of "The exclusion elements are not ordered in any way" SHOULD actually be in document order