See also: IRC log
<trackbot> Date: 24 February 2009
<magnus> Dialing in - but do not get through...
<tlr> Agenda: http://www.w3.org/mid/AD732A4D-7333-4EFE-8B03-FE425A23F573@nokia.com
<fjh> agenda: http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0107.html
<fjh> Scribe: Konrad Lanz
<fjh> ScribeNick: klanz2
<fjh> Widgets 1.0 Signature
fjh: liasion, widged updated draft
<fjh> http://dev.w3.org/2006/waf/widgets-digsig/
fjh: will send today
<fjh> 22-24 March AC Meeting Registration
fjh: AC meeting, please register
<fjh> http://www.w3.org/2002/09/wbs/34257/200903AC/
fjh: thinks its in cambridge, MA
<fjh> No associated XML Sec WG meeting
<fjh> http://www.w3.org/2009/02/10-xmlsec-minutes.html
RESOLUTION: 2a) Minutes from 10 February 2009, for approval -> approved
2b) Minutes from 17 February 2009, for approval -> next week review until then
<fjh> Key Wrapping intro in XML Encryption needs Example
fjh: Tom, noted a new issue is
there
... in xmlenc
4a) Transition Request Approved
<fjh> Transition Request Approved
http://lists.w3.org/Archives/Member/member-xmlsec/2009Feb/0021.html
<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2009Feb/0021.html
4b) XML Signature 1.1 ECPointType
fjh: brian, did update ... not on the call .. follow list
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0086.html
fjh: defer till next week
tlr: adds editors note, btw
...
... this may change
<fjh> Not including in FPWD but will add editors note
tlr:
<fjh> s/this may/this may
fjh: changes: ...
tlr: one thing I will do, looks out for references, dangling ones
<fjh> Summary of changes since last teleconference
<fjh> Editorial Note, update ECPointType schema and text, fix links, wg
<fjh> acknowledgement
fjh: assumes tlr will update also the editors note
magnus: it's not the ECPointType its about verifyability of the randomness of the curve
<tlr> Will add note that markup for verifiability is likely going to change, and that WG considers this.
<fjh> Summary of changes since last teleconference
<fjh> Editorial note, style changes, fix links, wg acknowledgement
fjh: brings kelvin up to speed,
about the changed to DSIG 11
... editorial changes been made
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0093.html
fjh: good a s apublic working, draft, concerns?
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0094.html
<fjh> Typos, fixes to references, fix ECDH-ES uri, fix links, drop acknowledgements
fjh: editorial changes
tlr: href attributes broken in
the docs
... different URIS for same algo
fjh: was tehre any ambiguity
<tlr> klanz: RIPE URIs in the documents?
<tlr> tlr: don't think so; nor is aes-kw-pad
<tlr> ... i suggest having an agendum about that ...
<fjh> issue: ripe URIs
<trackbot> Created ISSUE-100 - RIPEMD URIs ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/100/edit .
klanz2: what about the RIPEMDmd algos that did not make it into the 4051 draft as eastlake has not bublished the bis
<fjh> ACTION: konrad to make proposal RIPE algorithms [recorded in http://www.w3.org/2009/02/24-xmlsec-minutes.html#action01]
<trackbot> Created ACTION-222 - Make proposal RIPEMD algorithms [on Konrad Lanz - due 2009-03-03].
<tlr> ISSUE: Add AES Key Wrap with Padding to Encryption
<trackbot> Created ISSUE-101 - Add AES Key Wrap with Padding to Encryption ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/101/edit .
<fjh> issue: AES Keywrap
<trackbot> Created ISSUE-102 - AES Keywrap ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/102/edit .
Editorial Status Update
<fjh> Switch to "experimental" namespace
fjh: namespace problem, experimental namespace
<fjh> Affiliations, update abstract (move 2nd Edition), style
tlr: palceholder doc ...
<fjh> http://www.w3.org/2008/xmlsec/namespaces.html
fjh: status of WD 1.1 covered ...
tlr: starts working on stuff ... hopes to have it out soon
fjh: process things nothing the WG can do
<fjh> http://www.w3.org/2002/09/wbs/34786/TPAC2009/
fjh: TPAC Plan in Santa Clara, CA
W3C figures out details currently ...
... we have to answer till March 18th
... Who would attend?
klanz2: I'd like to and if I get
fundting I'll come
... should work out
fjh: Let's put 20, depends on
economy ...
... two day should be good
<Gerald-E> I can go then..
fjh: let's do thursday and friday
5th 6th Nov
<fjh> one day too short, 3 day too long
<Gerald-E> I plan on going for the week.
fjh: which group we'd like to
meet, ... EXI ..
... overlaps ... ?
klanz2: I'd like to attend XMLCORE
fjh: confidentiality ?
Questionnaire
http://www.w3.org/2002/09/wbs/42458/f2fsched2009/
Status of options.
5-6 May, Boston?
<fjh> http://www.w3.org/2002/09/wbs/42458/f2fsched2009/
fjh: dicussion about location, Boston ... Europe ....
<fjh> I can probably host at Nokia in Cambridge MA 5-6 May
tlr: gives up on hosting in Europe ...
<tlr> ... I'll spend time on the phone while you meet in Boston
magnus: this week will not work
for magnus
... prefers to have it later
fjh: hosting at nokia, not possible after mid may
magnus: could host ?
fjh: holiday season, cannot in August
tlr: may - july
... given TPAC scheduled for Nov ...
<magnus> RSA could likely host, if held in the Boston area.
<magnus> RSA most likely could host, if held in the Boston area
<Gerald-E> I vote for June - I can not do May
<Gerald-E> I am restricted only for May.
klanz2: I cannot do July and late June ...
... August is also very difficult
... so May or early June would be good
tlr: 12,13 May ...
Gerald-E: depends
kelvin: not sure
fjh: tentatively plan for that date
<scribe> ACTION: magnus and fjh to check on hosting [recorded in http://www.w3.org/2009/02/24-xmlsec-minutes.html#action02]
<trackbot> Created ACTION-223 - And fjh to check on hosting [on Magnus Nyström - due 2009-03-03].
<scribe> done
july is not possible for me
<brich> i can't travel July 13, but could conference in
brich: ... travelling difficult
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0100.html
tlr: padding, with padding,
currently no padding
... only keys that are mod 64 = 0
... proposal encompasses all useful key length ...
... seperate identifiers indicated
... roll out algo as mandatory to implement
... will take a few month before stable ...
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0101.html
tlr: let's make OPTIONAL
fjh: where is the OPTIONAL mentioned in the draft ...
tlr: forgotten add algorithms do appropriate table ...
??Potential-RESOLUTION??: Add as OPTIONAL AES Key Wrap with Padding to the post WD 1.1
<fjh> kelvin notes that we need to make sure this material does not go forward if ietf dependency is not ready
tlr: add editors ... work in progress
<fjh> tlr notes that we can deal with that later, unlikely, add editors note that currently an internet draft
<fjh> Possible Resolution Add as Optional AES Key Wrap with padding as proposed by tlr for editors draft of 1.1 post FPWD
RESOLUTION: Add as Optional AES Key Wrap with padding as proposed by tlr for editors draft of 1.1 post FPWD
<scribe> ACTION: tlr to Add as Optional AES Key Wrap with padding as proposed by tlr for editors draft of 1.1 post FPWD [recorded in http://www.w3.org/2009/02/24-xmlsec-minutes.html#action03]
<trackbot> Created ACTION-224 - Add as Optional AES Key Wrap with padding as proposed by tlr for editors draft of 1.1 post FPWD [on Thomas Roessler - due 2009-03-03].
<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2009Feb/0012.html
magnus: we have not identified a
security level above 192 bit
... need recommended curves for 192 and 256 bits
<fjh> test
<fjh> magnus notes we should list the additional curves as Recommended, 192 and 256 for interop
kelvin: helpful if we put notes in ...
klevin: curves would be recommended, first have to define the curve at certain security level and what hash algorithm matches the strength
kelvin: NIST covers the recommendations
<fjh> kelvin notes that nist has table with curve and hash algorithm recommendations for given security levels
kelvin: why assesss security levels if we don't do that for RSA ?
<fjh> kelvin asks if general question to highlight security strength for RSA, DSA as well, noting algorithms
I'm not sure that the XMLDSIG docs are the right place for this, there is other projects taking care of such stuff http://www.keylength.com/
tehre is a collection of all the things from NIST, ECRYPT, SCSSI etc ....
magnus: the core issue is
...
... provide recommendation for the two higher security level
curves with reference
ECDSA
<scribe> ACTION: magnus to propose text for a note potentially to be added to XMLDSIG provide recommendation for the two higher security level curves with reference [recorded in http://www.w3.org/2009/02/24-xmlsec-minutes.html#action04]
<trackbot> Created ACTION-225 - Propose text for a note potentially to be added to XMLDSIG provide recommendation for the two higher security level curves with reference [on Magnus Nyström - due 2009-03-03].
<kyiu> I think we can address magnus's proposal by adding a note or paragraph that highlight P384 and P512 and reference the appropriate NIST doc (SP 800-57 Part 1) which also includes recommendation about the hash alg that should be used for a specific security level
fjh: shouldn't that be in the
algos note ...
... adding references
<magnus> (wasn't action-225 on Kelvin?)
<fjh> yes it was
<fjh> suggest putting reference to NIST best practices on algorithm strength into algorithms summary document
deferred
action-192 closed
<trackbot> ACTION-192 Review suggestion to change reference for EC point to OCtet string proposed by magnus closed
*d*
magnus: can we come back to
identifirer discussion
... shouldn't there be a REQUIRED curve in XMLENC as well
... should it be the same curve
kelvin: agrees
<fjh> kelvin recommend 256 curve for encryption?
tlr: we need an agendum for that
<fjh> thomas notes need to talk about mandatory to implement for key agreement
tlr: let's continue on actio items ...
fjh: asks tlr to get back into the discussion ;-)
<fjh> tlr asks if we should review status of diffie-hellman, make it manditory
tlr: there is a single key agreement in XMLENC ...
magnus: strange as there is no required curve#
ISSUE: shouldn't there be a REQUIRED curve in XMLENC as well
<trackbot> Created ISSUE-103 - Shouldn't there be a REQUIRED curve in XMLENC as well ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/103/edit .
<scribe> [pending review] ACTION-218: Thomas Roessler to Send proposed changes
to properties document on mail list - due 2009-02-24 [on ]
http://www.w3.org/2008/xmlsec/track/actions/218
ACTION-218 closed
<trackbot> ACTION-218 Send proposed changes to properties document on mail list closed
<fjh> http://www.w3.org/2008/xmlsec/track/actions/open
<tlr> action-13?
<trackbot> ACTION-13 -- Konrad Lanz to review streaming using 2nd edition Signature -- due 2008-11-10 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/13
http://www.w3.org/2008/xmlsec/track/actions/13
<fjh> http://www.w3.org/2008/xmlsec/track/actions/13
<tlr> I think "review action-13 results" sounds like a good agendum for an upcoming call
<fjh> wg should review this issue, new notes added. topic of backward compatibility
http://www.w3.org/2008/xmlsec/track/actions/77
<tlr> ??
<tlr> action-77?
<trackbot> ACTION-77 -- Sean Mullan to update best practices document for section titles -- due 2008-10-14 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/77
<fjh> http://www.w3.org/2008/xmlsec/track/actions/100
<tlr> action-100?
<trackbot> ACTION-100 -- Konrad Lanz to email proposal regarding 2 ds:References, old and new -- due 2008-11-11 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/100
<fjh> 100 is about backward compatibility
<tlr> I don't see any useful notes in this one
<fjh> separate from action 13
<Gerald-E> I have to leave early... sorry.
<tlr> An action, by definition, is a promise to do something by a certain time.
<tlr> action-100 is the promise to send an e-mail that can then be discussed
<Gerald-E> this review also needs to be done for issues, to know their state as well.
<tlr> therefore, action-100 should be done and moved to pending review
<tlr> +1
klanz2: transform action-100 into an issue that is how to carry existing ds:References into new signatures
<Gerald-E> I have to leave, but I will help with issues to update their status.
<Gerald-E> either description or status should be current so we know how to address this.
<fjh> scott notes that it might be useful for WG members to write note on their position on how 2.0 should proceed, share on list
<fjh> need focus and priority now
<fjh> chair requests all wg members to review their actions, update the notes, move to pending if done or moot, send email if necessary to discuss on call
<fjh> goal is to close actions
<fjh> please also review issues list and update notes, start discussion on list
http://www.w3.org/2008/xmlsec/track/actions/100 still open -> transform action-100 into an issue that is how to carry existing ds:References into new signatures
tlr: does bulk closures
<tlr> happy to adjpurn early
ACTION-100 closed
<trackbot> ACTION-100 Email proposal regarding 2 ds:References, old and new closed
ISSUE: carry existing ds:References into new XMLDSIG 2.0
<trackbot> Created ISSUE-104 - Carry existing ds:References into new XMLDSIG 2.0 ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/104/edit .
<tlr> someday pile issue, I think
<tlr> yep
ISSUE: HMAC output length is defined on bits base64 on octets
<trackbot> Created ISSUE-105 - HMAC output length is defined on bits base64 on octets ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/105/edit .