See also: IRC log
Date: 12 Feb 2009
<scribe> ScribeNick: ArtB
<scribe> Scribe: Art
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
AB: Feb 24-26 f2f meeting agenda
has been updated:
... http://www.w3.org/2008/webapps/wiki/WidgetsParisAgenda
... any other announcements?
[None]
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
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
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
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
AB: register for f2f meeting;
deadline is Feb 16 to register
... meeting adjourned
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]