XML Security Working Group Teleconference
06 Jan 2009

Administrivia

fjh: F2F next week

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

<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2008Nov/0035.html

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

fjh: draft agenda sent out
... goal to get 1.1 in order
... how to do interop
... 2.0 items, best practices, rqmts
... bridge will be open for meeting
... skip meeting week after F2F?

<hlockhar> +1

RESOLUTION: cancel teleconf on January 20

<gedgar> for today's meeting I can only stay for the first hour unfortunately.

<gedgar> +! skip the meeting after the F2F

fjh: 1.1 review algs first day of meeting, also for xml enc

<scribe> ACTION: fjh to create template for algorithm note [recorded in http://www.w3.org/2009/01/06-xmlsec-minutes.html#action01]

<trackbot> Created ACTION-130 - Create template for algorithm note [on Frederick Hirsch - due 2009-01-13].

fjh: interop for 1.1 need to decide process at F2F
... talk about signature properties, widgets
... 2.0 on 2nd day mostly
... go over pratik's drafts
... EXI joint meeting 5-6 on Tues
... best practices, recent action items
... reqmts, simple signing
... Xades plugfest

<fjh> announcement - XAdES Plugfest 6 Feb, http://lists.w3.org/Archives/Public/public-xmlsec/2008Dec/0022.html

Minutes Approval

RESOLUTION: Minutes from 16 December 2008 approved

Issues

fjh: some refs in 1.1 draft missing
... issue-78, add missing refs
... issue 79 - conveying OCSP responses and CRL inclusion not talked about in xmldsig draft
... discuss more at F2F

scantor: more than CRL already defined?

fjh: maybe CRL not needed then
... extensibility issue

<fjh> may want element for OCSP

<fjh> extensibility

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

<fjh> feedback from wg on the questions in this email requested.

fjh: look at tlr email and discuss at F2F

Editorial updates

<fjh> requirements document updated

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

fjh: updated reqmts with long term sig material
... home page ... maybe add EXI doc discussuing dsig and enc

<fjh> Update to transform simplification

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

pdatta: updated design with email

<fjh> http://www.w3.org/2008/xmlsec/Drafts/transform-note/Overview.html#design

pdatta: posing syntax without transforms
... declarative model about what is being signed

<scribe> ... new syntax, selection section and c14n section

pdatta: policy processor can figure out what is being signed without executing transforms

<scribe> ... new syntax can be mapped to old syntax

pdatta: perf improvement examples given
... does not have to keep c14n output in memory
... env sig can be optimized
... signing binary data
... don't have to look at transforms, look at type instead
... sign what is seen, section 5.5

maybe consider it as part of c14n

fjh: maybe need see what is signed stage instead of c14n

<fjh> in between selection and c14n could have "see" stage

tlr: add pratik as editor

<fjh> tlr notes that pratik should be added as an editor

fjh: please review pratik's updates for F2F
... signature properties

signature properties

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

fjh: added expires property
... remove timestamp property
... added replay protect element
... role attribute to indicate widget/code signing role
... please review and comment
... widget spec better if it references 1.1 and sig properties

tlr: draft doesn't say which props are critical/not critical
... uris what they they mean and what impl should do with them
... for example are we extending core validation or is it orthogonal?

<fjh> tlr notes, if expired, does that mean core validation failed or something else

bal: will take a look at code signing properties for F2F

XML Security 1.1

<fjh> New Key Value Proposal

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

scantor: to address one of schema issues
... rsa and dsa key complexity issues
... der encoided keys
... schema uses RFC 3279 structure

bal: why dsig should have 2nd encoding key format?

scantor: being able to use same syntax for bare keys that certificates use

bal: already have a way to do that and tools are available to convert to existing form
... this can be defined within SAML community, questions whether it should be in core
... made a choice in 2000 to define xml key structure

fjh: why is it bad to define a different representation?

bal: should you put a 2nd mech in core spec? Now have multiple ways to do same thing
... impls then have to expect both forms

<gedgar> I have to drop off..

bal: perfectly reasonable for SAML to define their own KeyInfo extension to satisfy use case

<fjh> apparently have disagreement on need for additional representation

scantor: issue is lack of tool support

<fjh> hal notes factual question - general need for this

<fjh> hal notes licensing crypto toolkits that include asn.1, bal notes that all do not

scantor: tools - given encoded key, how do i get xml representation?

<fjh> scott - given a public key how to get the xml representation of that key, that functionality is not easy to get on many platforms

<fjh> is the question of usability versus the issue of offering alternatives in a spec

bal: certain scenarios are passing key around blindly, keyinfo being used to pass keys around
... independent of xml dsig

<fjh> use of keyinfo independent of a signature is a use case

scantor: keys need to be turned into programming level objects
... to compare keys, etc
... problem is moving between key formats doesn't exist

<fjh> scott notes processing to produce keyinfo may not be signature processing, may be human or simple tools

<fjh> bal notes what about key analysis, e.g. does it match policy

bal: how much do we want to adhere to XML dsig 1.0 goal of not requiring non-XML formats

scantor: not sure why adding another format necessarily invalidates that goal

fjh: did we think about keyinfo being used outside of signature?

<tlr> KeyValue is MUST

fjh: if we do specify mandatory/optional could we define as optional (not suggesting that, but is it possible?)

<tlr> second paragraph of 4.4

<fjh> http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/#sec-KeyInfo

<fjh> 4.4.2

<fjh> While applications may define and use any mechanism they choose through inclusion of elements from a different namespace, compliant versions MUST implement KeyValue (section 4.4.2) and SHOULD implement RetrievalMethod (section 4.4.3).

scantor: we didn't define it ourselves because we would be off on our own

<fjh> tlr asks about requirements, is an XML only serialization required for KeyInfo, maybe we do not want this requirement

<fjh> tlr notes should call out in requirements document

<fjh> tlr asks is x509Data container sufficient or more profiling needed, any mandatory items needed

<fjh> tlr asks for requirements and consensus on those

<fjh> scribenick: fjh

scott: reuse of key info is a requirement, ability to compare etc

passing hash of keys is another approach, also not defined

<bal> this may solve problem better

requirement - repurposing of key info

<scantor> some people don't like using certificates to pass around keys and ignoring semantics of certs

Generation and validation requirements DSAwithSHA1

http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0007.html

<bal> wording around DSAwithSHA1 for 1.1

"REQUIRED for signature verification/OPTIONAL for signature generation DSAwithSHA1"

... would like to see optional, chris noted mandatory for validators, optional for generators

... updated draft to reflect that

produced proposal, 1.1 editors draft has not been updated yet I believe

... give some text to caution people shouldn't use DSAwithSHA1 with current standard for long term keys

.. because not secure

... beyond 2010

<tlr> agree bad idea to include IPR

... what is timing expectation for FIPS revision?

<bal> last comments last couple of months

... possible within 6 months

... possible 186-3 could be published before we finish

<tlr> ACTION: thomas to ping Tim Polk about likely 186-3 timing expectations [recorded in http://www.w3.org/2009/01/06-xmlsec-minutes.html#action02]

<trackbot> Created ACTION-131 - Ping Tim Polk about likely 186-3 timing expectations [on Thomas Roessler - due 2009-01-13].

<tlr> +1 to adding now

<fjh> add to draft now

<smullan> RESOLUTION: add wording around DSAwithSHA1 for 1.1 to draft

<smullan> ACTION: bal to add wording around DSAwithSHA1 for 1.1 to draft [recorded in http://www.w3.org/2009/01/06-xmlsec-minutes.html#action03]

<trackbot> Created ACTION-132 - Add wording around DSAwithSHA1 for 1.1 to draft [on Brian LaMacchia - due 2009-01-13].

Best Practices

Timestamps

http://lists.w3.org/Archives/Public/public-xmlsec/2008Dec/0033.html

Use Timestamps tokens issued by Timestamp authorities for long lived signatures

<fjh> add RFC 3161 reference for time stamp protocol

<smullan> ACTION: fjh to update best practice with timestamp proposed changes [recorded in http://www.w3.org/2009/01/06-xmlsec-minutes.html#action04]

<trackbot> Created ACTION-133 - Update best practice with timestamp proposed changes [on Frederick Hirsch - due 2009-01-13].

local access risks

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

<ken> included example of using XSLT extensions

<smullan> will wait until F2F to review and vote on updating draft

http://www.w3.org/2008/12/16-xmlsec-minutes.html#item09

action item review

<smullan> ACTION-90 talk about at F2F

<tlr> yep!

AOB

<tlr> what was our plan for RSA-SHA256 for 1.1?

<smullan> ACTION: kelvin to update conformance document for RSA-SHA256 [recorded in http://www.w3.org/2009/01/06-xmlsec-minutes.html#action05]

<trackbot> Created ACTION-134 - Update conformance document for RSA-SHA256 [on Kelvin Yiu - due 2009-01-13].

<smullan> ACTION: kelvin to add requirements for RSA-SHA256 [recorded in http://www.w3.org/2009/01/06-xmlsec-minutes.html#action06]

<trackbot> Created ACTION-135 - Add requirements for RSA-SHA256 [on Kelvin Yiu - due 2009-01-13].

Required SHA1, Required SHA-256

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

<bal> should we add appropriate wording to encourage SHA256 instead of SHA1

note add agenda item for f2f re scary language on sha-1 and going to sha-256

note issues on md5, make it stronger than non recommended

<tlr> ACTION-135 closed

<trackbot> ACTION-135 Add requirements for RSA-SHA256 closed

<tlr> ACTION: thomas to propose stronger language on MD5 for 6.2 [recorded in http://www.w3.org/2009/01/06-xmlsec-minutes.html#action07]

<trackbot> Created ACTION-136 - Propose stronger language on MD5 for 6.2 [on Thomas Roessler - due 2009-01-13].

<scantor> http://events.ccc.de/congress/2008/Fahrplan/attachments/1251_md5-collisions-1.0.pdf

attack on md5 , collision attack, intermediary ca created that uses accepted ca root, enabling browser acceptance

<tlr> http://www.win.tue.nl/hashclash/rogue-ca/

<tlr> demo site: https://i.broke.the.internet.and.all.i.got.was.this.t-shirt.phreedom.org/