W3C

- DRAFT -

Widgets Voice Conference

12 Feb 2009

Agenda

See also: IRC log

Attendees

Present
Art, Arve, Benoit, Mark, Frederick, Josh
Regrets
Marcos, Claudio, Mike, Thomas, Jere
Chair
Art
Scribe
Art

Contents


 

Date: 12 Feb 2009

<scribe> ScribeNick: ArtB

<scribe> Scribe: Art

Review and tweak agenda

AB: Widgets DigSig spec is the only item on the agenda and it's relatively packed
... If we can't get to a topic and its not "closed" by the f2f meeting, we can add the topic to the f2f agenda
... Any change requests?

Arve: Marcos is critical for these discussions

AB: agree. If we make any decisions, we can make them tentative pending input from Marcos
... would that be acceptable Arve?

Arve: yes

Announcements

AB: Feb 24-26 f2f meeting agenda has been updated:
... http://www.w3.org/2008/webapps/wiki/WidgetsParisAgenda
... any other announcements?

[None]

Context of Widgets DigSig discussion

AB: Let me start with a little context setting ...
... Some recent discussions indicate we may not all be on the same page re Use Cases and Requirements
... I want to step back a bit and make sure we're in agreement here
... As you know Frederick is now a co-Editor of the DigSig spec and he is an Editor of the XML Sig spec
... but he wasn't part of the WG when we started this spec and hence may be missing some context
... We can use this call to help clarify some high level UCs, Reqs, etc.
... Note that we will dedicate all of Wedn afternoon on Feb 25 for DigSig and can get into the spec details tehn
... A factor we need to consider as we discuss UCs, Reqs and the Spec itself is what is mandatory for v1.0 versus the NextGen (NG) spec.
... We must also be very careful to separate what we need to specify in the spec itself versus deployment issues that are out of band and implementation issues which of course are also out of band
... Regarding the roadmap/timeline for this spec, I would like to see a new WD in early March with a LCWD in April/May and a Candidate starting beginning in June/July
... This may seem a bit aggressive and we can spend some time talking about schedule today and/or at the f2f meeting
... So with that introduction are there any quick follow-ups or comments before we move to the agenda?

FH: want to think about XML Sig 1.1 schedule

