XML Security Working Group Teleconference
12 Jan 2010

Administrivia

<fhirsch> new RSA factoring record (768-bit)

<fhirsch> http://eprint.iacr.org/2010/006.pdf

<fhirsch> bal can expect 10 yrs or less for 1024

minutes approval

<fhirsch> 5 January minutes

<fhirsch> http://www.w3.org/2010/01/05-xmlsec-minutes.html

RESOLUTION: 5 January minutes approved

Editorial Updates

fjh: added new schema section to signature properties

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2010Jan/0018.html

fjh: added rng schema
... added example document

<esimon2> I think python lxml supports rng validation

<fhirsch> ACTION: scantor to test validation of examples against rnc schema for signature properties [recorded in http://www.w3.org/2010/01/12-xmlsec-minutes.html#action01]

<trackbot> Created ACTION-487 - Test validation of examples against rnc schema for signature properties [on Scott Cantor - due 2010-01-19].

Best practices updated

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2010Jan/0022.html

added comments from Cynthia, some not applied that

had questions about

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2010Jan/0029.html

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2010Jan/0038.html

XML Signature updates ...

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2010Jan/0043.html

applied reference updates

<Zakim> Thomas, you wanted to say no to RFC 2231

tlr: rfc 2231 updates mime spec in rfc 2045
... suggest we don't update the reference

<tlr> Content-Type: text/plain; parameter="foo"

<tlr> Content-Type: text/plain; parameter*="...utf-8...%as%df..."

<fhirsch> tlr notes this would incorrectly imply that we use parameter syntax that we do not use

cynthia: makes sense, ok with previous ref

<fhirsch> proposed resolution: remove rfc 2231 references from signature 1.1 and encryption 11.

RESOLUTION: remove rfc 2231 references from signature 1.1 and encryption 1.1

Open XML Signature 1.1 Issues

<fhirsch> issue-82?

<trackbot> ISSUE-82 -- Should 1.1 spec mandate support for range of RSA key sizes (and DSA)? -- OPEN

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

fjh: bal already did this

<fhirsch> issue-82 closed

<trackbot> ISSUE-82 Should 1.1 spec mandate support for range of RSA key sizes (and DSA)? closed

<fhirsch> issue-91?

<trackbot> ISSUE-91 -- ECC can't be REQUIRED -- OPEN

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

tlr: reminder sent to rigo after dec. call
... have not heard back yet

fjh: wait until next week to go to last call?

brian, cynthia ok with waiting a week

bal: but blocked on hearing back from rigo

tlr: rephrase note if we don't get resolution

<fhirsch> tlr suggest revise note to say technical agreement to keep ECC required, but IPR might require change.

<fhirsch> ACTION: tlr to rephrase ECC note as appropriate, if needed [recorded in http://www.w3.org/2010/01/12-xmlsec-minutes.html#action02]

<trackbot> Created ACTION-488 - Rephrase ECC note as appropriate, if needed [on Thomas Roessler - due 2010-01-19].

tlr: will send a draft by email

<tlr> ACTION: thomas to cause another ping to Certicom [recorded in http://www.w3.org/2010/01/12-xmlsec-minutes.html#action03]

<trackbot> Created ACTION-489 - Cause another ping to Certicom [on Thomas Roessler - due 2010-01-19].

<bal> http://tools.ietf.org/html/draft-mcgrew-fundamental-ecc-01

<fhirsch> issue-149?

<trackbot> ISSUE-149 -- Link requirements to features -- OPEN

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

<fhirsch> close action-487

<trackbot> ACTION-487 Test validation of examples against rnc schema for signature properties closed

fjh: thinks shivram did issue 149

shivaram: just sent out encryption changes, signature is done

<fhirsch> No concern for signature 1.1 based on shivaram requirement review

<fhirsch> action-428?

<trackbot> ACTION-428 -- Frederick Hirsch to edit requirements 2.0 removing design section and exmples -- due 2009-11-13 -- CLOSED

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

<fhirsch> issue-149: action-428 resolved signature concerns

<trackbot> ISSUE-149 Link requirements to features notes added

<fhirsch> issue-158?

<trackbot> ISSUE-158 -- Add SHA-1 warnings -- OPEN

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

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2010Jan/0004.html

fjh: cynthia has suggested addtl references

<fhirsch> http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html

cynthia: do we want to reference original papers?

<tlr> http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html

<fhirsch> http://eprint.iacr.org/2004/304.pdf

cynthia: the paper is at very end of schneiers blog

fjh: also thinks it is better to ref a paper than a blog

cynthia: nist ref is not authoritative

hal: would the christoff (sp?) paper be good?
... will try to find link

<hlockhar> http://www.jucs.org/jucs_14_3/new_results_on_nmac

<fhirsch> ACTION: fjh attempt to validate signature properties against rnc schema [recorded in http://www.w3.org/2010/01/12-xmlsec-minutes.html#action04]

<trackbot> Created ACTION-490 - Attempt to validate signature properties against rnc schema [on Frederick Hirsch - due 2010-01-19].

hal: paper not just about collisions
... 80 bit hmacs not enough is conclusion

fjh: entering last call, don't want to keep modifying doc

<esimon2> I assume "rnc" should be "rng"

hal: will look into providing ref

<fhirsch> ACTION: hal to suggest reference for SHA-1 to list for XML Signature 1.1, indicating weakness of SHA-1 [recorded in http://www.w3.org/2010/01/12-xmlsec-minutes.html#action05]

<trackbot> Created ACTION-491 - Suggest reference for SHA-1 to list for XML Signature 1.1, indicating weakness of SHA-1 [on Hal Lockhart - due 2010-01-19].

fjh: must be done this week
... rnc is for compact form

<fhirsch> Will add reference Hal suggests to XML SIgnature 1.1 unless disagreement expressed on list

<fhirsch> issue-166?

<trackbot> ISSUE-166 -- RNG schema needed for Signature Properties -- OPEN

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

fjh: issue 166 can be closed

<fhirsch> issue-166 closed

<trackbot> ISSUE-166 RNG schema needed for Signature Properties closed

<fhirsch> issue-165?

<trackbot> ISSUE-165 -- Add note that standalone XSD file takes precedence when there is XSD schema file, XSD snippets in document and RNG schema - to XML Signature 1.1, Signature Properties, XML Encryption 1.1 and Generic Hybrid Ciphers -- OPEN

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

fjh: not done yet

all of docs has schema snippets in doc and standalone rng,xml schema docs

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2010Jan/0017.html

scribe: but need to say which has priority

<fhirsch> "The standalone XSD schema file takes precedence in case there is any disagreement between it and the XSD schema portions in this specification text or the RNG schema."

tlr: each of schema languages has slightly different ... there will be differences
... would prefer erratum than giving normative power to particular schema

scantor: worth saying standalone doc takes precedence over snippets

<fhirsch> scott suggests: The standalone XSD document takes precedence over XSD snippets.

<fhirsch> +1 to scott from tlr

tlr: ok with scott's suggestion

<fhirsch> which authoritative

<fhirsch> i would expect RNG to be more stringent than XSD and normative text more stringent than either

<fhirsch> issue: need review of Signature 1.1 schema snippets versus standalone XSD schema

<trackbot> Created ISSUE-169 - Need review of Signature 1.1 schema snippets versus standalone XSD schema ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/169/edit .

<fhirsch> ACTION: tlr to review XSD Signature 1.1 schema snippets vs standalone XSD 1.1 schema [recorded in http://www.w3.org/2010/01/12-xmlsec-minutes.html#action06]

<trackbot> Created ACTION-492 - Review XSD Signature 1.1 schema snippets vs standalone XSD 1.1 schema [on Thomas Roessler - due 2010-01-19].

<fhirsch> The full normative grammar is defined by the XSD schema and the normative text in the document

<fhirsch> ACTION: fjh to add text to documents regarding schema for ISSUE-165 to documents listed in isseu [recorded in http://www.w3.org/2010/01/12-xmlsec-minutes.html#action07]

<trackbot> Created ACTION-493 - Add text to documents regarding schema for ISSUE-165 to documents listed in isseu [on Frederick Hirsch - due 2010-01-19].

<fhirsch> issue-167?

<trackbot> ISSUE-167 -- Unicode NFC reference -- OPEN

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

<fhirsch> issue-167 closed

<trackbot> ISSUE-167 Unicode NFC reference closed

<fhirsch> issue-168?

<trackbot> ISSUE-168 -- Assorted normative reference updates -- OPEN

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

<tlr> yep, we fixed that one

<fhirsch> issue-168 closed

<trackbot> ISSUE-168 Assorted normative reference updates closed

<fhirsch> need sha-1 reference, schema snippet check, rng schema check, removal RFC2231

<tlr> removal of 2231 is done

<fhirsch> action-421?

<trackbot> ACTION-421 -- Ed Simon to look at the 1.1 schema -- due 2009-11-12 -- OPEN

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

<fhirsch> action-421 closed

<trackbot> ACTION-421 Look at the 1.1 schema closed

<fhirsch> action-350?

<trackbot> ACTION-350 -- Ed Simon to propose text to align node set result treatment for XSLT and XPath in 1.1 spec -- due 2009-08-04 -- OPEN

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

ed: will send email on nodeset issues and will close them

<fhirsch> action-431?

<trackbot> ACTION-431 -- Thomas Roessler to fix "they" in RFC2119 section throughout all documents -- due 2010-01-17 -- OPEN

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

tlr: leave it open as a reminder to check before publication

<fhirsch> action-449?

<trackbot> ACTION-449 -- Cynthia Martin to review 1.1 bibliographies (depends on ACTION-448) -- due 2009-11-24 -- OPEN

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

<fhirsch> action-449 closed

<trackbot> ACTION-449 Review 1.1 bibliographies (depends on ACTION-448) closed

Last Call

XML Signature 1.1 Readiness to Enter Last Call

<fhirsch> XML Signature 1.1 Readiness to Enter Last Call, plan for next week

fjh: will be ready next week assuming actions are done

<fhirsch> XML Signature Properties Readiness to Enter Last Call next week?

<fhirsch> Plan to enter last call next week unless new information suggests otherwise

Best Practices

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2010Jan/0019.html

comments from cynthia ...

fjh: did obvious ones that agreed with
... suggested remove hostile word, but think intent is to assume everyone is attacker; cynthia ok with that

<fhirsch> will make changes suggested in email to remove "Try to" in the two best practices

<fhirsch> signing namespaces - any recommended best practices

ed: still working on this one; it is a complex issue

<fhirsch> issue: should we recomend signing namespaces as part of Best Practice 12

<trackbot> Created ISSUE-170 - Should we recomend signing namespaces as part of Best Practice 12 ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/170/edit .

<fhirsch> issue-156?

<trackbot> ISSUE-156 -- Threat for signature from use of namespace prefixes with corresponding unsigned namespace declarations leading to wrapping like attacks -- OPEN

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

Requirements

<fhirsch> action-391?

<trackbot> ACTION-391 -- Gerald Edgar to see if issue-131 is covered in requirements doc -- due 2009-10-13 -- OPEN

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

<fhirsch> issue-131?

<trackbot> ISSUE-131 -- Is semantic equivalence robustness in requirements document -- CLOSED

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

<fhirsch> action-391 closed

<trackbot> ACTION-391 See if issue-131 is covered in requirements doc closed

fjh: can we publish them? ok

Open Issues for XML Encryption 1.1

<fhirsch> issue-150?

<trackbot> ISSUE-150 -- Use of XML encryption type encoding in EXI -- OPEN

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

<fhirsch> issue-154?

<trackbot> ISSUE-154 -- Links to references need to be updated from 2000 XML Rec to XML 1.0 5th Edition -- OPEN

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

<fhirsch> issue-154 closed

<trackbot> ISSUE-154 Links to references need to be updated from 2000 XML Rec to XML 1.0 5th Edition closed

<fhirsch> http://lists.w3.org/Archives/Public/public-xmlsec/2010Jan/0030.html

<fhirsch> added sentence: For details on the implementation of AES-GCM, see [SP800-38D].

bal: minor clarification

<fhirsch> also added at beginning "For the purposes of this specification,"

bal: aes-gcm defined as family of functions ... reword that we are choosing these

<fhirsch> etc

particular iv sizes for dsig only

RESOLUTION: accept AES-GCM proposal as proposed by magnus

<fhirsch> ACTION: fjh add revision of AES-GCM to xml encryption 1.1 [recorded in http://www.w3.org/2010/01/12-xmlsec-minutes.html#action08]

<trackbot> Created ACTION-494 - Add revision of AES-GCM to xml encryption 1.1 [on Frederick Hirsch - due 2010-01-19].

Generic Hybrid Ciphers

<Cynthia> please make sure the recommended parameters have text addressing interoperability and ability to determine those parameters

<fhirsch> issue-164?

<trackbot> ISSUE-164 -- RNG schema needed for Generic Hybrid Ciphers -- OPEN

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

fjh: we need an rng schema for this as well

bal: don't know rng; but may need help

<fhirsch> ACTION: fjh ask makoto regarding RNG schema for generic hybrid ciphers [recorded in http://www.w3.org/2010/01/12-xmlsec-minutes.html#action09]

<trackbot> Created ACTION-495 - Ask makoto regarding RNG schema for generic hybrid ciphers [on Frederick Hirsch - due 2010-01-19].

bal: we are speciying specific AES-GCM parameters - you don't have a choice
... so they will always interoperate
... can't use anything longer

cynthia: ok with brian's explanation

fjh: update acknowledgements for signature properties
... list workgroup members

2.0 docs

<fhirsch> action-443?

<trackbot> ACTION-443 -- Thomas Roessler to glue together the two pieces of today's irc log & minutes, and remove his twitter link while he's at it -- due 2009-11-14 -- CLOSED

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

<fhirsch> do we expect to mix 1.1 Reference and 2.0 reference in a single doc

<scantor> action-434?

<trackbot> ACTION-434 -- Scott Cantor to propose "final" disposition of Referencing syntax -- due 2009-11-13 -- CLOSED

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

<fhirsch> pratik argues 2.0 only so that only one form of C14N

<fhirsch> pratik notes missing URI might become an issue when there is a mixture

<fhirsch> scott not sure, but have no use case for mixing

<fhirsch> suggest going with 2.0 only to make it simpler and to obtain feedback if mixture needed

<fhirsch> sean notes 1.1 references without URI are very rare

<scantor> we would normatively say that a given Signature can contain either 2.0 Mode references or Compatibility Mode references, but not both

RESOLUTION: normatively say that a given Signature can contain either 2.0 Mode references or Compatibility Mode references, but not both

<scribe> ACTION: pdatta to update 2.0 draft based on scott's proposal for 2.0 mode references [recorded in http://www.w3.org/2010/01/12-xmlsec-minutes.html#action10]

<trackbot> Created ACTION-496 - Update 2.0 draft based on scott's proposal for 2.0 mode references [on Pratik Datta - due 2010-01-19].

pdatta: what should we do if xml sig 1.1 validates 2.0 refs with more than one without URI?

pretty sure java impl will throw exception

don't use dummy uri, leave it empty

Interop

fjh: assume last call in about 6 weeks
... if ecc issue still unresolved, may need to make it optional

<tlr> (that's worst case estimate)

fjh: will need to figure out with impls

<Cynthia> no new information regarding implementations of ECDSA

bal: doesn't think anything will change by April

tlr: features at risk are a mechanism to drop them or make optional if not enough impl. exp.