XML Security Working Group Teleconference
09 Jun 2009

<trackbot> Date: 09 June 2009

<trackbot> Meeting: XML Security Working Group Teleconference

<trackbot> Date: 09 June 2009

<scribe> Scribe: Cynthia Martin

<tlr> Scribe: Cynthia

<tlr> ScribeNick: cynthia

<scribe> Chair: Frederick Hirsch

Agenda

Need scribe for next week

RESOLUTION: June 30 call cancelled

fjh: May need to touch base in August, any issues with adding meeting

RESOLUTION: Aug 11 conference call scheduled

<fjh> Widget Signature changed to require Exclusive XML Canonicalization 1.0

<fjh> (omits comments) instead of Canonical XML 1.1

<klanz2> AGENDA: http://lists.w3.org/Archives/Public/public-xmlsec/2009Jun/0021.html

<fjh> http://dev.w3.org/2006/waf/widgets-digsig/

References to signature v.1.1

<fjh> W3C Publication Moratoria for 2H09

<fjh> 31 October - 8 November

<fjh> 23 December - 3 January

Would like a consensus on publishing some of the documents soon

Modify agenda to allow Kelvin to speak

<esimon2> I'll have to be in and out for most of this meeting.

AES Key Wrap

Kelvin sent out an example yesterday on mailing list

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

How is this related to Magnus' work?

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

Kelvin: Magus work is over RSA

Is this an alternative to Magus work?

<bal> the difference between the two is in the way the content encryption key is derived

we are loosing sound on this call

Introduce a new key encryption/wrap scheme

Is this schema different than Suite B?

Yes, it is, key encapsulatin code

Magnus- introduce key encapsulation but not a replacement

Key encapsulation- similar treatment for RSA or EC, possibly easier implementation

May be some value to have this in draft

Goals for today- accept work and review

Potential multiple ways to do the operations for different contexts

Possible action to draft text

We are at a point were the WG could accept this text

WOuld like to reach some sort of conclusion very soon- Kelvin, Brian?

Don't we need the text first, some of it is in email text

This is optional, none of this is mandatory? Is this correct?

bal: We would not add any mandatory implements- need to see the real text

wiLL DO

Brian: This is important, need the text
... If this is mandatory, this impacts implementors

Frederick: Any suggestions, next steps?

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

Pratick: is ECIS is in Suite B

Add Scott to call

Frederick: need a more concrete proposal for text

Cynthia: yes we need more formal text

Brian: need to see the text and what is mandatory, what does it look like

Frederick: there is benefit to what Magnus has done

Brian: yes, there is benefit and formal proofs, how much extra work for v1.1 implementors
... is this an optional add on, change in code structure
... Magnus is proposing a more generalized option for the spec

Frederick: what is the next step? Additional text?
... edit doc?

Magnus: Yes, edit the doc and let the WG review
... what is the impact on implementors, possible to recommend but not mandatory

Brian: If in v2.0 it will be mandatory, then you would want people to implement in v1.1

Brian: is this any more difficult to implement than government standards

Magnus: we don't know

Brian: Mandatory to implement in v2.0?

Magnus: symantics for encapsulation- optional, recommended, does not need to be decided now

Brian: need to decide where this is going for v2.0

Cynthia: yes,

Frederick: we need to think about this

Magnus: will check with WG about normative

I can do it if you want

