The minutes from the February 12 Widgets voice conference are
available at the following and copied below:
<http://www.w3.org/2009/02/12-wam-minutes.html>
WG Members - if you have any comments, corrections, etc., please send
them to the public-webapps mail list before 19 February 2009 (the
next Widgets voice conference); otherwise these minutes will be
considered Approved.
-Regards, Art Barstow
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Widgets Voice Conference
12 Feb 2009
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-webapps/
2009JanMar/0384.html
See also: [3]IRC log
[3] http://www.w3.org/2009/02/12-wam-irc
Attendees
Present
Art, Arve, Benoit, Mark, Frederick, Josh
Regrets
Marcos, Claudio, Mike, Thomas, Jere
Chair
Art
Scribe
Art
Contents
* [4]Topics
1. [5]Review and tweak agenda
2. [6]Announcements
3. [7]Context of Widgets DigSig discussion
4. [8]Use Cases
5. [9]Requirements
6. [10]Is supporting multiple signatures per package a MUST
for v1?
7. [11]AOB
* [12]Summary of Action Items
_________________________________________________________
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:
... [13]http://www.w3.org/2008/webapps/wiki/WidgetsParisAgenda
... any other announcements?
[13] http://www.w3.org/2008/webapps/wiki/WidgetsParisAgenda
[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
[14]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
[15]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
<[16]http://dev.w3.org/2006/waf/widgets-reqs/>
[16] http://dev.w3.org/2006/waf/widgets-reqs/%3E
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:
[17]http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/04
07.html
... Other comments?
[17] http://lists.w3.org/Archives/Public/public-webapps/
2009JanMar/0407.html
<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
[18]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
[19]http://www.w3.org/2009/02/12-wam-minutes.html#action02]
[End of minutes]