<scribe> ACTION: Barstow need to track Widgets DigSig and XML Sig 1.1 for possible conflicts [recorded in http://www.w3.org/2009/02/12-wam-minutes.html#action01]

MP: we fully support an agressive timeline for this spec
... agree we need to get agreement on the high level objectives
... don't think the spec issues are that great

Use Cases

AB: what are the main use cases regarding creation, installation and updating?
... we don't really have a Use Cases document per se
... However, for each requirement we do have some descriptive information and "Motivation"
... Frederick, All - what do you want to discuss regarding Use Cases? What needs clarification and what's missing?
... Before I open the floor, let's be careful to not conflate what needs to actually be specified in our DigSig spec versus deployment issues and implementation issues

FH: a few questions
... not sure I understand update model and sec features related
... Also need to understand the UCs wrt the properties

MP: in one of my emails to the list I expanded on the UCs

<fjh> I understand the use case of widget package integrity, via signature at any time, not clear on other use cases, including update or need for properties

MP: some of them don't necessarily need to be part of v1 of the spec
... But v1 must not rule out those UCs postponed to v.NG
... Main one: use signature to verify identity

<fjh> use case includes signature verification and cert validation, trust establishment

<mpriestl> ...and to verify that some entity has signed the widget package and is making some statement about it

MP: wrt updates, we realized there is a need to support more than one sig
... in a package
... e.g. an "update signature"
... need to reliably establish an update is a reliable replacement
... different levels of strength to do that
... an update sig would be separate
... the original pack could have an update sig
... and if the update sig in the original pack has the same key as the separate update sig
... have confidence the upate is reliable
... Think the usage property can be usefule here
... Some rule changes would need to change to reflect this usage prop

FH: have one comment about main UC but I can defer it
... Still confused on the update scenario
... Does the update replace the entire widget?

MP: yes
... how do you know the update you want to install is the "right" one to use for the update

FH: a hash of the orig widget can be used
... don't think you need keys

MP: there is a widget id
... don't want anyone to trick the install mechanism
... a hash of the widget could be fudged too

FH: not sure all of the info needed can be put in the property

MP: perhaps I should expand on the mail list

FH: this is the critical UC that is driving the property use
... I don't understand the update mechanism well enough

MP: I'm suggesting the update sig could be one of the mech used to decide if an update widget is the authorized update

FH: concerned about using the same prvt key
... what if it is revoked
... Could use org name
... still not sure I understand the UC
... not clear about auth decision
... but the idea is the Usage property cand help

MP: the update sig is not the same as the widget signauture
... using other parts of the cert is problematic

<fjh> ok

FH: perhaps we can simplify more
... there are a few roles in the model now
... do you really need an update prop

MP: there is an author signature and the distributor signature

<fjh> author signature to be coverd by distributor signaure

MP: can expect distributor sig to cover the author sig

FH: don't think a Usage property is needed
... I can generate a proposal for this

<scribe> ACTION: Hirsch create a proposal for properties and send it to the mail list [recorded in http://www.w3.org/2009/02/12-wam-minutes.html#action02]

FH: re UC #1 above.
... concerned about integrity if sigs can be added or removed
... think we need one sig that covers all of the other sigs

MP: agree we have to think about this

FH: two possible attacks: one is something is missing; another is man in the middle
... Need to note the risks

MP: I'm fine with that

<fjh> first risk can be addressed legally, author does not include distributor,

<fjh> second man in middle, could be addressed by transfer channel security e.g. tls

<timeless> zakim who is on?

FH: beside the two UCs we have discussed, are there others?

MP: we've mainly discussed these two
... there are some others we have talked about
... but they aren't critical for v1
... Howver, we don't want v1 to preclude addressing the other UCs

<fjh> ability to sign portions of content is inherent in xml signature capabilities

MP: want to make sure we have an extension mechanism
... may be able to use roles
... I can provide feedback once I see FH's role inpunpout

FH: want to make sure we understand OCSP

MP: I responded today
... think it can be removed from the spec

Requirements

AB: the basic question here is if the related requirements are "right" or do they still need some work e.g. additions, modifications?
... the agenda contains the list of related reqs and there are 8 of them
... I don't think we should necessarily go thru each of them but we can spend time on those that are particularly problematic.
... the requirements doc is <http://dev.w3.org/2006/waf/widgets-reqs/>

FH: two questions
... one I already responded on the list
... the other is about elliptic curve
... we can also take that on the list
... we still need to explicitly define the algorithms

<fjh> issue ECDSAwithSHA256 as required algorithm in place of DSAwithSHA256? related to XML Signature 1.1 outcome as well

Is supporting multiple signatures per package a MUST for v1?

AB: there has already been some discussion on this

<fjh> issue: ECDSAwithSHA256 as required algorithm in place of DSAwithSHA256? related to XML Signature 1.1 outcome as well

AB: Mark says this is a MUST: http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0407.html
... Other comments?

<fjh> ISSUE: ECDSAwithSHA256 as required algorithm in place of DSAwithSHA256? related to XML Signature 1.1 outcome as well

MP: Marcos sent something to the list about this
... I think his proposal is a good one
... I don't think it is a big issue to specify

FH: if have different roles that could get complicated

<mpriestl> good point - still shouldn't be that complicated though - hopefully

AOB

AB: register for f2f meeting; deadline is Feb 16 to register
... meeting adjourned

Summary of Action Items

[NEW] ACTION: Barstow need to track Widgets DigSig and XML Sig 1.1 for possible conflicts [recorded in http://www.w3.org/2009/02/12-wam-minutes.html#action01]
[NEW] ACTION: Hirsch create a proposal for properties and send it to the mail list [recorded in http://www.w3.org/2009/02/12-wam-minutes.html#action02]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2009/02/12 15:06:06 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found ScribeNick: ArtB
Found Scribe: Art

WARNING: Replacing previous Present list. (Old list: Art, Arve, Frederick, Mark)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ Benoit

Present: Art Arve Benoit Mark Frederick Josh

WARNING: Replacing previous Regrets list. (Old list: Marcos, Claudio, Jere, Josh, Mike, Thomas)
Use 'Regrets+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Regrets+ Marcos, Claudio, Mike, Thomas, Jere

Regrets: Marcos Claudio Mike Thomas Jere
Agenda: http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0384.html
Found Date: 12 Feb 2009
Guessing minutes URL: http://www.w3.org/2009/02/12-wam-minutes.html
People with action items: barstow hirsch need

[End of scribe.perl diagnostic output]