<magnus> ACTION: magnus to check with IETF SMIME on KEM normative statements [recorded in http://www.w3.org/2009/06/09-xmlsec-minutes.html#action01]

Frederick: make a decision?

Brian: no, we need a concrete proposal in writing- with readlines

Cynthia: I agree, we need a formal text

Magnus: we don't have a resolution yet for readline

<tlr> proposed: group agrees to further pursue Magnus' proposal, will look at red-line

Frederick: Readline without checking it in or private redline

Brian: can use private readline, no check in?

RESOLUTION: group agrees to further pursue Magnus' proposal, will look at red-line

Magnus: need surrounding text and normative use statement
... does it have an impact on the remaining text?

<klanz2> we have CVS ?

Frederick: We don't want edits without publication, may need to wait a week or two

Brian: Last call, tradeoff

Thomas: useful goal to get earlier review and back off on something

<klanz2> +1 to editors note along the line ... RESOLUTION PENDING

Frederick: leave it up to Magnus to add the information

Magnus: can this be sent to WG without full review

Frederick: checking it in would be easier for everyone, control system

Brian: check in is not as important, does not apply that it has been approved by Wg

Frederick: will be difficult to undo a checkin- avoid needless work

Thomas: agree, if Magnus is willing to back it off later, it would work

Frederick: may not have too many edits anyway
... may be close to agreement soon, WG seems to want it in the document
... proposal on agenda, is something missing Steve?

Who is speaking?

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

Frederick: where was it in last weeks agenda?

Magnus: link into last weeks agenda

Frederick; done

<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2009May/0009.html

Minutes Approval

Frederick: minutes approval

<fjh> http://www.w3.org/2009/06/02-xmlsec-minutes.html

Frederick: corrections? can we approve

RESOLUTION: minutes from June 2 are approved

can't hear you

Errata approval

got it

<fjh> http://www.w3.org/2008/06/xmldsigcore-errata.html

Frederick: signature errata needs approval today, EC1
... E01

RESOLUTION: XMLSEC E01 is approved

Frederick: E02 approval

<fjh> proposed E02

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

Frederick: section 9 having RDF and example, remove RDS and keep schema
... do we need more time?

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jun/att-0018/xmldsigcore-errata.html

Frederick: look at it now (review text)

Cynthia: agree with changes

Frederick: issues or accept?

RESOLUTION: accept E02 errata

<tlr> ACTION: thomas to update errata document for XML Signature as resolved here [recorded in http://www.w3.org/2009/06/09-xmlsec-minutes.html#action02]

<magnus2> Found it: http://lists.w3.org/Archives/Member/member-xmlsec/2009May/0009.html

key derivation function

Frederick: Magnus remind us of topic

Magnus: something I found in looking up text
... key derivation method in the agreement method

<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2009May/0009.html

Brian: trying to find the changes to be proposed, see link in chat

Magnus: not suggesting not to use KDF

Brian: would make the document mandatory to implement- KDF

<fjh> magnus proposal to leverage derived key schema

Magnus: make it necessary to understand, generality

Brian: need to think this through, mandatory items should be in main document
... make sure we mandate Suite B and NIST requirements

Magnus: no difference in performance than Suite B, from schema perspective, need to be general
... why not specify the KDF, than you don't need a new schema function in v1.1

Brian: why are they separate?

Magnus: can be separate or not, supporting KDF with ECDH

Magnus/Brian: balence between generality and specifics

<fjh> derived key document is only 7 pages with references and cover sheet etc, so merging material into core would not be a major issue in terms of amount of material to add

Magnus: post issues down the road when we have specifics

almost lost connection to network- just a warning on this side

Brian: add on documents and options, secondary documents are not mandatory

Frederick: made it a separate document, might need to be brought back into the main spec
... do we want to bring it into main spec?
... we we have a problem bringing this into the schema doc?

Brian: can't answer this today based on implementation

Pratik: examples in emails

<scantor> if ECCDH were mandatory, the requirement to support that one KD function seemed to make the basic notion of KD mandatory in that case, so moving the structure for KD back into the main doc seems to make sense

Magnus: if ECHD is mandatory, we implement KDF

Frederick: good feedback on what we should do with this, how do we go forward?

Brian: it will not take long, query and get answer soon

<magnus2> I can probably draft the KEM text before the next call.

Frederick: talk about this next week
... any decisions to make now?

Magnus: Give another week to talk to the organizations

Frederick: any others to add?

Bruce: Form the IBM - ECHD is not mandatory, KDF is not part of encryption support, not support mandatory

Magnus: parse this more, not in favor of KDF for mandatory for any ECDH implementation
... Bruce- no mandatory

Bruce: yes
... yes

Brian: question to Bruce, if used with standards DH, do you support this? Agreement?

<fjh> brian notes ok to have mandatory kdf for those that implement elliptic curve, as long as not generally manadatory

Bruce: depends on what we have

- standard DH, not standards DH

Magnus: we don't know what the outcome of EC will be yet

<fjh> brian suggests one mandatory KDF that can have either DH or ECDH

Frederick: how do we get to a proposal for this?
... we are pretty close?

<bal> My question to Bruce was whether IBM had any objection to specifying SP800-56A KDF as mandatory for D-H. Related question for the WG: should we consider picking one KDF as mandatory-to-implement in XMLENC independent of the D-H vs. ECDH choice?

Frederick: is there any action on this proposal? Brian?

Brian: don't know yet, may be ECDH/DH question
... single agreement method defined in section 5.5.2
... have we overly constrained that?

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

Brian: will circle with Kelvin on this, make ECDH and DH equivalent and general

<fjh> note brian and kelvin to review if possible to generalize/unify dh and ecdh mechanisms

Bruce: tenative information on list before next meeting

Brian: let us know about NIST KDF information

Frederick: are we done for today?

Magnus: yes

<fjh> X.962 vs SEC 1 version 2.0 reference in XML Signature 1.1

X.962 vs SEC 1 version 2.0 reference in XML Signature 1.1

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

Magnus: how to generate randomly verifiably random curves

Frederick: I thought we already referenced the sec doc

Magnus: not that I am aware of

Frederick: what is the suggestion?

Magnus: replace the text with the correct reference

Frederick: good move

<fjh> proposed resolution - update SEC 1 reference in Signature 1.1 to version 2.0, remove X.962 reference and refer to SEC 1 v2 instead

<klanz2> I'll forward to some people ...

Frederick: any problem with the proposed resoltuion?

<klanz2> ... let's all double check

RESOLUTION: update SEC 1 reference in Signature 1.1 to version 2.0, remove X.962 reference and refer to SEC 1 v2 instead

<scribe> ACTION: Magnus implement SEC 1 resolution [recorded in http://www.w3.org/2009/06/09-xmlsec-minutes.html#action03]

<fjh> Aligning Signature 1.1 and Encryption 1.1

Aligning Signature 1.1 and Encryption 1.1

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

<klanz2> Do you have a link for SEC 1 version 2.0 ?

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

Frederick: inconsistancy between the documents, security weaknesses, increased risk
... how should we note this in the documents? Comments?

Cynthia: I would note it in the document so it can be discouraged and put a limit to stop use

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

<klanz2> From my knowledge RIPEMD-160 seems not to suffer the weaknesses SHA-1 suffers ...

Magnus: we should be consistant

Thomas: the current situation review of SHA-1 and other risks- general adoption

<fjh> tlr notes concern regarding not saying any warning for RSA-SHA1

<fjh> tlr either have note warning and/or compliance requirement

<fjh> require but discourage use, vs only recommending etc

Magnus: For SHA1, HMAC-SHA1, RSA-SHA1, etc the approaches are somewhat consistant, but not all

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

Magnus: should try to find a unified way, required implementation/verification

Frederick: need a concrete proposal and general approach

<klanz2> Oly found this proposal? http://www.secg.org/collateral/proposal-for-sec1v2.pdf

Frederick: reason for generation/verification for compatability

Magnus: SHA1 generation/verification code is different?

<klanz2> here we go: http://www.secg.org/?action=secg,docs_secg is it that one?

Frederick: addresses some of the problems, but not all of the problems? Did not go all the way

<magnus2> Cynthia, it is TLR speaking, not me...

thanks- still working on the voices

<fjh> required, use discouraged vs use for generation vs verification

<Gerald-e> can we say it these are required for backward compatability, but use for signing purposes is strongly discouraged ?

<fjh> proposal put Discouraged on RSAwithSHA1

cynthia: agree with this

<klanz2> I need to leave now, bye bye

<fjh> proposal put Use Discouraged on RSAwithSHA1 and DSAwithSHA1 in http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-Algorithms

RESOLUTION: put use Discouraged on RSAwithSHA1 and DSAwithSHA1 in http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-Algorithms

Frederick: volunteer to make the change?

<scribe> ACTION: Magnus will make these changes [recorded in http://www.w3.org/2009/06/09-xmlsec-minutes.html#action04]

<trackbot> Created ACTION-310 - Will make these changes [on Magnus Nyström - due 2009-06-16].

<fjh> RIPEMD-160

RIPEMD-160 discouraged in future

Thomas: not as much as a problem as SHA1, limitiations on algorithm length, not strength

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

Frederick: don't do anything for now? is everyone ok?

RESOLUTION: do not need to add a warning for RIPEMD-160

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

Frederick: need to look at this- cypher reference
... don't need to do anything- Magnus?

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

Magnus: nothing in particular in mind
... we don't have a transform element , should there be one?

<fjh> "The syntax of the URI and Transforms is similar to that of"

Frederick: may need to review this more

<fjh> issue: review transforms for encryption

<trackbot> Created ISSUE-135 - Review transforms for encryption ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/135/edit .

Requirements

<esimon2> We may want to specifically mention the Pratik transform in the next version of XML Encryption, but that is tbd.

<fjh> Missing byte range use case and requirements

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

Frederick: running out of time

Chris: proposal for cannonicalization

Frederick: I could add this

ACTION:Frederick add byte range use case and requirements

Frederick: missing sub-sections
... still open items, references, etc- action for normative

<fjh> references in signature and encyption need review for currency, and to split informative and normative

Thomas: need to review where we are in the references, normative and informative

<fjh> ACTION-159?

<trackbot> ACTION-159 -- Brian LaMacchia to include errata into the 1.1 documents -- due 2009-01-20 -- CLOSED

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

<fjh> action-158?

<trackbot> ACTION-158 -- Thomas Roessler to take pass through references in Dsig Core - update, split into normative/informative -- due 2009-03-30 -- OPEN

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

Frederick: on the list for along time, need help with this action

Cynthia: let me look at it, work and schedule

<fjh> ACTION-256 completd

Frederick: Thomas action 256- done and 284 is done

<tlr> ACTION-256 closed

<trackbot> ACTION-256 Update xref note with addtl type Uris closed

<tlr> ACTION-284 closed

<trackbot> ACTION-284 Implement resolution concerning SHA-1 OIDs in 6.4.2 of XML Signature closed

Frederick: 2 issues based on emails

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

<fjh> ISSUE-133?

<trackbot> ISSUE-133 -- Update Exclusive C14N Schema -- OPEN

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

<fjh> http://www.w3.org/2002/07/xml-exc-c14n-errata

<fjh> E02 2002-10-03 (Error)

Frederick: erreta 2 issue

trackbot is off again

<fjh> ISSUE-134?

Frederick: issue 134

ISSUE=134

<fjh> Camellia algorithm

<fjh> for section of 5.2 Block Encryption Algorithm and 5.6 Symmetric Key Wrap for XML Encryption 1.1

Frederick: the NTT proposal for Camellia algorithm is not in the document

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

Magnus: we don't have every algorithm in the document, but if we do it should be optional

<Gerald-e> http://lists.w3.org/Archives/Public/xml-encryption/2002Oct/0010.html

Gerald: using it in Japan (and EU)

Brian: comes up in the IETF all the time, mandatory/optional, parallel specs for Japanese companies
... it is in the RFC, but not the XML spec

<tlr> +1 to not bothering if this is specified already

Brian: why do we need to import it, is it a new variant- implementation requests?

The EU has the same competion similar to NIST for encyrption algorithms

Frederick; may be some advantages to make this optional

Frederick: publicaiton of drafts, signature
... when do we want to update the signature drafts? we have new information

<esimon2> I'm still working on the XPath Transform NS issue and that might affect the XMLSig errata

Frederick: should we publish as they are now or wait?

Magnus: wait a bit, to resolve some of the issues discussed today

<tlr> +1

Frederick: right thing to do is wait, but Thomas will not be around

<Gerald-e> the link I had sent has a reference to Camellia

Thomas: anything that is not ready to go should be ready in a few days
... the pieces that are do and be done by everyone, someone would have to do the grunt work, publication check, link check

Frederick: are we really ready even with the EC issue, may need to delay last call until Aug meeting
... could publish working draft in July, and resolve EC by Aug
... peronal approach, get documents stable and then publish, may have to wait until Thomas gets back
... issues with pub rules, may be difficult to do it without Thomas

Cynthia: agree, I am not familar with the pub rules either, we could look outside the group to the W3C but it may be a problem

<tlr> ACTION: thomas to teach Frederick how to tame the pubrules dragon [recorded in http://www.w3.org/2009/06/09-xmlsec-minutes.html#action05]

<trackbot> Created ACTION-311 - Teach Frederick how to tame the pubrules dragon [on Thomas Roessler - due 2009-06-16].

Thomas: run one spec throught the process to see if we are ready

Frederick: which docs should be published
... run out of time again
... any other business

What about scibe next week?

I will do it again if yoiu don't mind