Call for Consensus (CfC) to close the Web Intents Task Force - Deadline October 29, 2015

2015-10-15 Thread Frederick Hirsch
This is a Call for Consensus (CfC) to close the Web Intents Task Force [1].

This Task Force has been inactive for some time.  There are no relevant 
deliverables in the draft revision of the DAP WG charter [2], or the Web 
Platform WG charter [3].

The purpose of this CfC is obtain consensus to explicitly close the Task Force. 
If you agree with closing the Task Force a response with a +1 would be useful;  
if you have concerns please note them. Silence will be assumed to be agreement.

I believe the TF mail archive will remain despite the TF being closed.

Please respond by October 29, 2015 (2 weeks) to this CfC.

Thanks

regards, Frederick

Frederick Hirsch
Chair, W3C Device APIs WG (DAP)

www.fjhirsch.com
@fjhirsch

[1] http://www.w3.org/2009/dap/#webintents

[2] http://w3c.github.io/dap-charter/DeviceAPICharter.html

[3] http://www.w3.org/2015/10/webplatform-charter.html





Call for Consensus to Publish First Public Working Draft of FindText API completed with support and no objections

2015-10-14 Thread Frederick Hirsch
Given support on the Web Annotation WG/Web Apps public mailing lists for 
publishing a FPWD of the FindText API, and no objections this CfC has concluded 
successfully in support of publishing a FPWD of the FindText API. (We've also 
had support in discussions on the teleconferences)

There were some questions asked that will be dealt with as the Working Groups 
work through questions related to this API, such as Shadow DOM, but this should 
not preclude FPWD publication.

On behalf of the Web Annotation WG chairs I declare consensus to publish.

(I will not speak for the Web Platform chairs, but there were no objections on 
the WebApps list that I saw, perhaps they can confirm that this CfC is 
completed successfully from their point of view as well).

regards, Frederick

on behalf of myself and Rob Sanderson, Web Annotation WG Co-Chairs

www.fjhirsch.com
@fjhirsch


> On Oct 6, 2015, at 4:32 PM, Frederick Hirsch <w...@fjhirsch.com> wrote:
> 
> This is a call for consensus (CfC) to publish a First Public Working Draft 
> (FPWD) of FindText API; deadline 14 October (1 week)
> 
> This FindText API is joint deliverable of the WebApps WG and Web Annotation 
> WG (listed as "Robust Anchoring" in the charters [1], [2]).
> 
> This is a Call for Consensus (CfC) to publish a FPWD of the FindText API, 
> using the following Editor's Draft as the basis:
> 
> http://w3c.github.io/findtext/
> 
> "This specification describes an API for finding ranges of text in a document 
> or part of a document, using a variety of selection criteria."
> 
> This API was presented to the WebApps WG last TPAC under a different name, 
> and with a fairly different design; it was modified to fit the feedback from 
> that meeting and from others, including narrowing of scope, the introduction 
> of Promises, and exposing low-level functionality in the spirit of the 
> Extensible Web.
> 
> The specification is largely based on the Annotator JavaScript library's 
> "robust anchoring" code, and a standalone polyfill is under development. 
> Feedback from possible implementers is especially welcome.
> 
> This CfC satisfies the group's requirement to "record the groups' decision to 
> request advancement".
> 
> By publishing this FPWD, the group sends a signal to the community to begin 
> reviewing the document. The FPWD reflects where the groups are on this spec 
> at the time of publication; it does _not_ necessarily mean there is consensus 
> on the spec's contents and the specification may be updated.
> 
> If you have any comments or concerns about this CfC, please reply to this 
> e-mail by 14 October at the latest. Positive response is preferred and 
> encouraged, even a +1 will do  Silence will be considered as agreement with 
> the proposal.
> 
> regards, Frederick & Rob
> 
> Frederick Hirsch, Rob Sanderson
> 
> Co-Chairs, W3C Web Annotation WG
> 
> www.fjhirsch.com
> @fjhirsch
> 
> [1] http://www.w3.org/2014/06/webapps-charter.html#deliverables
> 
> [2] http://www.w3.org/annotation/charter/#scope
> 
> 
> 
> 
> 






Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

2015-10-08 Thread Frederick Hirsch
+1 to FPWD of FindText API

> On Oct 7, 2015, at 11:38 AM, Robert Sanderson <azarot...@gmail.com> wrote:
> 
> +1 to FPWD
> 
> On Wed, Oct 7, 2015 at 8:34 AM, Ivan Herman <i...@w3.org> wrote:
> I am happy to have this documents published as FPWD.
> 
> Ivan
> 
> 
> > On 06 Oct 2015, at 22:32 , Frederick Hirsch <w...@fjhirsch.com> wrote:
> >
> > This is a call for consensus (CfC) to publish a First Public Working Draft 
> > (FPWD) of FindText API; deadline 14 October (1 week)
> >
> > This FindText API is joint deliverable of the WebApps WG and Web Annotation 
> > WG (listed as "Robust Anchoring" in the charters [1], [2]).
> >
> > This is a Call for Consensus (CfC) to publish a FPWD of the FindText API, 
> > using the following Editor's Draft as the basis:
> >
> > http://w3c.github.io/findtext/
> >
> > "This specification describes an API for finding ranges of text in a 
> > document or part of a document, using a variety of selection criteria."
> >
> > This API was presented to the WebApps WG last TPAC under a different name, 
> > and with a fairly different design; it was modified to fit the feedback 
> > from that meeting and from others, including narrowing of scope, the 
> > introduction of Promises, and exposing low-level functionality in the 
> > spirit of the Extensible Web.
> >
> > The specification is largely based on the Annotator JavaScript library's 
> > "robust anchoring" code, and a standalone polyfill is under development. 
> > Feedback from possible implementers is especially welcome.
> >
> > This CfC satisfies the group's requirement to "record the groups' decision 
> > to request advancement".
> >
> > By publishing this FPWD, the group sends a signal to the community to begin 
> > reviewing the document. The FPWD reflects where the groups are on this spec 
> > at the time of publication; it does _not_ necessarily mean there is 
> > consensus on the spec's contents and the specification may be updated.
> >
> > If you have any comments or concerns about this CfC, please reply to this 
> > e-mail by 14 October at the latest. Positive response is preferred and 
> > encouraged, even a +1 will do  Silence will be considered as agreement with 
> > the proposal.
> >
> > regards, Frederick & Rob
> >
> > Frederick Hirsch, Rob Sanderson
> >
> > Co-Chairs, W3C Web Annotation WG
> >
> > www.fjhirsch.com
> > @fjhirsch
> >
> > [1] http://www.w3.org/2014/06/webapps-charter.html#deliverables
> >
> > [2] http://www.w3.org/annotation/charter/#scope
> >
> >
> >
> >
> >
> >
> 
> 
> 
> Ivan Herman, W3C
> Digital Publishing Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> ORCID ID: http://orcid.org/-0003-0782-2704
> 
> 
> 
> 
> 
> 
> 
> -- 
> Rob Sanderson
> Information Standards Advocate
> Digital Library Systems and Services
> Stanford, CA 94305

regards, Frederick

Frederick Hirsch
Chair, W3C Device APIs WG (DAP)

www.fjhirsch.com
@fjhirsch






Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

2015-10-06 Thread Frederick Hirsch
This is a call for consensus (CfC) to publish a First Public Working Draft 
(FPWD) of FindText API; deadline 14 October (1 week)

This FindText API is joint deliverable of the WebApps WG and Web Annotation WG 
(listed as "Robust Anchoring" in the charters [1], [2]).

This is a Call for Consensus (CfC) to publish a FPWD of the FindText API, using 
the following Editor's Draft as the basis:

 http://w3c.github.io/findtext/

"This specification describes an API for finding ranges of text in a document 
or part of a document, using a variety of selection criteria."

This API was presented to the WebApps WG last TPAC under a different name, and 
with a fairly different design; it was modified to fit the feedback from that 
meeting and from others, including narrowing of scope, the introduction of 
Promises, and exposing low-level functionality in the spirit of the Extensible 
Web.

The specification is largely based on the Annotator JavaScript library's 
"robust anchoring" code, and a standalone polyfill is under development. 
Feedback from possible implementers is especially welcome.

This CfC satisfies the group's requirement to "record the groups' decision to 
request advancement".

By publishing this FPWD, the group sends a signal to the community to begin 
reviewing the document. The FPWD reflects where the groups are on this spec at 
the time of publication; it does _not_ necessarily mean there is consensus on 
the spec's contents and the specification may be updated.

If you have any comments or concerns about this CfC, please reply to this 
e-mail by 14 October at the latest. Positive response is preferred and 
encouraged, even a +1 will do  Silence will be considered as agreement with the 
proposal.

regards, Frederick & Rob

Frederick Hirsch, Rob Sanderson

Co-Chairs, W3C Web Annotation WG

www.fjhirsch.com
@fjhirsch

[1] http://www.w3.org/2014/06/webapps-charter.html#deliverables

[2] http://www.w3.org/annotation/charter/#scope








Re: Stability of Widget DigSig

2015-05-08 Thread Frederick Hirsch
no objection, the referenced document is a Recommendation, isn't it?

http://www.w3.org/TR/widgets-digsig/

regards, Frederick

Frederick Hirsch

Chair XML Security WG

fjhirsch.com
@fjhirsch

 On May 8, 2015, at 7:14 AM, Arthur Barstow art.bars...@gmail.com wrote:
 
 [ + Marcos and Frederick ]
 
 Hi Andrew,
 
 The group stopped working on XML Digital Signature for Widgets several years 
 ago and there is no plan to resume work (except to process errata as 
 required).
 
 Marcos, Frederick - this spec's namespace document includes the following 
 statement:
 
 [[
 http://www.w3.org/ns/widgets-digsig/
 
 Implementers should be aware that this document is not stable.
 ]]
 
 Any objections from you or anyone else to remove this statement?
 
 -Thanks, ArtB
 
 On 5/7/15 5:55 AM, Andrew Twigger wrote:
 
 ATSC and CEA are developing standards that include the ability to download 
 digital signed applications. Their current specifications reference the W3C 
 Recommendation for XML Digital Signature for Widgets (18 April 2013).  
 However, the associated Widgets Digital Signature Namespace 
 (http://www.w3.org/ns/widgets-digsig/) contains a statement that 
 “Implementers should be aware that this document is not stable.” which has 
 raised questions as to the stability and suitability of referencing Widget 
 DigSig.  The alternative would be to reference XAdES with the C and T forms 
 to allow for the inclusion of timestamp and certificate revocation 
 information which are not included in Widget DigSig.
 
 I would be pleased to receive any information regarding the stability of 
 Widget DigSig and whether referencing XAdES would provide a better 
 alternative.
 
 Thank-you,
 
 Andrew Twigger
 
 




Re: [W3C TCP and UDP Socket API]: Status and home for this specification

2015-04-07 Thread Frederick Hirsch
 Lastly, if there is a decision to continue to work on this API I can remain 
 as main editor. However, I can currently not commit to more extensive tasks 
 such as implementation and test cases. 

Claes

Do you have information on W3C members committed to implementation  test cases 
going forward? This might be useful before considering venue for the work and 
detailed issues. (Is there a public web page with information on current 
implementations?)

thanks

regards, Frederick

Frederick Hirsch

www.fjhirsch.com
@fjhirsch



 On Apr 1, 2015, at 5:22 AM, Nilsson, Claes1 claes1.nils...@sonymobile.com 
 wrote:
 
 Hi all,
  
 Related to the recent mail thread about the SysApps WG and its deliverables I 
 would like to make a report of the status of the TCP and UDP Socket API, 
 http://www.w3.org/2012/sysapps/tcp-udp-sockets/. 
  
 Note that this specification is still being worked on. Latest merged PR was 
 March 30. I think it is time for a new Public Working Draft.
  
 This API is used to send and receive data over the network using TCP or UDP.
 Examples of use cases for the API are:
   • An email client which communicates with SMTP, POP3 and IMAP servers
   • An irc client which communicates with irc servers
   • Implementing an ssh app
   • Communicating with existing consumer hardware, like internet 
 connected TVs
   • Game servers
   • Peer-to-peer applications
   • Local network multicast service discovery, e.g. UPnP/SSDP and mDNS
  
 The TCP and UDP Socket API is a phase 1 deliverable of the SysApps WG. 
 SysApps was originally chartered to provide a runtime and security model so 
 that it would be possible to open up sensitive APIs to SysApps enabled 
 runtimes. Accordingly, it was assumed that the TCP and UDP Socket API would 
 be exposed to such a “trusted runtime”. Looking at existing TCP and UDP 
 Socket APIs they are implemented in proprietary web runtimes, FFOS and 
 Chrome, which provide a security model for installed packaged web runtimes.
  
 Today we can conclude that it has not been possible to standardize a runtime 
 and security model in SysApps. However, there still seems to be an interest 
 in the TCP and UDP Socket API, at least from individuals at Google and 
 Mozilla. For example, there has been extensive work, supported by Google, to 
 adapt this API to the Streams API specification, 
 https://streams.spec.whatwg.org/. 
  
 To meet the issue that we don’t have a standardized secure “web system 
 applications” runtime and that the current open web browser sandbox is not 
 secure enough for this kind of API (but the security features are evolving 
 through the Web Application Security Working Group) I recently added 
 “permission methods”, partly inspired by the W3C Push API. A webapp could for 
 example request permission to create a TCP connection to a certain host. The 
 ambition is to isolate the permission system from the socket interfaces 
 specifications and the manner in which permission to use this API is given 
 differs depending on the type of web runtime the API is implemented in. For 
 example, a web runtime for secure installed web applications may be able to 
 open up this API so that no explicit user content is needed, while an 
 implementation in a web browser may use a combination of web security 
 mechanisms, such as secure transport (https:), content security policies 
 (CSP), signed manifest, certificate pinning, and user consent to open up the 
 API.
  
 If SysApps WG is closed and the scope of W3C is limited to APIs that could be 
 exposed the “normal browser context” (which is evolving, once again referring 
 to Web Apps Sec WG) a new home for this API could be the Device API WG. A 
 Community Group, similar to what we have for Web Bluetooth and NFC, would 
 also be a possibility. 
  
 WDYT?
  
 Lastly, if there is a decision to continue to work on this API I can remain 
 as main editor. However, I can currently not commit to more extensive tasks 
 such as implementation and test cases. 
  
 Best regards
   Claes
  
  
 Claes Nilsson
 Master Engineer - Web Research
 Advanced Application Lab, Technology
  
 Sony Mobile Communications
 Tel: +46 70 55 66 878
 claes1.nils...@sonymobile.com
  
 sonymobile.com
  
 image003.png




Re: [ambient light events LC] Feedback ( LC-2736)

2013-01-17 Thread frederick . hirsch
 Dear Tab Atkins Jr. ,

The Device APIs Working Group has reviewed the comments you sent [1] on the
Last Call Working Draft [2] of the Ambient Light Events published on 13 Dec
2012. Thank you for having taken the time to review the document and to
send us comments!

The Working Group's response to your comment is included below, and has
been implemented in the new version of the document available at:
https://dvcs.w3.org/hg/dap/raw-file/tip/light/Overview.html.

Please review it carefully and let us know by email at
public-device-a...@w3.org if you agree with it or not before 28 Jan 2013.
In case of disagreement, you are requested to provide a specific solution
for or a path to a consensus with the Working Group. If such a consensus
cannot be achieved, you will be given the opportunity to raise a formal
objection which will then be reviewed by the Director during the transition
of this document to the next stage in the W3C Recommendation Track.

Thanks,

For the Device APIs Working Group,
Dominique Hazaël-Massieux
W3C Staff Contact

 1.
http://www.w3.org/mid/caawbydau-kyqb5dzqe3ivuxan2ppabhhtj1hr1zpgn0r90y...@mail.gmail.com
 2. http://www.w3.org/TR/2012/WD-ambient-light-20121213/


=

Your comment on the document as a whole:
 Heya!  I saw the LC announcement in public-webapps, and have some
 feedback.
 
 * The introduction isn't very well written - it jumps straight into
 technical details (and too much of them), without adequate explanation
 of the purpose of the spec and the defined interfaces. I suggest
 replacing it with something like:
 
 This specification defines events that provide information about the
 ambient light level, as measured by a device's light sensor.  A
 LightLevelEvent describes the light level as one of three simple
 categories - dim, normal, and bright - while a DeviceLightEvent
 provides a more granular answer by describing the light level in terms
 of lux units.
 
 * Chapter 5 should start with an intro that describes the event.  It's
 fine for this to be somewhat repetitive with the spec's own intro -
 the point is to make it sensical for someone to jump straight into
 this section.  I suggest something like:
 
 The DeviceLightEvent interface provides information about the ambient
 light levels, as detected by the device's light detector, in terms of
 lux units.
 
 * Chapter 5 should have a note (for authors) that the precise lux
 value reported by different devices in the same light may be
 different, due to differences in detection method, sensor
 construction, etc.
 
 * 5.1 and 5.2.3 seem to be duplicate information.  I suspect this is a
 result of ReSpec, but this should be avoided if possible.  Same for
 6.1 and 6.2.3.
 
 * Similar, Chapter 6 should have an intro.  I suggest something like:
 
 The LightLevelEvent interface provides information about the ambient
 light levels, as detected by the device's light detector, in terms of
 three general range: dim, normal, or bright.
 
 * The LightLevelEvent interface should use a WebIDL enum, rather than
 describing the values solely in prose.  Here's the IDL necessary:
 
 enum LightLevel { dim, normal, bright };
 [Constructor (DOMString type, optional LightLevelEventInit
 eventInitDict)]
 interface LightLevelEvent : Event {
 readonly attribute LightLevel? value;
 };
 dictionary LightLevelEventInit : EventInit {
 LightLevel? value;
 };
 
 
 * In 6.2.1 (the description of the allowed values for the
 LightLevelEvent.value attribute), may is used.  Either must should
 be used, or it should be made non-normative and switched to can or
 something.  I think the latter is appropriate, once the enum (above)
 is adopted, as the WebIDL constitutes sufficient normative
 requirements already.
 
 * In 6.2.2 (the definition of how to fire the event), if the light
 level can't be determined, the .value attribute of the event should be
 null, not the empty string.  I've already handled the nullability in
 the WebIDL above.
 
 * In 6.2.2, the prose is a little unclear about when to fire
 lightlevel events.  I recommend replacing the sentence starting with
 When the current light changes... and the following note with
 something like:
 
 This specification does not define the exact lux ranges that the
 LightLevel values map to, as devices with different sensitivities may
 want to map them slightly differently.  However, it recommends that
 dim correspond to ambient light below 50lux, normal correspond to
 light between 50lux and 1lux, and bright correspond to light
 above 1lux.  User agents must fire a light level event when the
 current light level changes.  User agents may fire a light level event
 at any other time, for example if they have reason to believe that the
 page does not have sufficiently fresh data.
 
 ~TJ


Working Group Resolution (LC-2736):
The WebIDL was changed to use enum as you suggested, thank you.

Changes were also made to address editorial comments, see the diff

Re: Re: Indicating certificate order in XML Dig Sig ( LC-2504)

2011-08-15 Thread frederick . hirsch

 Dear Marcos Caceres ,

The XML Security Working Group has reviewed the comments you sent [1] on
the Last Call Working Draft [2] of the XML Signature Syntax and Processing
Version 1.1 published on 3 Mar 2011. Thank you for having taken the time to
review the document and to send us comments!

The Working Group's response to your comment is included below.

Please review it carefully and let us know by email at
public-xml...@w3.org if you agree with it or not before 22 August 2011. In
case of disagreement, you are requested to provide a specific solution for
or a path to a consensus with the Working Group. If such a consensus cannot
be achieved, you will be given the opportunity to raise a formal objection
which will then be reviewed by the Director during the transition of this
document to the next stage in the W3C Recommendation Track.

Thanks,

For the XML Security Working Group,
Thomas Roessler
W3C Staff Contact

 1.
http://www.w3.org/mid/BANLkTi=ztsu8cyc06jzy1t8duyhkwbk...@mail.gmail.com
 2. http://www.w3.org/TR/2011/CR-xmldsig-core1-20110303/


=

Your comment on :
 Add link and informative reference to XML SIgnature Best Practices
 document to XML Signature 1.1 introduction.


Working Group Resolution (LC-2504):
Editors draft has been updated with text in introduction and reference.

http://lists.w3.org/Archives/Public/public-xmlsec/2011Aug/0003.html

Text added to editors draft: 

The Working Group encourages implementers and developers to read XML
Signature Best Practices [XMLDSIG-BESTPRACTICES]. It contains a number of
best practices related to the use of XML Signature, including
implementation considerations and practical ways of improving security.

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








Re: Pre-LC Review Requested: System Information API

2010-05-11 Thread Frederick Hirsch

There is some confusion on the meaning of internal and external, I
realise. I should make it clearer what I meant:
- internal means battery
- external means AC

In that case we should remove internal/external terminology and define
attributes as:
- isBattery: true if the current power source is a battery
- isBeingCharged: true if the current power source is a battery and is
being charged

What do you think?


This seems clearer and more straightforward.

regards, Frederick

Frederick Hirsch
Nokia



On May 11, 2010, at 10:47 AM, ext Max Froumentin wrote:


On 10/05/2010 17:36, timeless wrote:




If both highThreshold and lowThreshold parameters are
specified, the success callback is triggered if and only if the
property value is either lower than the value of lowThreshold
or higher than the value of highThreshold.

It's odd that you've stuck this into lowThreshold but not high

What do you mean?


== attribute double highThreshold This attribute has no effect on the
get() method. On the monitor() method, it indicates that the
successCallback is only be triggered if the property is a number and
its value is greater than or equal this number. attribute double
lowThreshold This attribute has no effect on the get method. On the
monitor() method, it indicates that the successCallback is only be
triggered if the property is a number and its value is lower than or
equal this number. If both highThreshold and lowThreshold parameters
are specified, the success callback is triggered if and only if the
property value is either lower than the value of lowThreshold or
higher than the value of highThreshold. ==

That last sentence is only present in the description of the second
attribute.



Ah, I see. It was the most logical place to put it. After both high  
and
low were defined, but not separate. I don't know if it's wise  
repeating

the same text in both places, either.


Indicates whether the internal power source is currently
charging. A value of true, indicates that the battery is being
charged. If false then the battery is not being charged.

What if I have an external battery which is being charged?

then both isExternal and batteryBeingCharged are true.


The description says internal power source is currently charging,
I'm offering to charge the external power source. I think you should
elide internal.


There is some confusion on the meaning of internal and external, I
realise. I should make it clearer what I meant:
- internal means battery
- external means AC

In that case we should remove internal/external terminology and define
attributes as:
- isBattery: true if the current power source is a battery
- isBeingCharged: true if the current power source is a battery and is
being charged

What do you think?


I've looked for a reference that explained the meaning of all the
terms that I considered, and failed to find one. Do you know if
there is something out there that would indicate what those terms
mean?


Wikipedia's articles here don't seem particularly bad:
http://en.wikipedia.org/wiki/Load_(computing)
http://en.wikipedia.org/wiki/CPU_usage


CPU usage redirects to CPU time, described as The CPU time is often
measured in clock ticks or as a percentage of the CPU capacity. The
name time is rather inadequate, though, so let's go for usage then.


What if I'm using 2 or more connections concurrently?

That's very advanced for this API. See previous discussions on this
topic.


Link please? :)


The tracker is down at the moment, and I'm not sure what to look for  
in

my email, but the group decided that we shouldn't put in the API
features that we can't see used outside of a system monitoring  
context.
For instance, we don't find a common use for exposing multiple CPUs  
and

their frequencies. The same principle applies here: how often does a
device use multiple internet connections? Should it matter to the API
user? I think that the answer is no.



The VPN case worries me.

Sorry to hear. Why?


People are unlikely to be aware that exposing details of their vpn
connection is more interesting and potentially dangerous than just
exposing their network connection. I might be willing to provide the
connection details for my normal network connection, but corporate
policy probably doesn't want me to disclose my vpn's information.
Above you've specified that the UA can only disclose one, so which
does it pick (and how?).


That seems to be a good use case for policy rules, actually. I expect
the policy framework comes up with would cater for this scenario.



TYPE_BLUETOOTH?

or IRDA, RS-232, USB, WAP, etc. I wasn't sure where to draw the
line and include standards that define a whole protocol stack, or
ones that merely act as tethering protocols, or ones that just
encapsulate Ethernet. I'd very much welcome a comprehensive list.


I'd kinda want the list to be based on properties (pulse based v
cable, power expensive, currency expensive, range [short, medium,
long]): USB is Cable+Minor+Free+Short

Re: Minor DigSig feedback

2010-05-06 Thread Frederick Hirsch

Andreas

Thanks, good catch.

regards, Frederick

Frederick Hirsch
Nokia



On May 5, 2010, at 11:41 AM, ext Andreas Kuehne wrote:


Hi all,

just a minor comment found by build a  test case :


Section 7.1. Common Constraints for Signature Generation and  
Validation


1. [...]
2. [...]

3. For each ds:Reference element:

1. The URI attribute MUST be a zip relative path from  
the root of the widget package to the file entry being referenced.




This condition should not be applied to same-document references. It  
only makes sense to 'external' references.


Greetings

Andreas




--
Andreas Kühne phone: +49 177 293 24 97 mailto: kue...@trustable.de

Trustable Ltd. Niederlassung Deutschland Ströverstr. 18 - 59427 Unna  
Amtsgericht Hamm HRB 5868


Directors Andreas Kühne Heiko Veit

Company UK Company No: 5218868 Registered in England and Wales





Re: Minor DigSig feedback

2010-05-06 Thread Frederick Hirsch

in the proposed editors draft [1] this is section 10.2 item #3

I suggest we change 3a from The URI attribute ... to be For  
references that are not same-document references, the URI attribute...



regards, Frederick

Frederick Hirsch
Nokia



On May 5, 2010, at 11:41 AM, ext Andreas Kuehne wrote:


Hi all,

just a minor comment found by build a  test case :


Section 7.1. Common Constraints for Signature Generation and  
Validation


1. [...]
2. [...]

3. For each ds:Reference element:

1. The URI attribute MUST be a zip relative path from  
the root of the widget package to the file entry being referenced.




This condition should not be applied to same-document references. It  
only makes sense to 'external' references.


Greetings

Andreas




--
Andreas Kühne phone: +49 177 293 24 97 mailto: kue...@trustable.de

Trustable Ltd. Niederlassung Deutschland Ströverstr. 18 - 59427 Unna  
Amtsgericht Hamm HRB 5868


Directors Andreas Kühne Heiko Veit

Company UK Company No: 5218868 Registered in England and Wales





Updated Digital Signatures for Widgets Editors Draft

2010-04-08 Thread Frederick Hirsch
I have updated the Digital Signatures for Widgets editors draft  
(note title change agreed earlier) .


http://dev.w3.org/2006/waf/widgets-digsig/

The changes made were noted in http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0028.html 
 and agreed to on today's teleconference [1].


Also updated the XML Security references, passed link checker and  
validator.


This should complete ACTION-519 (For tracker)

Please review section 1.4, example Reference URI=#prop;  section 7.1  
item 3c; section 7.2 paragraph 2 and following note;   section 7.3  
fourth paragraph; and References for [XMLDSIG11], [XMLSecAlgs],  
[XMLDSIG-Properties].


regards, Frederick

Frederick Hirsch
Nokia

[1]  http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0051.html





Re: Widget Signature modification proposal (revised)

2010-04-07 Thread Frederick Hirsch

Andreas

The intent of the proposed change is to remove ambiguity and thus  
enable interop - not to make it more complicated.


I think having a clear profile with fewer choices should make it  
simpler for implementation.


This may be on the agenda for the call this Thursday.

regards, Frederick

Frederick Hirsch
Nokia



On Apr 7, 2010, at 6:04 AM, ext Thomas Roessler wrote:


kue...@trustable.de wrote:
from the implementors perspective these modifications don't  
introduce too much trouble. But I'm a little bit concerned about  
the explicit ban of canonicalizations for 'external' documents like  
config.xml.


It is, in the first place, the default behavior of the XML Signature
Reference Processing Model for external documents.

You're right that there's a possible design choice here to *permit*  
(not

mandate) canonicalization regardless. It sounds like you suggest that
the WG make that choice, by not prohibiting use of C14N for XML  
content,

but simply leaving it open?






Re: Widget Signature modification proposal (revised)

2010-04-07 Thread Frederick Hirsch

Thanks Andreas

Yes it seems counter-intuitive not to canonicalize XML, but  it is  
really only needed once the XML has been parsed, and avoiding  
canonicalization saves resources.


Are you aware of the XML Security WG  and the recent FPWD of Canonical  
XML 2.0 [1] and XML Signature 2.0 [2]? These are intended to improve  
simplicity, usability, streamability, reduced attack surface etc. Your  
comments would be very welcome!


regards, Frederick

Frederick Hirsch
Nokia

[1] http://www.w3.org/TR/2010/WD-xml-c14n2-20100304/

[2] http://www.w3.org/TR/2010/WD-xmldsig-core2-20100304/


On Apr 7, 2010, at 9:00 AM, ext kue...@trustable.de wrote:


Hi Frederik, hi Thomas !

I don't want to critisize the decisions taken by your group. To keep  
implementations and testing easy is a good reason !


But from my outside view it's a bit suprising : Seeing that XMLDSig  
is used let's me expect a complex solution. So it would be good to  
read at the introduction level that the use of  XMLDSig is limited  
to a small subset and doesn't necessarily implies a huge  
infrastructure.


Another aspect of XMLDSig's complexity is the way people used work  
with it. For example I would add a canonicalization step to each  
external XML document without thinking about it ... So I would  
mandate an explicit note in the spec and maybe a special error  
definition in case a canonicalization is used or other widget  
specific constraints are violated.


Greetings

Andreas

- original Nachricht 

Betreff: Re: Widget Signature modification proposal (revised)
Gesendet: Mi, 07. Apr 2010
Von: Frederick Hirschfrederick.hir...@nokia.com


Andreas

The intent of the proposed change is to remove ambiguity and thus
enable interop - not to make it more complicated.

I think having a clear profile with fewer choices should make it
simpler for implementation.

This may be on the agenda for the call this Thursday.

regards, Frederick

Frederick Hirsch
Nokia



On Apr 7, 2010, at 6:04 AM, ext Thomas Roessler wrote:


kue...@trustable.de wrote:

from the implementors perspective these modifications don't
introduce too much trouble. But I'm a little bit concerned about
the explicit ban of canonicalizations for 'external' documents like
config.xml.


It is, in the first place, the default behavior of the XML Signature
Reference Processing Model for external documents.

You're right that there's a possible design choice here to *permit*
(not
mandate) canonicalization regardless. It sounds like you suggest  
that

the WG make that choice, by not prohibiting use of C14N for XML
content,
but simply leaving it open?







--- original Nachricht Ende 






Re: Widget Signature modification proposal (revised)

2010-04-07 Thread Frederick Hirsch

umm, not FPWD, rather updated WD ...

Also, the 2.0 requirements document is here: 
http://www.w3.org/TR/2010/WD-xmlsec-reqs2-20100204/

The latest publications status of all 1.1 and 2.0 XML Security  
documents is at  http://www.w3.org/2008/xmlsec/wiki/PublicationStatus


regards, Frederick

Frederick Hirsch
Nokia



On Apr 7, 2010, at 9:19 AM, Hirsch Frederick (Nokia-CIC/Boston) wrote:


Thanks Andreas

Yes it seems counter-intuitive not to canonicalize XML, but  it is
really only needed once the XML has been parsed, and avoiding
canonicalization saves resources.

Are you aware of the XML Security WG  and the recent FPWD of Canonical
XML 2.0 [1] and XML Signature 2.0 [2]? These are intended to improve
simplicity, usability, streamability, reduced attack surface etc. Your
comments would be very welcome!

regards, Frederick

Frederick Hirsch
Nokia

[1] http://www.w3.org/TR/2010/WD-xml-c14n2-20100304/

[2] http://www.w3.org/TR/2010/WD-xmldsig-core2-20100304/


On Apr 7, 2010, at 9:00 AM, ext kue...@trustable.de wrote:


Hi Frederik, hi Thomas !

I don't want to critisize the decisions taken by your group. To keep
implementations and testing easy is a good reason !

But from my outside view it's a bit suprising : Seeing that XMLDSig
is used let's me expect a complex solution. So it would be good to
read at the introduction level that the use of  XMLDSig is limited
to a small subset and doesn't necessarily implies a huge
infrastructure.

Another aspect of XMLDSig's complexity is the way people used work
with it. For example I would add a canonicalization step to each
external XML document without thinking about it ... So I would
mandate an explicit note in the spec and maybe a special error
definition in case a canonicalization is used or other widget
specific constraints are violated.

Greetings

Andreas

- original Nachricht 

Betreff: Re: Widget Signature modification proposal (revised)
Gesendet: Mi, 07. Apr 2010
Von: Frederick Hirschfrederick.hir...@nokia.com


Andreas

The intent of the proposed change is to remove ambiguity and thus
enable interop - not to make it more complicated.

I think having a clear profile with fewer choices should make it
simpler for implementation.

This may be on the agenda for the call this Thursday.

regards, Frederick

Frederick Hirsch
Nokia



On Apr 7, 2010, at 6:04 AM, ext Thomas Roessler wrote:


kue...@trustable.de wrote:

from the implementors perspective these modifications don't
introduce too much trouble. But I'm a little bit concerned about
the explicit ban of canonicalizations for 'external' documents  
like

config.xml.


It is, in the first place, the default behavior of the XML  
Signature

Reference Processing Model for external documents.

You're right that there's a possible design choice here to *permit*
(not
mandate) canonicalization regardless. It sounds like you suggest
that
the WG make that choice, by not prohibiting use of C14N for XML
content,
but simply leaving it open?







--- original Nachricht Ende 








Re: Widget Signature Issue and Proposed Resolution

2010-03-31 Thread Frederick Hirsch
Based on some feedback I have a revision to the Normative change (same  
intent)  and also a clarification that might be helpful:


(A) Revised Proposal

Disallow all Transforms except for a single canonicalization  
transform  that is required for every ds:Reference that needs XML  
content canonicalization.


Specifically, this would result in the following changes to the   
Widget  Signature specification  [1]:


(1) Normative change:

(a) Section 7.1 Common Constraints for Signature Generation and  
Validation


Change 3c from The ds:Reference MUST NOT have any ds:Transform   
elements. to


A ds:Reference to any XML content MUST have a ds:Transform element  
child that specifies the canonicalization method.
Canonical XML 1.1 MUST be specified as the Canonicalization  Algorithm  
for this transform.


Sectjon 7.2, add

Every ds:Reference to XML content MUST have exactly one ds:Transform  
element to specify the canonicalization method. Canonical XML 1.1 MUST  
be specified as the Canonicalization  Algorithm.


Note that this specifically means that a ds:Reference to the ds:Object  
element and the ds:Reference to config.xml will each require a  
ds:Transform element to specify canonicalization method.


Section 7.3, add after the third paragraph (If a ds:KeyInfo element  
is present) the following new paragraph:


When validating a Widget Signature, a validator MUST be able to  
process a ds:Reference that has a ds:Transform specifying the  
canonicalization method. The validator MUST be able to process a  
ds:Reference that specifies Canonical XML 1.1 as a canonicalization  
method. The validator SHOULD also be able to process XML content with  
a ds:Reference  that does not include a ds:Transform by using the  
default Canonical XML 1.0 canonicalization method.


(2) Non-normative change:

1.4 Example, (formatting appropriately and renumbering lines)

Change Reference URI=config.xml

to

Reference URI=config.xml
Transforms  Transform Algorithm=http://www.w3.org/2006/12/xml- 
c14n11//Transforms


Change Reference URI=#prop

to

Reference URI=#prop
Transforms  Transform Algorithm=http://www.w3.org/2006/12/xml- 
c14n11//Transforms


--

(B) Clarificationn

There are two different places in XML Signature where XML  
canonicalization applies, hence  leading to possible confusion.


First, there is the canonicalization of SignedInfo. This  is  
determined by the CanonicalizationMethod of SignedInfo. This only   
applies to the canonicalization of SignedInfo itself, however


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

Second,  there is the  canonicalization of XML referenced using a   
ds:Reference,  for example both the ds:Object element and the  
config.xml in the Widget Signature case.


In each case the content obtained from the URI for the ds:Reference  
requires canonicalization unless already an octet stream, so by  
default canonicalization is used to convert the XML to an octet   
stream. If no transform is specified, then the default 1.0   
canonicalization algorithm is used. This has two problems - it isn't   
obvious that canonicalization was done at all and this might become  
an  interop problem, and Canonical XML 1.0 is used instead of 1.1  
(that  fixes known issues with xml:id). By putting an explicit  
Transform  within each ds:Reference element it makes this all clear.


There is no mechanism in XML Signature to specify how all ds:Reference  
elements to XML are to be canonicalized - it is specified individually  
for each Reference, and in XML Signature 1.1 and earlier this is done  
by specifying a transform, as noted in this example 2.1 from XML  
Signature 1.1:


[s05] Reference URI=http://www.w3.org/TR/2000/REC-xhtml1-2126/;
 [s06] Transforms
 [s07] Transform Algorithm=http://www.w3.org/2006/12/xml-c14n11/
 [s08] /Transforms
 [s09] DigestMethod Algorithm=http://www.w3.org/2001/04/ 
xmlenc#sha256/

 [s10] DigestValuedGhpcyBpcyBub3QgYSBzaWduYXR1cmUK.../DigestValue
 [s11] /Reference

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


regards, Frederick

Frederick Hirsch
Nokia



On Mar 29, 2010, at 4:16 PM, Hirsch Frederick (Nokia-CIC/Boston) wrote:


ISSUE:  Widget Signature : Not specifying Canonicalization algorithm
explicitly

Detail: The current Widget Signature specification does not allow the
use of XML Signature Transforms, however the only means to explicitly
specify the Canonicalization method to use  to use a transform (in
XML  Signature 1.1 and earlier). Using the default may be
problematical if  organizations are not able to confirm the default in
use, or because a  different algorithm is required (for example with
an Id on ds:Object   Canonical XML 1.1 should be used, but the default
is Canonical XML  1.0)

PROPOSAL:

Disallow all Transforms except for a single canonicalization
transform  that is required for every ds:Reference that needs XML
content canonicalization

Widget Signature Issue and Proposed Resolution

2010-03-29 Thread Frederick Hirsch
ISSUE:  Widget Signature : Not specifying Canonicalization algorithm  
explicitly


Detail: The current Widget Signature specification does not allow the   
use of XML Signature Transforms, however the only means to explicitly  
specify the Canonicalization method to use  to use a transform (in  
XML  Signature 1.1 and earlier). Using the default may be  
problematical if  organizations are not able to confirm the default in  
use, or because a  different algorithm is required (for example with  
an Id on ds:Object   Canonical XML 1.1 should be used, but the default  
is Canonical XML  1.0)


PROPOSAL:

Disallow all Transforms except for a single canonicalization  
transform  that is required for every ds:Reference that needs XML  
content canonicalization.


Specifically, this would result in the following changes to the  
Widget  Signature specification  [1]:


(1) Normative change:

Section 7.1 Common Constraints for Signature Generation and Validation

Change 3c from The ds:Reference MUST NOT have any ds:Transform   
elements. to


The ds:Reference MUST NOT have any ds:Transform elements other than  
a  single Transform to specify the canonicalization method. A   
ds:Transform element specifying Canonicalization method  MUST be   
present when the ds:Reference is known to reference XML content.   
Canonical XML 1.1 MUST be specified as the Canonicalization   
Algorithm. For example, a ds:Transform specifying the canonicalization  
method is needed for the config.xml reference as well as the Object  
reference.


(2) Non-normative change:

1.4 Example

Add

Transforms  Transform Algorithm=http://www.w3.org/2006/12/xml- 
c14n11//Transforms
as the first child element of the following Reference elements in the   
example 1.4 (formatting appropriately and renumbering lines):

Reference URI=config.xml
Reference URI=#prop
--

regards, Frederick

Frederick Hirsch
Nokia

[1] http://www.w3.org/TR/widgets-digsig/



Please review LCWD of XML Signature 1.1 and Signature Properties; 2.0 draft information

2010-02-12 Thread Frederick Hirsch
The XML Security WG is asking WebApps WG for review of the XML  
Signature 1.1 and Signature Properties Last Call drafts. Though the  
formal deadline is March 18,  we would prefer comments in February if  
possible.


Some more information:

* Signature 1.1 draft: http://www.w3.org/TR/xmldsig-core1/

* changes from 1.0 (2nd Edition) http://www.w3.org/TR/xmldsig-core1/explain.html

Changes are focused on the set of mandatory to implement algorithms  
and markup for relevant key material.


* Signature Properties : 
http://www.w3.org/TR/2010/WD-xmldsig-properties-20100204/

As Art noted below, there are other related documents that have been  
updated. The full list is at the XMLSec publication page


http://www.w3.org/2008/xmlsec/wiki/PublicationStatus

I should also point out that the Canonical XML 2.0 and XML Signature  
2.0 drafts in progress might be of interest to members of this group,  
since they are to address goals to improve performance, usability,  
streamability and reduced attack surface. These are works in progress:


* 2.0 Requirements: 
http://www.w3.org/2008/xmlsec/Drafts/xmlsec-reqs2/Overview.html

* Canonical XML 2.0: http://www.w3.org/2008/xmlsec/Drafts/c14n-20/

* XML Signature 2.0: http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/

regards, Frederick

Frederick Hirsch, Nokia
Chair XML Security WG



On Feb 10, 2010, at 6:48 AM, Barstow Art (Nokia-CIC/Boston) wrote:


Last week the XML Security WG published LCWDs of two specs the Widget
Digital Signature CR [Widget-DigSig] references:

  XML Signature Properties
  http://www.w3.org/TR/2010/WD-xmldsig-properties-20100204/

  XML Signature Syntax and Processing Version 1.1
  http://www.w3.org/TR/2010/WD-xmldsig-core1-20100204/

The comment deadline is March 18. Some additional details below.

-Art Barstow

[Widget-DigSig] http://www.w3.org/TR/2009/CR-widgets-digsig-20090625/


Last Call for Two XML Signature Drafts; Other Drafts Updated

   04 February 2010 | Archive

   http://www.w3.org/News/2010#entry-8712

   The XML Security Working Group published two Last Call Working
   Drafts:

   http://www.w3.org/2008/xmlsec/
 * XML Signature Syntax and Processing 1.1, which specifies
   XML syntax and processing rules for creating and
   representing digital signatures. XML Signatures can be
   applied to any digital content, including XML.
 * XML Signature Properties, which outlines proposed standard
   XML Signature Properties syntax and processing rules and an
   associated namespace for these properties. The intent is
   these can be composed with any version of XML Signature
   using the XML SignatureProperties element.

   The group welcomes Last Call comments through 18 March. The
   group also published several other drafts today: XML Security
   1.1 Requirements and Design Considerations, XML Security
   RELAX NG Schemas, XML Security 2.0 Requirements and Design
   Considerations, XML Signature Transform Simplification:
   Requirements and Design, and XML Signature Best Practices.
   Learn more about XML Technology.

   http://www.w3.org/TR/2010/WD-xmlsec-reqs-20100204/
   http://www.w3.org/TR/2010/WD-xmlsec-rngschema-20100204/
   http://www.w3.org/TR/2010/WD-xmlsec-reqs2-20100204/
   http://www.w3.org/TR/2010/NOTE-xmldsig-simplify-20100204/
   http://www.w3.org/TR/2010/WD-xmldsig-bestpractices-20100204
   http://www.w3.org/standards/xml/







Editorial Update: Signature Properties

2010-01-08 Thread Frederick Hirsch
fyi, I've updated Signature Properties editors draft to include links  
to a standalone Signature example XML file showing all properties  
(without crypto) , and standalone XML Schema file (thanks to Scott  
Cantor for getting the schema right).


No change to the Role or Profile as we have had to date.

This should not break any implementations but make it easier to find  
and work with the schema.


Comments/corrections welcome.

Thanks

regards, Frederick

Frederick Hirsch
Nokia



Begin forwarded message:

From: Hirsch Frederick (Nokia-CIC/Boston) frederick.hir...@nokia.com 


Date: January 8, 2010 8:39:27 AM EST
To: XMLSec WG Public List public-xml...@w3.org
Cc: Hirsch Frederick (Nokia-CIC/Boston) frederick.hir...@nokia.com
Subject: Editorial Update: Signature Properties

I have updated the SIgnature Properties editors draft [1] with the
following changes :

1. Added new Schema section, with link to standalone XSD schema
document and example XML document.

2. Updated schema portions in document with corrections from Scott,
also changed format to remove Example notation.

3. Added place holder for RNG schema

4. Added Reference for Schema Part 1, internal update for consistency
in references.

Much thanks to Scott for updating the schema (same meaning but revised
to be valid schema).

regards, Frederick

Frederick Hirsch
Nokia

[1] http://www.w3.org/2008/xmlsec/Drafts/xmldsig-properties/Overview.html






Re: [widgets] DigSig - proposed change to XML Signature Properties

2010-01-07 Thread Frederick Hirsch
Given the CR stage [1] of Widgets Signature, it probably makes sense  
to not make this schema change, since it would break implementations,  
even though changes are still allowed at this stage. As Scott notes,  
it is more of a style issue - however I thought it worth mentioning  
given that Signature Properties is about to enter Last Call.



regards, Frederick

Frederick Hirsch
Nokia

[1] http://www.w3.org/2005/10/Process-20051014/tr.html#cfi


On Jan 7, 2010, at 2:17 PM, Barstow Art (Nokia-CIC/Boston) wrote:


The XML Security WG is considering changing the syntax of the Profile
and Role elements of the XML Signature Properties spec.

It appears to me the proposed change would affect at least sections 5.
{1,2,3} and the example.

If you have any comments on the proposed changes, please send them to
both public-webapps@w3.org and public-xml...@w3.org.

Frederick, Scott - would you please explain the rationale for the
proposed change?

-Art Barstow

Begin forwarded message:


From: Hirsch Frederick (Nokia-CIC/Boston)
frederick.hir...@nokia.com
Date: January 7, 2010 1:31:20 PM EST
To: ext Scott Cantor canto...@osu.edu
Cc: Hirsch Frederick (Nokia-CIC/Boston)
frederick.hir...@nokia.com, XMLSec WG Public List public-
xml...@w3.org, Barstow Art (Nokia-CIC/Boston)
art.bars...@nokia.com
Subject: Re: ISSUE-163, standalone XSD and RNG schema needed for
Signature Properties

Thanks very much Scott.

I'll check with Art Barstow, Chair of WebApps regarding the  
suggestion

to change the Profile and Role elements to see if that would have a
negative impact on them.

What do others think, any issue with making that change if acceptable
to the Webapps WG? Any objection?

specifically, I think the suggestion is to change

element name=Profile type=dsp:ProfileType/
  complexType name=ProfileType
attribute name=URI type=anyURI/
  /complexType

to

element name=Profile type=anyURI/

and likewise for Role.

Are there any other issues or concerns with this updated schema that
Scott sent? I'd like to update the Signature Properties schema
snippets to match, link in this schema, and get help on creating an
RNG schema (anyone here feel that they can handle it for this
relatively simple schema?)

I'd also like to incorporate an example as Scott suggests, preferably
one from WebApps.

regards, Frederick

Frederick Hirsch
Nokia



On Jan 7, 2010, at 12:18 PM, ext Scott Cantor wrote:


I checked in a draft xsd schema file after extracting the schema
from
the examples and starting to try to fix some errors, in case that
helps an easier start:



http://www.w3.org/2008/xmlsec/Drafts/xmldsig-properties/xmldsig-
properties-

schema.xsd


A valid version is attached, with the following changes:

- fixing some errors and missing prefixes
- removing extra type definitions when the element is just a
string or
dateTime

In addition, I would suggest changing the two properties that are
empty
elements with the URI attributes into elements with a type of anyURI
and
just putting the value into the element.

Note that I'm also just correcting the schema as given, and since
there are
no examples in the document, I can't tell you for sure whether the
XML you
*want* is represented.

-- Scott

xmldsig-properties-schema.xsd









Re: [WARP4U] WARP with UPnP, was: RE: [widgets] Draft Minutes for 19 November 2009 Voice Conference

2009-12-03 Thread Frederick Hirsch

+1, duplicating material is a recipe for disaster.

regards, Frederick

Frederick Hirsch
Nokia



On Dec 2, 2009, at 8:22 AM, ext Robin Berjon wrote:


On Dec 1, 2009, at 22:22 , Marcin Hanclik wrote:

Can you please update this to just be a delta?
As far as I know W3C specs, delta documents are usually errata or  
WG Notes.


What we have been calling delta specification in WebApps are  
specifications that add to another. For instance, WARP adds the  
access element to P+C. It doesn't make some huge cut and paste of P 
+C just because it modifies. This is as much about sane editing  
practice and being able to work with a team as it is about clean  
architecture and separation of concerns.


The expectation was that WARP4U would add something to WARP, perhaps  
attributes, perhaps attribute values, perhaps child elements, and  
certainly some processing. It's a delta spec. It's not considered to  
be the next version, it's a different feature set.



Therefore I would keep the document as it is.


I then have to maintain the strongest objection possible to it being  
published, even as FPWD. Such copying is inappropriate, and will  
lead to no end of editorial problems. It fosters confusion and  
brings no value.


--
Robin Berjon - http://berjon.com/









Re: Security evaluation of an example DAP policy

2009-11-20 Thread Frederick Hirsch

Jeremy

Thanks. I want to make sure I understand the concerns.

I guess the question is whether one can bake all the security in that  
is needed for various (possibly conflicting) use cases, including  
those that do not presume user interaction. An argument for  policy is  
to decouple the mechanism from the decision criteria to get that  
flexibility, while making sure the mechanism is secure.  On the other  
side I hear the concern that the mechanism cannot be as secure.


I note that the policy requirements document includes some use cases  
Paddy contributed in an earlier email:


http://dev.w3.org/2009/dap/policy-reqs/#use-cases

So for example, how does one bake in these:

The weather.example.com Widget can connect to weather.example.com  
without notifying the user, except when roaming.


Reliably identified Websites can send and receive SMS except to  
premium rate numbers.


Do we need to go into more detail on these two (as examples)?

regards, Frederick

Frederick Hirsch
Nokia



On Nov 20, 2009, at 9:15 AM, ext Jeremy Orlow wrote:

These are reasons, but I think the greatest cause of our concern is  
that we have not seen any examples of how policies can provide the  
same level of security that baking security into the API from the  
beginning can provide.


All too often the policy based approaches fall back on either asking  
the user or simply denying access--both of which are not viable  
solutions in most cases within the browser.  If we take security  
into account when designing the APIs we can often find creative  
approaches that satisfy all of the requirements/use-cases while  
providing an API that can be on by default.


On Fri, Nov 20, 2009 at 1:53 PM, Frederick Hirsch frederick.hir...@nokia.com 
 wrote:
My understanding from reading the thread is that the concern is with  
complexity, increased attack surface due to mechanisms that can be  
used in unanticipated ways or misconfigured, and management issues.


Thus though policy can state a simple approach, I'm not sure the  
above concerns are addressed by that expression.


I think we need to work through the use cases, both for those that  
do need a policy language and those that do not, then consider if  
APIs have various methods as Robin suggested, or otherwise how it  
will all fit together.


regards, Frederick (not as chair)

Frederick Hirsch
Nokia




On Nov 19, 2009, at 7:49 PM, ext Marcin Hanclik wrote:

Hi Jonas, Maciej,

It seems that the policy that you would accept would be:

policy-set combine=deny-overrides
policy description=Default Policy for websites. Simply denying all  
API that are covered by some device capability:) 

 target
   subject
 subject-match attr=class match=website func=equal/
   /subject
 /target
 rule effect=deny
   condition
 resource-match attr=device-cap func=regexp/.+//resource- 
match

   /condition
 /rule
/policy
/policy-set

Let's see how DAP will evolve then.

Thanks,
Marcin

From: Maciej Stachowiak [...@apple.com]
Sent: Friday, November 20, 2009 1:26 AM
To: Jonas Sicking
Cc: Marcin Hanclik; Adam Barth; Robin Berjon; public-device-a...@w3.org 
; public-webapps WG

Subject: Re: Security evaluation of an example DAP policy

On Nov 19, 2009, at 4:23 PM, Jonas Sicking wrote:

On Thu, Nov 19, 2009 at 4:07 PM, Marcin Hanclik
marcin.hanc...@access-company.com wrote:
Hi Adam,

I think that
resource-match attr=param:name func=regexp/(C|c):\\(.+)\\(.+)/
resource-match /
should be
resource-match attr=param:name func=regexp/(C|c):\\([^\\]+)\\.
+/resource-match /
up to any further bug in the RE.
Sorry, my problem.

Anyway, the general comment is that the use case is under control
based on the current spec.

For what it's worth, I think any API that opened a dialog asking the
user Do you want to give website X access to directory Y in your file
system would not be an API we'd be willing to implement in firefox.
I.e. our security policy would be to always deny such a request (thus
making implementing the API useless for our users).

Ditto for Safari.

 - Maciej




Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that  
is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure,  
copying or distribution of the information by anyone else is  
strictly prohibited.
If you have received this document in error, please notify us  
promptly by responding to this e-mail. Thank you.










Re: Security evaluation of an example DAP policy

2009-11-20 Thread Frederick Hirsch

Marcin

do you have any more comment on any of the following from the draft  
policy requirements document?


http://dev.w3.org/2009/dap/policy-reqs/#use-cases

Example Widget use cases, to give examples of the types of policy that  
might be expressed:



	• A Widget whose signature chains to operator root can read and write  
from the PIM databases.
	• A Widget downloaded from weather.example.com can access geolocation  
coordinates if the user says it’s OK.
	• The weather.example.com Widget can connect to weather.example.com  
without notifying the user, except when roaming.
	• All Widgets with a reliably identified author can save data  
persistently if the user says it’s OK.

• No Widget can get my location, no matter who trusts it.

Example web site use cases, to give examples of the types of policy  
that might be expressed:



	• A reliably identified website can access geolocation coordinates if  
the user confirms it’s OK.
	• Any Website in a subdomain of mynetwork.example.com can read phone  
status properties.
	• Reliably identified Websites can send and receive SMS except to  
premium rate numbers.

• evil.example.com cannot access any device APIs.
	• The weather.example.com foo widget can access geolocation  
coordinates but only if it’s embedded on the foo home page.


Do you have any more to add, or better use cases? I was going to ask  
about premium rate numbers so thanks for bringing that up.


Can anyone please volunteer to provide more detail on the use cases or  
additional use cases?


regards, Frederick

Frederick Hirsch
Nokia



On Nov 20, 2009, at 10:12 AM, ext Marcin Hanclik wrote:


Hi,


Reliably identified Websites can send and receive SMS except to
premium rate numbers.
There seems to be no worldwide pattern to recognize the premium  
numbers based on the number itself, this could be some network  
operators service or something similar IP-geolocation databases. The  
policy would be very long if we would put all the worldwide  
available premium numbers into it.

Therefore this use case is not fully doable out of the box.
However, BONDI allows to (reliably?) identify websites and allows to  
control sending and receiving SMS.



The weather.example.com Widget can connect to weather.example.com
without notifying the user, except when roaming.

I am not sure what  weather.example.com Widget.
I assume it is the widget that was downloaded from  
weather.example.com.

The BONDI policy format would encode this e.g. like this:

policy-set combine=deny-overrides
policy description=
 target
  subject
subject-match attr=class match=website func=equal/
subject-match attr=uri.host match=weather.example.com  
func=equal/

  /subject
  subject
subject-match attr=class match=widget func=equal/
subject-match attr=install-uri.host  
match=weather.example.com func=equal/

  /subject  /target
 rule effect=deny
  condition combine=or
environment-match attr=roaming func=equalinternational/ 
resource-match

  /condition
 /rule
 rule effect=permit //this seems not needed
  condition combine=or
environment-match attr=roaming func=equalnational/ 
resource-match

  /condition
 /rule /policy
/policy-set

Thanks,
Marcin

P.S. I think I will not write more policies until there is some use  
case that is not doable (at least in my opinion. I may be wrong.)


Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com

-Original Message-
From: Frederick Hirsch [mailto:frederick.hir...@nokia.com]
Sent: Friday, November 20, 2009 3:29 PM
To: ext Jeremy Orlow
Cc: Frederick Hirsch; Marcin Hanclik; Maciej Stachowiak; Jonas  
Sicking; Adam Barth; Robin Berjon; public-device-a...@w3.org; public- 
webapps WG

Subject: Re: Security evaluation of an example DAP policy

Jeremy

Thanks. I want to make sure I understand the concerns.

I guess the question is whether one can bake all the security in that
is needed for various (possibly conflicting) use cases, including
those that do not presume user interaction. An argument for  policy is
to decouple the mechanism from the decision criteria to get that
flexibility, while making sure the mechanism is secure.  On the other
side I hear the concern that the mechanism cannot be as secure.

I note that the policy requirements document includes some use cases
Paddy contributed in an earlier email:

http://dev.w3.org/2009/dap/policy-reqs/#use-cases

So for example, how does one bake in these:

The weather.example.com Widget can connect to weather.example.com
without notifying the user, except when roaming.

Reliably identified Websites can send and receive SMS except to
premium rate numbers.

Do we need to go into more detail on these two (as examples)?

regards, Frederick

Frederick Hirsch
Nokia



On Nov 20, 2009, at 9:15 AM, ext Jeremy Orlow wrote:


These are reasons, but I think the greatest cause of our concern

Re: DAP and security (was: Rename File API to FileReader API?)

2009-11-18 Thread Frederick Hirsch
This is a good point, and an argument for policy rather than  
implicit user consent, if I'm not mistaken. It highlights that  
usability might also be an issue with the non-modal interaction  
model,  as well as not always be very meaningful (since I the user  
might have no idea what most directories are for or where to  
navigate). Arbitrary directory navigation for writing files is not a  
good idea.


More importantly we have to be careful with analogies.


regards, Frederick

Frederick Hirsch
Nokia



On Nov 18, 2009, at 3:14 PM, ext Jonas Sicking wrote:

On Wed, Nov 18, 2009 at 5:27 AM, David Rogers  
david.rog...@omtp.org wrote:

Hi Maciej,

From my side I'd like to understand what your thoughts and  
proposals for file writing security / policy would entail - would  
you defer the decision responsibility to the user via a prompt?


From my point of view the answer is unfortunately there are no  
simple

answers, it's always a judgement call.

For example for the geolocation the security model is basically:

1. Page asks for user position
2. User is faced with a non-modal dialog where he/she can answer yes
or no, or simply ignore the dialog
3. Only if the user answers yes then the position is returned to  
the page.


In this case I think this was an acceptable solution.

If we added a directory API which gave access to a requested path on
the users hard drive we could use a similar security model:

1. Page asks user for permission to read/write to a specific
directory, say C:\
2. User is faced with a non-modal dialog where he/she can answer yes
or no, or simply ignore the dialog
3. Only if the user answeres yes a reference to the directory is
returned which the page can read from/write to.

This would *not* be an acceptable solution to me, despite being
basically identical to the geolocation case.

The reason is two-fold. I think it's easier to explain to the user
what the user is authorizing (your location), and if a user doesn't
understand and still clicks yes, it has less catastrophic results.

For the directory API though, it's much harder to explain the decision
to the user. What's the C:\ directory? What's the difference between
that and C:\Documents and Settings\Jonas Sicking\My Images? What's a
directory? Also, if a user clicks yes without understanding the
risks, that has catastrophic results if the directory in question is
C:\ and read/write access is granted.

When it comes to security dialogs, the basic rule to keep in mind is
Lots of people are not going to understand it and just click whatever
button they think will get stuff to work, or a random button.

/ Jonas






Re: Rename “File API” to “FileReader API”?

2009-11-11 Thread Frederick Hirsch

I would be concerned with leaving file writing to DAP, because a
widely held view in DAP seems to be that security can be ignored while
designing APIs and added back later with an external policy file   
mechanism.


From the F2F my understanding is that DAP will consider security as  
an integral part of API development, while also developing policy  
mechanisms, thus I do not think the view you mention is widely held.


regards, Frederick

Frederick Hirsch
Nokia



On Nov 10, 2009, at 8:47 PM, ext Maciej Stachowiak wrote:



On Nov 10, 2009, at 3:09 AM, Robin Berjon wrote:


On Nov 10, 2009, at 11:27 , Maciej Stachowiak wrote:

On Nov 10, 2009, at 2:01 AM, Arve Bersvendsen wrote:
On Tue, 10 Nov 2009 10:59:23 +0100, Adam Barth w...@adambarth.com
wrote:



Which is the proper mailing list to follow development of the file
writing API?  I'd like to follow it's security considerations.


public-device-a...@w3.org


At TPAC, I recall that we proposed drawing the line between file
reading/writing on the one hand (presumably to go in the current
File API spec) and filesystem access (including messing with
directories, mountpoints, file renames etc) to be done in the
Filesystem API spec. Do we need further discussion to settle what
goes in which spec?


No, we agreed that File Reader would keep going on in WebApps
because there's no reason to move something that's making progress
(unless Arun wants to move it, he's in both WGs anyway), but that
the rest would be done in DAP since it's more security sensitive and
new (and chartered there).



I don't recall agreeing to that. I remember that we discussed multiple
options, and I do not believe there was a resolution recorded along
the lines of what you say. (But if I'm wrong, I guess the minutes will
show.

I think file writing (once the script has securely received a file
handle) has different security considerations than directory
manipulation and opening of arbitrary files. File writing should be
designed with the browser security model in mind, because it's
something that is reasonable to expose to Web content, given the right
model for getting a writable handle (private use area or explicitly
chosen by the user via Save As dialog). I think directory
manipulation and opening of arbitrary files can't be fit into that
security model and has to rely on a widget security model where
there is an overall user trust decision.

I would be concerned with leaving file writing to DAP, because a
widely held view in DAP seems to be that security can be ignored while
designing APIs and added back later with an external policy file
mechanism. I would also be concerned with tying file writing to
directory manipulation, because I think the former is reasonable to do
in browsers and not the latter. Perhaps this means that we need three
specs?

Regards,
Maciej







Proposed additional topic for joint DAP/WebApps Widgets F2F session

2009-10-29 Thread Frederick Hirsch
If we have time and interest,  I suggest we might also discuss in the  
joint DAP/WebApps Widgets session HTML5 security model, even if we  
also discuss in the joint DAP/WebApps API session, depending on the  
expertise in the room.


I would like to make sure we transfer understanding to the DAP WG from  
everyone who can help the DAP WG and I'd like to make sure that  
somehow we have this discussion during TPAC.


Thus Agenda topic for joint DAP/Webapps-Widget is Security  
Considerations, including HTML5.


regards, Frederick

Frederick Hirsch, Nokia
Co-Chair, W3C DAP Working Group




Re: Proposed additional topic for joint DAP/WebApps Widgets F2F session

2009-10-29 Thread Frederick Hirsch

David

Would it be possible for you to summarize what you think the issue is,  
as far as architecture and technical disparities, as a first step?


regards, Frederick

Frederick Hirsch
Nokia



On Oct 29, 2009, at 11:54 AM, ext David Rogers wrote:


Hi,

As discussed on the webapps call, in addition to Fredrick's proposal I
think we need to understand the relationship between DAP / Widgets /
WebApps / HTML5 more clearly. There are overlaps and architectural
disparities which we should highlight and come up with a plan for
dealing with. Would it be possible for the chairs to come up with some
input in terms of an architecture diagram of where they think we are?

Thanks,


David.

-Original Message-
From: public-device-apis-requ...@w3.org
[mailto:public-device-apis-requ...@w3.org] On Behalf Of Frederick  
Hirsch

Sent: 29 October 2009 14:28
To: public-Webapps@w3.org WG
Cc: Frederick Hirsch; Charles McCathieNevile; W3C Device APIs and  
Policy

WG
Subject: Proposed additional topic for joint DAP/WebApps Widgets F2F
session

If we have time and interest,  I suggest we might also discuss in the
joint DAP/WebApps Widgets session HTML5 security model, even if we
also discuss in the joint DAP/WebApps API session, depending on the
expertise in the room.

I would like to make sure we transfer understanding to the DAP WG from
everyone who can help the DAP WG and I'd like to make sure that
somehow we have this discussion during TPAC.

Thus Agenda topic for joint DAP/Webapps-Widget is Security
Considerations, including HTML5.

regards, Frederick

Frederick Hirsch, Nokia
Co-Chair, W3C DAP Working Group







Re: Widget DigSign: Example of a distributor signature document is buggy

2009-10-08 Thread Frederick Hirsch
I think the first document should be re-titled (since it isn't generic  
to XML Signature 1.1):


Widgets 1.0: Test Suite for Widget Signature 1.0

It also seems we have two types of tests:

1. syntactic tests that check the presence and placement of XML  
material - such as locating the signature in the widget package,  
syntax correctness, presence of required property elements,  and use  
of Role attribute for author and distributor signatures.


2. Signature value verification when specific algorithms are used for  
a given input.



regards, Frederick

Frederick Hirsch
Nokia



On Oct 8, 2009, at 8:07 AM, ext Kai Hendry wrote:


Hopefully further (correct) examples are here:
http://dev.w3.org/2006/waf/widgets-digsig/tests/
http://dev.w3.org/2006/waf/widgets-digsig/tests/test-suite- 
unstable.xml


Review is very welcome,





Re: Widget DigSign: Example of a distributor signature document is buggy

2009-10-07 Thread Frederick Hirsch

Christian

You are correct, thank you for catching this error.

I have updated the editors draft accordingly.

http://dev.w3.org/2006/waf/widgets-digsig/#example

regards, Frederick

Frederick Hirsch
Nokia



On Oct 6, 2009, at 9:44 AM, ext Breitschwerdt, Christian, VF-Group  
wrote:



Hi Marcos,

The position of the object element in the example provided in
http://www.w3.org/TR/widgets-digsig/ section 1.4 is not correct in  
that

the object occurs before the SignatureValue.

The DTD provided fo the XMLDIG11
http://www.w3.org/TR/2009/WD-xmldsig-core1-20090226/xmldsig-core-schema 
.

dtd and also the example
http://www.w3.org/TR/2009/WD-xmldsig-core1-20090226/signature-example.xm
l instruct us that it should occur AFTER the SignatureValue.

The major problem with the example is that even it is non-normative it
may be used by implementors as a template, and some existing XML
security tools  chains (i.e. Apache XML security library) will fail to
process a template that has the object in the wrong order.

Kind regards,
Christian






Re: HTML extension for system idle detection.

2009-09-17 Thread Frederick Hirsch
isn't the mere knowledge of the level of activity on a device a  
possible privacy concern, and couldn't the pattern of activity offer a  
traffic analysis type opportunity?


regards, Frederick

Frederick Hirsch
Nokia



On Sep 17, 2009, at 1:35 PM, ext Jeremy Orlow wrote:

On Thu, Sep 17, 2009 at 12:50 AM, Arve Bersvendsen ar...@opera.com  
wrote:
On Thu, 17 Sep 2009 00:05:58 +0200, David Bennett d...@google.com  
wrote:


I have a proposal for an extension to javascript to enable browsers to
access system idle information.  Please give me feedback and  
suggestions on the proposal.



What exactly are the security and privacy implications of detecting  
system

idle activity in the browser?

As far as I know, there really aren't any.  This was discussed on  
WhatWG (before being directed here) and IIRC there were no serious  
security or privacy concerns.  The minimum resolution of the event  
makes attacks based on keystroke timing impossible.  Some people  
suggested that web apps could do something bad while the user is  
away, but I don't think anyone could come up with a good example of  
something bad.  Can you think of any specific concerns?



On Thu, Sep 17, 2009 at 2:43 AM, Robin Berjon ro...@berjon.com  
wrote:

Hi David,


On Sep 17, 2009, at 00:05 , David Bennett wrote:
I have a proposal for an extension to javascript to enable browsers  
to access system idle information.  Please give me feedback and  
suggestions on the proposal.


Thanks!

SUMMARY

There currently is no way to detect the system idle state in the  
browser.  For example this makes it difficult to deal with any sort  
of chat room or instant messaging client inside the browser since  
the idle will always be incorrect; or allow for apps to control  
their speed or network resources when a user is idle.


This sounds like it /could/ (not sure and no promises) be an area of  
work for DAP, given that it is about device/system information, and  
given that I would expect the user to be in very solid control of  
the security policy granting access to such information. I guess it  
could perhaps be exposed as a system property, part of the System  
Information work.


I'm not sure this is the type of API we need to ask the user about.   
Web apps can already detect when you're on their page, so I'm not  
sure how valuable the additional information you would be leaking  
is.  I'd assume browsers could have a big hammer like disable idle  
reporting for any users who are particularly concerned.



In case it's not clear, I think this is a good proposal and all my  
concerns were addressed in previous threads: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022443.html





Re: [WARP] Last Call comments (1)

2009-09-10 Thread Frederick Hirsch

Is the fundamental difference of feature and access the following:

feature - API set expected to be possibly used
access - network resource to be accessed.

if so, doesn't feature imply both the loading and permission to access  
a library, whereas access is about accessing a resource.


if this is correct, aren't these fundamentally different?

regards, Frederick

Frederick Hirsch
Nokia



On Aug 27, 2009, at 2:06 PM, ext Marcin Hanclik wrote:


Hi All,

Here are a couple of the Last Call comments to WARP LCWD [1].
They were already partially presented in my emails [2] and [3].

The comments below are more of architectural nature than just  
editorial fixes.
That is why the arguments together with the derived understanding  
are followed by the proposed changes to the specification. The  
proposed changes below are incomplete.


MOTIVATION / ARGUMENTS

The main motivation for the changes proposed below is the syntax and  
the underlying architecture related to the treatment of the network  
access - from the widget's or web application's point of view - as  
the resource to which access is to be controlled by some security  
policy.


The specification that underlies the overall widgets ecosystem,  
Widgets 1.0: Packaging and Configuration (further referred to as  
PC) [4], defines a method to express the dependency of the widget  
on a resource/component, namely the feature element.

PC in [5] - the definition of the feature element - states:

A feature is a runtime component

The feature element serves as a standardized means to request the  
binding of an (IRI) identifiable runtime component to a widget for  
use at runtime.


...a widget can attempt to access the feature identified by the  
feature element's name attribute.


PC [6] states non-normatively:
The Widgets 1.0: Access Requests specification defines a means to  
request access to URI-identifiable resources (e.g. resources on the  
Web) (see [Widgets-Access]).


On the other hand, however, WARP states [7]:
 The purpose of this specification is precisely to define the  
security model for network interactions from within a widget that  
has access to sensitive information, and to provide means for a  
widget to declare the need to access specific network resources so  
that a policy may control it.

And [8]
A network resource is a retrievable resource of any type that is  
identified by a URI that has a DNS or IP as its authority.


WARP states that it addresses [9] the requirements [10] and [11].

[10] R52 Default Security Policy:

A conforming specification MUST specify a default security policy  
that limits the privileges afforded to a widget at runtime. The  
default security policy MUST be specified in such a way that it  
forces a widget package to explicitly request permission to use  
particular device capabilities (see also the Security Declarations  
requirement).


[11] R54 Security Declarations:

A conforming specification MUST specify or recommend a means for  
declaring that an instantiated widget will require access to  
resources or services that have the potential to introduce a  
security risk for an end user. A conforming specification SHOULD  
also make it possible to externalize and associate security  
declarations with a particular widget package (e.g., by allowing  
security declarations to be securely acquired from an external  
trusted authority over HTTP). This MUST include a means of declaring  
the APIs that a widget expects to access. When possible, a  
conforming specification MUST specify a means to verify the  
authenticity and integrity of security declarations included in the  
widget package (e.g. by using Digital Signatures).


One of the motivations against the @required attribute on access  
element was prompting [12], and prompting is included the current  
LCWD [9]. Therefore it is unclear what the argumentation against  
@required attribute is (this is related to the semantics of the  
access and feature elements as outlined below).


The above statements result in the following understanding:

1. WARP specification actually defines the syntax for expression of  
dependency of a widget only on network resources. So here, the name  
of the specification is misleading (taking into account only this  
point, we could require it be named Widgets 1.0: Network Access  
Policy).


2. The dependency of a widget on network resources is atomic and  
unconditional.


3. The resource is identifiable by URI.

4. The URI-identifiable resources are not necessarily truly remote  
network resources.


5. Since network access introduces various risks (e.g. when roaming)  
the requirement [11]:


 A conforming specification MUST specify or recommend a means for  
declaring that  an instantiated widget will require access to  
resources or services that have to the potential to introduce a  
security risk for an end user.


seems not to be fully satisfied, since the access to network  
resources is unconditional

Re: [cors] Additional Comments on 17 March 2009 cors draft

2009-07-01 Thread Frederick Hirsch


So the issue is not confidentiality, it is inappropriate script  
execution. Got it.


Thanks Anne

regards, Frederick

Frederick Hirsch
Nokia



On Jul 1, 2009, at 5:34 AM, ext Anne van Kesteren wrote:


I might not have time to address your larger set of questions before I
leave on vacation tomorrow, but I thought I could at least answer  
this one.


On Tue, 30 Jun 2009 17:38:20 +0200, Frederick Hirsch
frederick.hir...@nokia.com wrote:
One additional question regarding a cross-site get (using browser  
here

for simplicity of terms) (for example, see [1])

Is it true that

1. the GET results in the content being returned on the wire with a
Access-Control-Allow-Origin header
2. the browser then checks this header and enforces policy
3. if policy disallows then the browser does not allow the content  
to be

used.


Yes, this is correct.


In any case, doesn't this open an attack to get the content by  
sniffing

the wire for the response content, regardless of the header?


If that is a viable attack scenario such servers are already exposed  
due
to e.g. cross-origin img or iframe loading which already works  
today.
Or e.g. by simply setting window.location to the address from which  
you

want to sniff the response.

All the header is effectively protecting is exposing the raw  
contents of

a cross-origin resource to script.



[1] http://arunranga.com/examples/access-control/SimpleXSInvocation.txt



--
Anne van Kesteren
http://annevankesteren.nl/





[cors] Comments on 17 March 2009

2009-06-30 Thread Frederick Hirsch
 preflight checking...

18 Editorial: Section 1
In This extension enables server-side applications to enforce  
limitations on the cross-origin requests that they are willing to  
service

clarify the limitations

19 Editorial: Section 2

Replace This specification is written for servers and user agents.  
with This specification is written for implementers of user agents  
that enforce policy, APIs that use it, and web servers that provide  
content that may be used in cross-site manner.


20 Editorial: Section 2
Why is the term hosting specifications given, is it common  
terminology? Can it be removed?


21 Editorial: Section 2
Is a conformant server one that returns appropriate headers for  
requests?


22 Editorial:  Section 4.5
Where is the full list of headers defined? is a reference needed?

23 Editorial: Section 5.1 #1
Can the list of origins be unbounded in practice?

24 Editorial: Section 6
Mark Everything with regards to redirects might change a little to  
more closely adhere to HTTP redirect semantics. as an editors note.


25 Editorial: Section 6.1
some of the spacing between items seems to need additional space

26  Editorial: Section 7.3
Replace progresing with progressing


regards, Frederick

Frederick Hirsch
Nokia






Re: [cors] Additional Comments on 17 March 2009 cors draft

2009-06-30 Thread Frederick Hirsch
One additional question regarding a cross-site get (using browser here  
for simplicity of terms) (for example, see [1])


Is it true that

1. the GET results in the content being returned on the wire with a   
Access-Control-Allow-Origin header

2. the browser then checks this header and enforces policy
3. if policy disallows then the browser does not allow the content to  
be used.


In any case, doesn't this open an attack to get the content by  
sniffing the wire for the response content, regardless of the header?


regards, Frederick

Frederick Hirsch
Nokia

[1] http://arunranga.com/examples/access-control/SimpleXSInvocation.txt

On Jun 30, 2009, at 11:11 AM, Hirsch Frederick (Nokia-CIC/Boston) wrote:


I have some basic comments and questions on Cross-Origin Resource
Sharing, W3C Working Draft 17 March 2009
http://www.w3.org/TR/2009/WD-cors-20090317/

Perhaps some of these have been answered already and there are
probably others I did not list.

1. GET can have side effects, so can we assume it is safe? Thus does
it not also always require pre-flight check?

2. How is Origin set, is it always correct, how is it set for widgets?
Perhaps the document should discuss this.

3. Is there a race condition between preflight request and subsequent
request? What if server changes policy, e.g. allowed methods in this
time.
Is there a requirement on the maximum time between both these actions?

4. Shouldn't the specification require header integrity protection so
they cannot be rewritten during transit? This could require TLS or
secure channel or header signing so the mechanism may not be defined
in the specification, but shouldn't integrity protection be a MUST?

5. Will Access-Control-Allow-Origin header scale if all possible URLs
must be listed (I'm thinking of airline example) .

6. Security sections should be normative and have normative  
statements.


Section 3
- remove statement that section is non-normative
- Replace Authors of client-side Web applications are strongly
encouraged to validate content retrieved from a cross-origin resource
as it might be harmful. with Authors of client-side Web applications
SHOULD validate content retrieved from a cross-origin resource as it
might be harmful.

editorial, replace This section lists advice that did not fit
anywhere else. with This is general security considerations, more
detailed are provided in specific sections.

Section 5.3
- remove statement that section is non-normative
- Replace “are strongly encouraged to” with SHOULD in paragraph 1
- Replace “are strongly encouraged to” with SHOULD in paragraph 2
- Replace To provide integrity protection of resource sharing policy
statements usage of SSL/TLS is encouraged. with statement that
Integrity protection for headers MUST be provided. This MAY take the
form of TLS, header signing, or other mechanisms, as appropriate.

Section 6.3
- remove statement that section is non-normative

- Why is the statement User agents are to carefully follow the rules
set forth in the preceding sections to prevent introducing new attack
vectors. needed? Remove it, since the normative rules  in this
specification must be followed for compliance,  and if important
should be normative.

- Replace “are allowed to” with SHOULD in paragraph 2

- Replace “are encouraged to” with SHOULD in paragraph 3

- Replace User agents are encouraged to apply security decisions on a
generic level and not just to the resource sharing policy. with
These  MUST apply equally to access through APIs (e.g.
XMLHttpRequest) or through inlined content (e.g. iframe, script,
img). (taking from WARP)
It might be that I do not understand this statement, some
clarification would be helpful.

- Replace “is encouraged” with MUST in last sentence.

7. Is there a resolution to Mark Nottingham's concerns  expressed in 
http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0226.html
 ? Aren't these reasonable concerns?

8 Is the party of permissions the site (origin) requesting the
content? What about per-identity permissions? How will this work with
OAuth etc? Will this be a general issue?

9. What is the resolution to the confused deputy concern? Should the
specification note the concern? I'm not sure if the WG has discussed/
resolved this issue.

10  requirements section: Requirement #1 - What is the implied
alternative for additional protection than firewall?

11  requirements section: Is Requirement #2 accurate given that GET
can have side effects so is not always safe?

12  requirements section: How did Requirement #4 impact this
specification? How does this attack come into play with this
specification and if it does, how does the specification address it?

13  requirements section: Is requirement #8 possible? Isn't
configuration required to return headers, deal with pre-flight
requests etc? Or would this be addressed by Mark Nottingham's
suggestion to always return access header?

14  requirements section: Requirement #17, does this include
integration

Re: [widgets] dig sig RelaxNG schema

2009-06-25 Thread Frederick Hirsch

Kai

XML Signature 1.1 is specified using XML Schema [1].  XML Signature  
1.1 has a draft RNG schema [2].  We did not develop an rnc grammar for  
widget signature.


The XML Security WG started to work on an XML Signature 1.1 RNG schema  
[2] but since we do not have deep expertise in the group we have not  
progressed this yet. However the tests from XML Signature Second  
Edition validated against it. We received some feedback about using  
different styles of RNG schema authoring which we do not have much  
expertise in the group to process -  If you are able to help get the  
schema correct that would be helpful. It is on our list of things to  
do to attempt to improve it, if we can get help.


Is having RNG/RNC schema important? Can you or someone in the WebApps  
working group please help, perhaps by reviewing our RNG schema  
document and suggesting improvements?


I'm copying this message with the XML Security WG.

Thanks

regards, Frederick

Frederick Hirsch, Nokia
Chair XML Security WG

[1] http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-Schema

[2] http://www.w3.org/2007/xmlsec/Drafts/xmldsig-rngschema/


On Jun 25, 2009, at 7:13 AM, ext Kai Hendry wrote:


Using http://bondi.omtp.org/1.0/security/xmldsig-core-schema.rnc and
rnv [1] I've been trying to validate the example:
http://www.w3.org/TR/widgets-digsig/#example

Firstly does widgets-digsig have it's own grammar.rnc? I have not been
able to find one.


Using xmldsig-core-schema.rnc I ran into a couple of problems. Firstly
I had to alter:

Object.ANY = (element * {Object.ANY}|attribute * {text}|text)*

To accept the new elements introduced by
http://www.w3.org/TR/xmldsig-properties/

Also the xmldsig-core-schema.rnc seems sensitive to element order. So
I made a change to the rnc to get the example signature1.xml to
validate:

-Signature.attlist, SignedInfo, SignatureValue, KeyInfo?, Object*
+Signature.attlist, SignedInfo, Object*, SignatureValue, KeyInfo?

Or perhaps the order of the example is incorrect?



Be great to see more fully worked examples. An author-signature.xml
example would be good.


Kind regards,


[1] http://www.davidashen.net/rnv.html






Re: Reminder: Comments for LCWD of Widgets 1.0: Digital Signatures due June 1

2009-06-08 Thread Frederick Hirsch
XML Signature 1.1 should be referenced. It defines the URI for the  
algorithms, context for use in XML Signature, and references etc.


regards, Frederick

Frederick Hirsch
Nokia



On Jun 8, 2009, at 8:30 AM, ext Marcin Hanclik wrote:


Hi Marcos,


Also, DSA-SHA-1, RSA-SHA-256, and ECDSA-SHA-256 don't link to any
specifications? Do they have a corresponding spec?


DSA-SHA-1
ANSI X9.57 DSA signature generated with SHA-1 hash (DSA x9.30)
http://www.oid-info.com/get/1.2.840.10040.4.3
SHA-1
http://www.itl.nist.gov/fipspubs/fip180-1.htm


RSA-SHA-256
RSA
http://tools.ietf.org/rfc/rfc2437.txt
SHA-256
http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf

ECDSA-SHA-256
ECDSA is specified in X9.62
http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI+X9.62%3a2005  
(paid resource)

In RFCs it is referred to as:
[X9.62] American National Standards Institute. ANSI X9.62-1998,
 Public Key Cryptography for the Financial Services Industry:
 The Elliptic Curve Digital Signature Algorithm. January 1999.
SHA-256 as above

For SHA-XXX alternatively the following can be used:
http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf
(includes SHA-1, SHA-256 and more)

Thanks.

Kind regards,
Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com

-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org 
] On Behalf Of Marcos Caceres

Sent: Monday, June 08, 2009 1:08 PM
To: Priestley, Mark, VF-Group; Frederick Hirsch
Cc: Arthur Barstow; public-webapps; public-xml...@w3.org
Subject: Re: Reminder: Comments for LCWD of Widgets 1.0: Digital  
Signatures due June 1


On Thu, Jun 4, 2009 at 2:27 PM, Priestley, Mark,
VF-Groupmark.priest...@vodafone.com wrote:

Hi Art, All,

Vodafone has some late comments which it would like to provide to the
group for consideration and apologise for supplying these after the
deadline.

We believe that all but one of the comments is editorial and so there
inclusion or otherwise should not affect or delay the decision to  
go to
CR status, which we support. In submitting these comments it is not  
our

intention or desire to hold up this process, only to provide the
comments for consideration.

The only comment that doesn't fit into this category is a question  
that

has been raised by one of our developers. My hope is that there is
already an answer!

Thanks,

Mark

---
Editorial Comments
---

---[Definition of file entry]---

Section: 1.2

A file entry is the compressed (or Stored [ZIP]) representation of a
physical file or folder contained within a widget package, as  
defined in

the [Widgets Packaging] specification.

In Widgets 1.0: Packaging and Configuration [2] the file entry
definition is different.

A file entry is the data held by a local file header, file data, and
(optional) data descriptor, as defined in the [ZIP] specification,  
for

each physical file contained in a Zip archive.


Fixed.


Comment - the inclusion of folder in the definition in [1] has caused
one reviewer to ask if there should be a reference element for  
folders?
I believe this is not the case and or folder could be removed  
from the

definition.


Using the definition that appears in PC.


---[Requirements accuracy]---

Section: 2

R52. Support for Multiple Signature Algorithms: DSA-SHA-1, RSA- 
SHA-1,

DSA-SHA-256 and RSA-SHA-256.

Are these algorithms still correct? DSA-SHA-256 and RSA-SHA-1 should
probably be removed as they are not required algorithms.


I've removed them.


ECDSA-SHA-256
could be added.



Added, but, Fredrick, there seems to be some inconstancy in the spec
with regards to the use of the algorithm names. Can you please check.

Also, DSA-SHA-1, RSA-SHA-256, and ECDSA-SHA-256 don't link to any
specifications? Do they have a corresponding spec?


[Conflict between mandatory statements]
A user agent MAY support additional signature algorithms. (Section:
6.1)
A user agent MAY support additional digest methods. (Section: 6.2)
A user agent MAY support additional XML canonicalization methods.
(Section: 6.3)

Section: 7.1
The Algorithm attribute of the ds:digestMethod MUST be one of the
digest algorithms.
The Algorithm attribute of the ds:CanonicalizationMethod element  
MUST

be one of the canonicalization algorithms.
The ds:SignatureMethod algorithm used in the ds:SignatureValue  
element

MUST be one of the signature algorithms.

Comment - If in section 6 we say A user agent MAY support additional
XXX algorithms, which seems to be in conflict with section 7 that
states the algorithm used must be one of algorithms listed in  
section 6.

This seems to be an open ended requirement.


I agree.


Suggestion - Remove the statements in section 7.1. It is down to the
signer to choose the algorithm to use. If they choose to use a
non-recommended algorithm

Re: Reminder: Comments for LCWD of Widgets 1.0: Digital Signatures due June 1

2009-06-08 Thread Frederick Hirsch

1) inconsistency question


Added, but, Fredrick, there seems to be some inconstancy in the spec
with regards to the use of the algorithm names. Can you please check.


should be ECDSAwithSHA256 , is that the extent of the inconsistency  
question?


xml signature 1.1 algorithms section

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

2) Also, DSA-SHA-1, RSA-SHA-256, and ECDSA-SHA-256 don't link to any  
specs


I believe we should refer to XML SIgnature 1.1 which then provides  
appropriate material


3) section 6 vs section 7.1

I suggest we keep the language as is. 7.1 says you must use an  
algorithm in section 6, section 6 says you must support certain ones,  
and may support others. There is nothing inconsistent or wrong here.  
Thus if we change the rules in section 6 we do not need to change  
section 7.


(I thought we decided on the last wg call to freeze the spec but I  
guess not... )


regards, Frederick

Frederick Hirsch
Nokia



On Jun 8, 2009, at 7:07 AM, ext Marcos Caceres wrote:


On Thu, Jun 4, 2009 at 2:27 PM, Priestley, Mark,
VF-Groupmark.priest...@vodafone.com wrote:

Hi Art, All,

Vodafone has some late comments which it would like to provide to the
group for consideration and apologise for supplying these after the
deadline.

We believe that all but one of the comments is editorial and so there
inclusion or otherwise should not affect or delay the decision to  
go to
CR status, which we support. In submitting these comments it is not  
our

intention or desire to hold up this process, only to provide the
comments for consideration.

The only comment that doesn't fit into this category is a question  
that

has been raised by one of our developers. My hope is that there is
already an answer!

Thanks,

Mark

---
Editorial Comments
---

---[Definition of file entry]---

Section: 1.2

A file entry is the compressed (or Stored [ZIP]) representation of a
physical file or folder contained within a widget package, as  
defined in

the [Widgets Packaging] specification.

In Widgets 1.0: Packaging and Configuration [2] the file entry
definition is different.

A file entry is the data held by a local file header, file data, and
(optional) data descriptor, as defined in the [ZIP] specification,  
for

each physical file contained in a Zip archive.


Fixed.


Comment - the inclusion of folder in the definition in [1] has caused
one reviewer to ask if there should be a reference element for  
folders?
I believe this is not the case and or folder could be removed  
from the

definition.


Using the definition that appears in PC.


---[Requirements accuracy]---

Section: 2

R52. Support for Multiple Signature Algorithms: DSA-SHA-1, RSA- 
SHA-1,

DSA-SHA-256 and RSA-SHA-256.

Are these algorithms still correct? DSA-SHA-256 and RSA-SHA-1 should
probably be removed as they are not required algorithms.


I've removed them.


ECDSA-SHA-256
could be added.



Added, but, Fredrick, there seems to be some inconstancy in the spec
with regards to the use of the algorithm names. Can you please check.

Also, DSA-SHA-1, RSA-SHA-256, and ECDSA-SHA-256 don't link to any
specifications? Do they have a corresponding spec?


[Conflict between mandatory statements]
A user agent MAY support additional signature algorithms. (Section:
6.1)
A user agent MAY support additional digest methods. (Section: 6.2)
A user agent MAY support additional XML canonicalization methods.
(Section: 6.3)

Section: 7.1
The Algorithm attribute of the ds:digestMethod MUST be one of the
digest algorithms.
The Algorithm attribute of the ds:CanonicalizationMethod element  
MUST

be one of the canonicalization algorithms.
The ds:SignatureMethod algorithm used in the ds:SignatureValue  
element

MUST be one of the signature algorithms.

Comment - If in section 6 we say A user agent MAY support additional
XXX algorithms, which seems to be in conflict with section 7 that
states the algorithm used must be one of algorithms listed in  
section 6.

This seems to be an open ended requirement.


I agree.


Suggestion - Remove the statements in section 7.1. It is down to the
signer to choose the algorithm to use. If they choose to use a
non-recommended algorithm they should understand that user agent  
support

cannot be guaranteed.


Right. Frederick, wdyt?



--
Marcos Caceres
http://datadriven.com.au





Re: Reminder: Comments for LCWD of Widgets 1.0: Digital Signatures due June 1

2009-06-04 Thread Frederick Hirsch
XML Signature 1.1 notes that the order of certificates in X.509Data is  
not specified.


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

Is this really expected to be an issue, with long cert chains?


regards, Frederick

Frederick Hirsch
Nokia



On Jun 4, 2009, at 8:27 AM, ext Priestley, Mark, VF-Group wrote:


Hi Art, All,

Vodafone has some late comments which it would like to provide to the
group for consideration and apologise for supplying these after the
deadline.

We believe that all but one of the comments is editorial and so there
inclusion or otherwise should not affect or delay the decision to go  
to
CR status, which we support. In submitting these comments it is not  
our

intention or desire to hold up this process, only to provide the
comments for consideration.

The only comment that doesn't fit into this category is a question  
that

has been raised by one of our developers. My hope is that there is
already an answer!

Thanks,

Mark

---
Editorial Comments
---

---[Definition of file entry]---

Section: 1.2

A file entry is the compressed (or Stored [ZIP]) representation of a
physical file or folder contained within a widget package, as  
defined in

the [Widgets Packaging] specification.

In Widgets 1.0: Packaging and Configuration [2] the file entry
definition is different.

A file entry is the data held by a local file header, file data, and
(optional) data descriptor, as defined in the [ZIP] specification, for
each physical file contained in a Zip archive.

Comment - the inclusion of folder in the definition in [1] has caused
one reviewer to ask if there should be a reference element for  
folders?
I believe this is not the case and or folder could be removed from  
the

definition.

---[Requirements accuracy]---

Section: 2

R52. Support for Multiple Signature Algorithms: DSA-SHA-1, RSA-SHA-1,
DSA-SHA-256 and RSA-SHA-256.

Are these algorithms still correct? DSA-SHA-256 and RSA-SHA-1 should
probably be removed as they are not required algorithms. ECDSA-SHA-256
could be added.

[Conflict between mandatory statements]

A user agent MAY support additional signature algorithms. (Section:
6.1)
A user agent MAY support additional digest methods. (Section: 6.2)
A user agent MAY support additional XML canonicalization methods.
(Section: 6.3)

Section: 7.1
The Algorithm attribute of the ds:digestMethod MUST be one of the
digest algorithms.
The Algorithm attribute of the ds:CanonicalizationMethod element MUST
be one of the canonicalization algorithms.
The ds:SignatureMethod algorithm used in the ds:SignatureValue  
element

MUST be one of the signature algorithms.

Comment - If in section 6 we say A user agent MAY support additional
XXX algorithms, which seems to be in conflict with section 7 that
states the algorithm used must be one of algorithms listed in  
section 6.

This seems to be an open ended requirement.

Suggestion - Remove the statements in section 7.1. It is down to the
signer to choose the algorithm to use. If they choose to use a
non-recommended algorithm they should understand that user agent  
support

cannot be guaranteed.

---
Question / non-editorial
---

---[Support for certificate chains]---

Typically more than one X509 certificate will need to be included in  
the
signature in order to construct a certificate chain to an installed  
root
certificate. Ideally the widget user agent would be given an  
indication

of how to re-construct the certificate chain. This could be done my
recommending that X509Certificate elements be included in certificate
chain order or by including an attribute to the element, e.g.

X509Data
 X509Certificate order=1.../X509Certificate
 X509Certificate order=2.../X509Certificate
 X509Certificate order=3.../X509Certificate /X509Data

Maybe this is already solved with other uses of XML Digital  
Signatures?



[1] http://dev.w3.org/2006/waf/widgets-digsig/
[2] http://www.w3.org/TR/widgets/#definitions













-Original Message-
From: public-webapps-requ...@w3.org
[mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow
Sent: 21 May 2009 18:23
To: public-webapps; public-xml...@w3.org
Subject: Reminder: Comments for LCWD of Widgets 1.0: Digital  
Signatures

due June 1

Hi All - a friendly reminder June 1 is the end of the comment period  
for

the April 30 Widgets 1.0: Digital Signatures Last Call Working
Draft:

 http://www.w3.org/TR/2009/WD-widgets-digsig-20090430/

Please send all comments by June 1.

-Regards, Art Barstow


On May 1, 2009, at 10:48 AM, Barstow Art (Nokia-CIC/Boston) wrote:

On April 30 the WebApps WG published a LCWD of the Widgets 1.0  
Digital



Signatures spec:

[[
http://www.w3.org/TR/2009/WD-widgets-digsig-20090430/

Introduction

This document defines a profile of the XML Signature Syntax and
Processing 1.1 specification to allow

Re: Widgets 1.0: Digital Signatures

2009-06-04 Thread Frederick Hirsch
Thanks for the review Josh. These all look editorial to me and I  
assume we can handle them during CR.


regards, Frederick

Frederick Hirsch
Nokia



On Jun 4, 2009, at 9:30 AM, ext timeless wrote:


Hi, apologies for the late comments.

I hope all of my comments are of an editorial nature. The only one
that might not be is the last one which is a question.

http://dev.w3.org/2006/waf/widgets-digsig/

-

I'm aware this is non normative:

1.4 Example


 CanonicalizationMethod
  Algorithm=http://www.w3.org/2006/12/xml-c14n11/
 SignatureMethod
  Algorithm=http://www.w3.org/2001/04/xmldsig-more#rsa-sha256; /

but..do we want to be consistent about trailing spaces before / ?
-

there are tabs here, which is inconsistent with the rest of the  
example:

KeyInfo
X509Data
 X509Certificate.../X509Certificate
/X509Data
/KeyInfo

-
4 Locating and Processing Digital Signatures for the Widget

3.

If the signatures list is not empty, sort the list of signatures by
the file name field in ascending numerical order (e.g. signature1.xml
followed by signature2.xml followed by signature3.xml etc).

In Safari 4 beta, the paragraph has a blank paragraph between it and
the 3. number, this differs from 6.

-
If the signatures list is not empty, sort the list of signatures by
the file name field in ascending numerical order (e.g. signature1.xml
followed by signature2.xml followed by signature3.xml etc).

change xml etc to xml, etc.

-
7.1 Common Constraints for Signature Generation and Validation

4. Every Signature Property required by this specification MUST be
incorporated into the signature as follows:

b. A widget signature MUST include a ds:Object element within the
ds:Signature element. This ds:Object element MUST have an Id attribute
that is referenced by a ds:Reference element within the signature
ds:SignedInfo element.

Why is Id written in mixed case?

-





Re: [widgets] dig sig and requirements ready for pub!

2009-05-07 Thread Frederick Hirsch
I assume this issue is closed with no need to add this text, given the  
subsequent thread. If this is incorrect please note that on the list.


Thanks

regards, Frederick

Frederick Hirsch
Nokia



On May 5, 2009, at 6:33 AM, Barstow Art (Nokia-CIC/Boston) wrote:

On May 4, 2009, at 10:13 AM, Hirsch Frederick (Nokia-CIC/Boston)  
wrote:


We can add, A signer MUST place the dsp:Identifier signature  
property

into the signature when generating the signature. if necessary.


This seems like a reasonable way to address Kai's question.

Kai - please let us know if Frederick's proposal is acceptable.

-Regards, Art Barstow



On May 1, 2009, at 6:49 AM, ext Kai Hendry wrote:


http://dev.w3.org/2006/waf/widgets-digsig/#identifier-signature-
property

I'm not sure what signature management is exactly, though can
someone please inform me what a UA is supposed to do with
dsp:Identifier?


I'm also keen on seeing a simple self sign sign/verify example  
using

http://www.aleksey.com/xmlsec/ or some other opensource tool.


Kind regards,







Re: [widgets] Dig Sig review in prep for LC

2009-04-29 Thread Frederick Hirsch

+1

I don't see the need for that paragraph.

regards, Frederick

Frederick Hirsch
Nokia



On Apr 29, 2009, at 6:36 AM, ext Thomas Roessler wrote:


Hi Frederick,
Some tiny editorial changes

I think we should add the following sub-section to the Status of
This Document:

[[
h3 class=no-num no-tocNote to Last Call Reviewers/h3
pemThis section is non-normative./em/p
pThe editors of this specification respond rapidly to all feedback
and continuously make corrections to this document. Unless you are
reading this document on the date of publication, strong
class=redNoteit is extremely  likely that this document has been
superseded/strong. Instead of reviewing this published draft,  
please
review the a href=http://dev.w3.org/2006/waf/widgets- 
digsig/latest
editor's draft/a and make sure to cite the date of that draft in  
the

feedback sent to the Web Apps Working Group's public mailing list a
href=
mailto:public-webapps@w3.org;public-Webapps@w3.org/a. /p
pPlease also be sure to check the mailing list a href=
http://lists.w3.org/Archives/Public/public-webapps/;archive/a to
see if any issues uncovered have already been addressed. To help with
cataloging issues, prefix emails to the mailing list with the string
samp[widgets]/samp. Any and all feedback is welcomed./p
]]


Well... Doesn't Last Call suggest that you're actually beyond the
phase of rapid changes?







Re: [widgets] Dig Sig review in prep for LC

2009-04-29 Thread Frederick Hirsch

comments inline, including proposals. thanks for the review

regards, Frederick

Frederick Hirsch
Nokia



On Apr 29, 2009, at 4:01 AM, ext Marcos Caceres wrote:


Hi Frederick,
Some tiny editorial changes

I think we should add the following sub-section to the Status of  
This Document:


[[
h3 class=no-num no-tocNote to Last Call Reviewers/h3
pemThis section is non-normative./em/p
pThe editors of this specification respond rapidly to all feedback
and continuously make corrections to this document. Unless you are
reading this document on the date of publication, strong
class=redNoteit is extremely  likely that this document has been
superseded/strong. Instead of reviewing this published draft, please
review the a href=http://dev.w3.org/2006/waf/widgets-digsig/;latest
editor's draft/a and make sure to cite the date of that draft in the
feedback sent to the Web Apps Working Group's public mailing list a
href=
mailto:public-webapps@w3.org;public-Webapps@w3.org/a. /p
pPlease also be sure to check the mailing list a href=
http://lists.w3.org/Archives/Public/public-webapps/;archive/a to
see if any issues uncovered have already been addressed. To help with
cataloging issues, prefix emails to the mailing list with the string
samp[widgets]/samp. Any and all feedback is welcomed./p
]]

I think we should use standard last call boilerplate. If it isn't  
ready for last call then maybe we should wait.




Section 1.1
Namespace prefix wsig:  wsig



I think wsig: is clearer to the reader so would not like to do this one.


Section 1.3
to the term definition  to where the term is defined.


ok


2.0
are addressed in the Widgets 1.0 Requirements [Widgets  
Requirements] document.

-
are addressed in the Widgets 1.0 Requirements document [Widgets  
Requirements].



ok


3.0
security critical mechanism
Can we include a concrete example of such a thing? I'm not sure what a
security critical mechanism is.



I suggest we remove Trust in a certificate is established through a  
security critical mechanism implemented by the user agent, which is  
out of scope for this specification.


Mark, do you have a better suggestion?


4.0
Step 6
Numerical order is - dfnNumerical order/dfn is

The numerical order is really relevant to processing. I think we
should move this paragraph and proceeding paragraph to the top of
section 4.0. Their importance is kind of lost where they are right
now.

there are only 7 steps, less than a page. I doubt it will get lost. I  
suggest leaving this alone. ok with dfn.



5.1
profile of XML Signature [XMLDSIG11] defined by this specification.
-
profile of  [XMLDSIG11] defined by this specification.




I think  the english XML Signature which I though makes it more  
readable. I guess we have different styles in mind, I prefer english +  
Reference, alternative is reference only. I can make this change for  
consistency.




contain a dsp:Profile signature properties element compliant with XML
Signature Properties [XMLDSIG-Properties] and this specification.
-
contain a dsp:Profile element compliant with the [XMLDSIG-Properties]
specification and this specification.


ok, highlighting term




5.5
The dsp:Identifier signature property is intended to be used to
uniquely identify the signature to enable signature management. 

Who is the subject in this sentence? I.e., used by who? publishers?
the UA? users? I think that needs to be made clear.



how about

The signer uses the dsp:Identifier signature property to
uniquely identify the signature to enable signature management.

(you don't like passive voice? :)




value is unique for the widgets that they sign.



value is unique for the widget packages that they sign.





ok


6.1
Signatures generated using key lengths of less than 2048 bits SHOULD
NOT be used unless the life time of the signature is less than one
year.

Again, it is not clear to me who SHOULD NOT be used is directed at?
should not be used by the UA?



The signer  SHOULD NOT generate signatures using key lengths of less  
than 2048 bits unless the life time of the signature is less than one  
year.


By the way, shouldn't this be a MUST NOT?



Kind regards,
Marcos


thanks



--
Marcos Caceres
http://datadriven.com.au






Updates to Widget Signature

2009-04-28 Thread Frederick Hirsch

I have updated Widgets Signature as follows:

1. Added MUSTs to require consistency of  file name and corresponding  
dsp:Role [1].


A file matching the author-sig-filename [ABNF] rule MUST contain a  
dsp:Role signature property having the URI for an Author role as  
defined in this specification or the signature MUST be flagged as  
being in error.


A file matching the dist-sig-filename [ABNF] rule MUST contain a  
dsp:Role signature property having the URI for a Distributor role as  
defined in this specification or the signature MUST be flagged as  
being in error.


2. Added general warning about optional algorithms to algorithms  
section [2]


Note that use of optional algorithms may result in signatures that are  
not interoperable with implementations that do not support these  
algorithms. Authors are cautioned to take this into consideration.


3. Added specific note for ECDSAwithSHA256

Although all implementations may not support this optional algorithm,  
implementation is encouraged since it may become mandatory in a  
subsequent release of this specification. This may also be necessary  
if any security issues are discovered with the currently required  
algorithm.


4. Removed paragraph on access control since we are moving it to  
Packaging and Config.


Removed from end of section Use of XML Signature in Widgets [3]   
Proposed  change to P  C still needs to be made [4].


5. Updated reference for Signature Properties  and Widget Requirements  
to anticipate publication as Working Draft  on 30 April [5]


6. Updated reference to P  C to refer to editors draft of today 28  
April - this date may require further update [5]


We are planning to publish this document this week, and draft needs to  
be complete tomorrow. So please let me know of any issues with these  
changes or any other corrections by tomorrow morning Eastern time.


Thank you

regards, Frederick

Frederick Hirsch
Nokia

[1] 
http://dev.w3.org/2006/waf/widgets-digsig/#naming-convention-for-an-author-signature

and

http://dev.w3.org/2006/waf/widgets-digsig/#naming-convention-for-a-distributor-sign

[2] http://dev.w3.org/2006/waf/widgets-digsig/#algorithms

[3] http://dev.w3.org/2006/waf/widgets-digsig/#use

[4] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0359.html

[5] http://dev.w3.org/2006/waf/widgets-digsig/#references





Re: [widgets] New WD of Widgets 1.0: Digital Signatures spec published on March 31

2009-04-23 Thread Frederick Hirsch

I've added this to the Widgets Signature specification.

regards, Frederick

Frederick Hirsch
Nokia



On Apr 23, 2009, at 3:18 AM, ext Priestley, Mark, VF-Group wrote:


Thanks Frederick!


-Original Message-
From: Frederick Hirsch [mailto:frederick.hir...@nokia.com]
Sent: 22 April 2009 23:20
To: Priestley, Mark, VF-Group
Cc: Frederick Hirsch; marc...@opera.com; Barstow Art (Nokia-CIC/ 
Boston);

public-webapps
Subject: Re: [widgets] New WD of Widgets 1.0: Digital Signatures spec
published on March 31

I think the following items are fine and will add them to the spec:

Signing parties are expected to ensure that the dsp:Identifier  
signature

property value is unique for the widgets that they sign 5.5 and 7.2

I don't think there is anything else, though we need to check the  
blogs

and also to see if any new mistakes have been introduced.

regards, Frederick

Frederick Hirsch
Nokia



On Apr 22, 2009, at 5:53 PM, ext Priestley, Mark, VF-Group wrote:


Thanks Frederick and Marcos - responses inline.

Only a couple of questions left :)

Regards,

Mark

-Original Message-
From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On
Behalf Of Marcos Caceres
Sent: 22 April 2009 11:46
To: Frederick Hirsch; Priestley, Mark, VF-Group
Cc: Barstow Art (Nokia-CIC/Boston); public-webapps
Subject: Re: [widgets] New WD of Widgets 1.0: Digital Signatures spec
published on March 31

On Tue, Apr 21, 2009 at 11:14 PM, Frederick Hirsch
frederick.hir...@nokia.com

wrote:
Mark

Please find responses  inline. Thanks for the review.

regards, Frederick

Frederick Hirsch
Nokia



On Apr 7, 2009, at 2:27 AM, ext Priestley, Mark, VF-Group wrote:



Hi Art, All,

Please find below my editorial comments and requests for
clarifications based on the new WD [1]. While it is a long list the
comments are all minor and so hopefully easily addressed. Overall I
think the spec is looking good, for which a lot of thanks must go  
to



Frederick and Marcos!

That said, I have a couple of more substantive comments that I will
send in the next couple of days.

Many thanks,

Mark


[1] http://www.w3.org/TR/2009/WD-widgets-digsig-20090331/

-
COMMENTS
-

1.0

A widget package can be signed by the author of the widget
producing an [XMLDSIG11] signature that cryptographically includes
all of the file entries other than signature files. A widget  
package



can also be signed by one or more distributors, with XML signatures
that each cryptographically includes all of the non-signature file
entries as well as any author signature.

Change the last sentence for consistency between definitions, ie:

... A widget package can also be signed by one or more  
distributors



change of the widget, producing [XMLDSIG11] /change signatures
that each cryptographically includes all of the non-signature file
entries as well as any author signature.


ok


[mp] Thanks






-
Can we remove the following sentence? This is a general property of
signatures which I'm not sure we need to include.

Digitally signing implies use of private key material only known  
by



the signer, thus enabling verification of integrity and signature
source.


ok


[mp] Thanks




-
1.1

We don't actually define any XML elements in the
http://www.w3.org/ns/widgets-digsig; namespace... is this worth
noting this and/or removing the wsig prefix?



We define URIs using this namespace so we should keep the URI
definition.
ok with removing prefix since it is not used now but would prefer to
keep to avoid errors later. Not a big issue to remove though.


[mp] I'm OK either way.




-
The terms XML elements and resources seem to be used
interchangeably? Is there a difference?


yes, one is xml elements others are resources as referenced by URI


Mark, I'm worried you asked this question? Is there confusion
somewhere wrt to the use resource and xml elements?

[mp] No, it's mostly a case of me needing to read the text more
carefully! My confusion was caused by the fact we only define the
namespace prefixes that we use in throughout the spec in the context
of resources.




-
Algorithms used by XML Security are defined in a number of
places... - could we tighten up this sentence, eg something like
This specification references algorithms defined in [XMLSecAlgs]
and [XMLDSIG11] ?



No, XMLSecAlgs does not define the algs. There are defined in a
number of places :)


OK - my concern was just that [XMLSecAlgs] cross references lots of
algorithms that we don't need but happy to leave as it is.




-
1.2

compressed (or Stored) - either remove capitalisation of Stored  
or



add it to compressed




I suggest stored. Marcos?


Stored should probably be [Stored], with a reference to the RFC for
the algorithm.

[mp] OK for me


-
physical file - file ?



Marcos? ok with file personally


Agree.

[mp] Thanks


-
top-most path level - is there a better way of saying this?



don't think so unless you have a proposal without using

Re: [widget-digsig] Pls review: Additional considerations on elliptic curve algorithms to consider

2009-04-23 Thread Frederick Hirsch
I agree .  Also to be clear Mark, I believe you are saying VF supports  
a MUST in the XML Signature 1.1 specification.


regards, Frederick

Frederick Hirsch
Nokia



On Apr 23, 2009, at 8:15 AM, ext David Rogers wrote:


Marcos,

Surely the logic should support algorithm evolution in that way. If  
it is a SHOULD it doesn't mean that engines need to support all  
algorithms - that would be a SHALL? If we say nothing at all, you  
run the risk of dropping off a security cliff if you need to migrate  
in the future. A SHOULD at least prescribes an intended roadmap and  
gives the option for implementers to go for that if they so choose.


Thanks,

David.

-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org 
] On Behalf Of Marcos Caceres

Sent: 23 April 2009 08:53
To: Priestley, Mark, VF-Group
Cc: Frederick Hirsch; Web Applications Working Group WG; Babbage,  
Steve, VF-Group
Subject: Re: [widget-digsig] Pls review: Additional considerations  
on elliptic curve algorithms to consider


On Thu, Apr 23, 2009 at 9:31 AM, Priestley, Mark, VF-Group
mark.priest...@vodafone.com wrote:

Hi Frederick, All,

Vodafone supports the move to support ECDSA in XML Signature 1.1  
[2] and

welcomes the new clarifying text. Vodafone will not object to
ECDSAwithSHA256 being specified as mandatory [2] however we would  
like

to propose that it is a recommended algorithm in Widgets 1.0: Digital
Signatures [5] (e.g. a SHOULD).


Sorry, it doesn't make sense to have them as a should in this
context. Either they are in or out because in practice engines will
need to support all prescribed algorithms. Lets keep to the smallest
possible subset of most commonly used algorithms in 1.0; every
algorithm we add makes this specification more difficult/expensive to
implement, adds more points of failure, etc. If the market shifts to
new algorithms, then we can add those later in a new draft.

Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au






[widget-digsig] Updated Widget Signature editors draft

2009-04-23 Thread Frederick Hirsch
I have updated the Widget Signature draft to reflect decisions on  
today's call, as follows:


Added ECDSAwithSHA256 as SHOULD  signature algorithm
Removed editor  notes re feedback on signature algorithms
Removed editor note with Signature Properties reference, since we've  
removed section 9

Added FIPS-186-3 reference

http://dev.w3.org/2006/waf/widgets-digsig/

Note that we will need to update the Signature Properties reference,  
when that specification is published with this specification.


regards, Frederick

Frederick Hirsch
Nokia






Re: [widgets] Agenda for 23 April 2009 Voice Conference

2009-04-22 Thread Frederick Hirsch

d. What needs to be done before this spec is feature-complete and
ready for Last Call WD publication?


address editorial comments from Mark, as posted on list
http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0256.html
can edit this today.

Agree to coordination published update of Signature Properties, thus  
remove section 9 from widget signature

http://dev.w3.org/2006/waf/widgets-digsig/#sigproperties

any other comments received that we might have missed?

regards, Frederick

Frederick Hirsch
Nokia



On Apr 22, 2009, at 7:36 AM, Barstow Art (Nokia-CIC/Boston) wrote:


Below is the draft agenda for the April 23 Widgets Voice Conference
(VC).

Inputs and discussion before the meeting on all of the agenda topics
via public-webapps is encouraged (as it can result in a shortened
meeting).

Logistics:

   Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London;
09:00 Boston; 06:00 Seattle
   Duration = 90 minutes
   Zakim Bridge +1.617.761.6200, conference 9231 (WAF1)
   IRC channel = #wam; irc.w3.org:6665
   Confidentiality of minutes = Public

Agenda:

1. Review and tweak agenda

2. Announcements

3. Widgets DigSig spec

 http://dev.w3.org/2006/waf/widgets-digsig/

a. Created property; proposal to modify by Mark; proposal to delete
it by Frederick

 MP: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/
0186.html
 FH: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/
0244.html

b. DigSig comments by Mark;

 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/
0070.html

c. Issue #83 proposal; by Frederick and Marcos:

 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/
0240.html

d. What needs to be done before this spec is feature-complete and
ready for Last Call WD publication?

4. PC spec

 http://dev.w3.org/2006/waf/widgets/

a. Simple approach for access; see Robin's proposal and followups

 http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/
0943.html

b. I18N proposal from Marcos; please review and submit comments
before the meeting:

 http://dev.w3.org/cvsweb/2006/waf/widgets/i18n.html

c. Dropping screenshot; proposal by Marcos:

 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/
0197.html

5. Window Modes spec: status and plans

6. AOB








Re: [widgets] Agenda for 23 April 2009 Voice Conference

2009-04-22 Thread Frederick Hirsch

I agree that the sentence should be dropped.

I'll take an editorial pass today to remove that sentence, address the  
agreed changes on Mark's editorial comments and to remove the Created  
material.


Thanks for noting this one.

regards, Frederick

Frederick Hirsch
Nokia



On Apr 22, 2009, at 11:26 AM, ext Marcos Caceres wrote:


Hi,

On Wed, Apr 22, 2009 at 3:31 PM, Frederick Hirsch
frederick.hir...@nokia.com wrote:

d. What needs to be done before this spec is feature-complete and
ready for Last Call WD publication?


address editorial comments from Mark, as posted on list
http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0256.html
can edit this today.

Agree to coordination published update of Signature Properties,  
thus remove

section 9 from widget signature
http://dev.w3.org/2006/waf/widgets-digsig/#sigproperties

any other comments received that we might have missed?


I'm not sure if we addressed the issue that was raised on a two blogs
about the assertion that Widget authors and distributors can
digitally sign widgets as a trust and quality assurance mechanism.

It was suggested that we should drop that sentence, I think.



--
Marcos Caceres
http://datadriven.com.au





Re: [widgets] New WD of Widgets 1.0: Digital Signatures spec published on March 31

2009-04-22 Thread Frederick Hirsch

Two proposals based on Marcos comments


-
which MAY logically contain - if the configuration file is made
mandatory then the MAY should be a MUST



I think it is a MAY,  others?


Technically, Mark is correct. But leave it as a MAY (or maybe drop MAY
altogether) because this spec does not put conformance criteria on
packaging.



Dropped MAY for reason Marcos mentioned, also since not really  
appropriate to definition.




Question: is a file entry the same as a file? If so then we should
always use file entry in place of file. If not then perhaps we
should define file?



I don't think they are the same. This is a PC question. Marcos?


Depends. A file entry is the representation of file data in a zip
archive. A file is a physical uncompressed file as would appear on
disk. If we assume that signatures will act on physical files, it will
be correct to talk about files.


I don't think we can always expect creation of a physical file for  
processing. Suggest not making any  change here.


regards, Frederick

Frederick Hirsch
Nokia



On Apr 22, 2009, at 6:45 AM, ext Marcos Caceres wrote:


On Tue, Apr 21, 2009 at 11:14 PM, Frederick Hirsch
frederick.hir...@nokia.com wrote:

Mark

Please find responses  inline. Thanks for the review.

regards, Frederick

Frederick Hirsch
Nokia



On Apr 7, 2009, at 2:27 AM, ext Priestley, Mark, VF-Group wrote:



Hi Art, All,

Please find below my editorial comments and requests for  
clarifications
based on the new WD [1]. While it is a long list the comments are  
all

minor and so hopefully easily addressed. Overall I think the spec is
looking good, for which a lot of thanks must go to Frederick and  
Marcos!


That said, I have a couple of more substantive comments that I  
will send

in the next couple of days.

Many thanks,

Mark


[1] http://www.w3.org/TR/2009/WD-widgets-digsig-20090331/

-
COMMENTS
-

1.0

A widget package can be signed by the author of the widget  
producing an
[XMLDSIG11] signature that cryptographically includes all of the  
file
entries other than signature files. A widget package can also be  
signed

by one or more distributors, with XML signatures that each
cryptographically includes all of the non-signature file entries  
as well

as any author signature.

Change the last sentence for consistency between definitions, ie:

... A widget package can also be signed by one or more distributors
change of the widget, producing [XMLDSIG11] /change signatures  
that
each cryptographically includes all of the non-signature file  
entries as

well as any author signature.


ok




-
Can we remove the following sentence? This is a general property of
signatures which I'm not sure we need to include.

Digitally signing implies use of private key material only known  
by the
signer, thus enabling verification of integrity and signature  
source.


ok


-
1.1

We don't actually define any XML elements in the
http://www.w3.org/ns/widgets-digsig; namespace... is this worth  
noting

this and/or removing the wsig prefix?



We define URIs using this namespace so we should keep the URI  
definition.
ok with removing prefix since it is not used now but would prefer  
to keep to

avoid errors later. Not a big issue to remove though.


-
The terms XML elements and resources seem to be used
interchangeably? Is there a difference?


yes, one is xml elements others are resources as referenced by URI


Mark, I'm worried you asked this question? Is there confusion
somewhere wrt to the use resource and xml elements?




-
Algorithms used by XML Security are defined in a number of  
places... -
could we tighten up this sentence, eg something like This  
specification

references algorithms defined in [XMLSecAlgs] and [XMLDSIG11] ?



No, XMLSecAlgs does not define the algs. There are defined in a  
number of

places :)


-
1.2

compressed (or Stored) - either remove capitalisation of Stored  
or add

it to compressed




I suggest stored. Marcos?


Stored should probably be [Stored], with a reference to the RFC for
the algorithm.


-
physical file - file ?



Marcos? ok with file personally


Agree.


-
top-most path level - is there a better way of saying this?



don't think so unless you have a proposal without using the word  
root


I know it's nasty, but people understand it. Lets play wordsmith only
once we have all the tech stuff solved.


-
which MAY logically contain - if the configuration file is made
mandatory then the MAY should be a MUST



I think it is a MAY,  others?


Technically, Mark is correct. But leave it as a MAY (or maybe drop MAY
altogether) because this spec does not put conformance criteria on
packaging.




-
Question: is a file entry the same as a file? If so then we should
always use file entry in place of file. If not then perhaps we
should define file?



I don't think they are the same. This is a PC question. Marcos?


Depends. A file entry is the representation of file data in a zip

[widget-digsig] updated Widget Signature editors draft

2009-04-22 Thread Frederick Hirsch

I have updated the widget signature editors draft

http://dev.w3.org/2006/waf/widgets-digsig/

1. Removed section 9, Draft update to XML Signature Properties since  
XML Security WG  plans to publish latest revision of Signature  
Properties in conjunction with next Widget Signature publication.


2. Removed all mention of Created property, removed from example 1.4,  
mention in 1.5, remove section 5.6, mention in 7.2 and 7.3


3. removed sentence from abstract and introduction that received  
negative comment:
Widget authors and distributors can digitally sign widgets as a trust  
and quality assurance mechanism


4. Implemented Editorial requests from Mark that we all agreed,  
including refinements from timeless, and Marcos.


Note that I used signature file where talking about files  
specifically, and widget signature when talking about features of  
the XML signature itself, since otherwise it makes no sense.


Dropped MAY from definition, which MAY logically contain , as  
suggested by Marcos.

add ZIP reference to Stored usage.

5 Updated acknowledgements to thank XML Security WG and other reviewers.

6. Added proposed text  to 5.1 to resolve ISSUE-83

A user agent MUST prevent a widget from accessing the contents of
a digital signature document unless an access control mechanism
explicitly enables such access e.g. via a an access control policy.
The definition of such a policy mechanism is out of scope of
this specification, but may be defined to allow access to all or
parts of the signature documents, or deny any such access.

7. Fixed an internal link issue related to choice of verification  
versus validation of signatures.


We still have some issues to resolve with links into the requirements  
document, and thus possibly the requirements section in general.


regards, Frederick

Frederick Hirsch
Nokia






Re: [widgets] New WD of Widgets 1.0: Digital Signatures spec published on March 31

2009-04-22 Thread Frederick Hirsch

I think the following items are fine and will add them to the spec:

Signing parties are expected to ensure that the dsp:Identifier  
signature property value is unique for the widgets that they sign 5.5  
and 7.2


I don't think there is anything else, though we need to check the  
blogs and also to see if any new mistakes have been introduced.


regards, Frederick

Frederick Hirsch
Nokia



On Apr 22, 2009, at 5:53 PM, ext Priestley, Mark, VF-Group wrote:


Thanks Frederick and Marcos - responses inline.

Only a couple of questions left :)

Regards,

Mark

-Original Message-
From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On  
Behalf Of Marcos Caceres

Sent: 22 April 2009 11:46
To: Frederick Hirsch; Priestley, Mark, VF-Group
Cc: Barstow Art (Nokia-CIC/Boston); public-webapps
Subject: Re: [widgets] New WD of Widgets 1.0: Digital Signatures  
spec published on March 31


On Tue, Apr 21, 2009 at 11:14 PM, Frederick Hirsch frederick.hir...@nokia.com 
 wrote:

Mark

Please find responses  inline. Thanks for the review.

regards, Frederick

Frederick Hirsch
Nokia



On Apr 7, 2009, at 2:27 AM, ext Priestley, Mark, VF-Group wrote:



Hi Art, All,

Please find below my editorial comments and requests for
clarifications based on the new WD [1]. While it is a long list the
comments are all minor and so hopefully easily addressed. Overall I
think the spec is looking good, for which a lot of thanks must go  
to Frederick and Marcos!


That said, I have a couple of more substantive comments that I will
send in the next couple of days.

Many thanks,

Mark


[1] http://www.w3.org/TR/2009/WD-widgets-digsig-20090331/

-
COMMENTS
-

1.0

A widget package can be signed by the author of the widget  
producing

an [XMLDSIG11] signature that cryptographically includes all of the
file entries other than signature files. A widget package can also  
be

signed by one or more distributors, with XML signatures that each
cryptographically includes all of the non-signature file entries as
well as any author signature.

Change the last sentence for consistency between definitions, ie:

... A widget package can also be signed by one or more distributors
change of the widget, producing [XMLDSIG11] /change signatures
that each cryptographically includes all of the non-signature file
entries as well as any author signature.


ok


[mp] Thanks






-
Can we remove the following sentence? This is a general property of
signatures which I'm not sure we need to include.

Digitally signing implies use of private key material only known by
the signer, thus enabling verification of integrity and signature  
source.


ok


[mp] Thanks




-
1.1

We don't actually define any XML elements in the
http://www.w3.org/ns/widgets-digsig; namespace... is this worth
noting this and/or removing the wsig prefix?



We define URIs using this namespace so we should keep the URI  
definition.

ok with removing prefix since it is not used now but would prefer to
keep to avoid errors later. Not a big issue to remove though.


[mp] I'm OK either way.




-
The terms XML elements and resources seem to be used
interchangeably? Is there a difference?


yes, one is xml elements others are resources as referenced by URI


Mark, I'm worried you asked this question? Is there confusion  
somewhere wrt to the use resource and xml elements?


[mp] No, it's mostly a case of me needing to read the text more  
carefully! My confusion was caused by the fact we only define the  
namespace prefixes that we use in throughout the spec in the context  
of resources.





-
Algorithms used by XML Security are defined in a number of
places... - could we tighten up this sentence, eg something like
This specification references algorithms defined in [XMLSecAlgs]  
and [XMLDSIG11] ?




No, XMLSecAlgs does not define the algs. There are defined in a  
number

of places :)


OK - my concern was just that [XMLSecAlgs] cross references lots of  
algorithms that we don't need but happy to leave as it is.





-
1.2

compressed (or Stored) - either remove capitalisation of Stored or
add it to compressed




I suggest stored. Marcos?


Stored should probably be [Stored], with a reference to the RFC for  
the algorithm.


[mp] OK for me


-
physical file - file ?



Marcos? ok with file personally


Agree.

[mp] Thanks


-
top-most path level - is there a better way of saying this?



don't think so unless you have a proposal without using the word  
root


I know it's nasty, but people understand it. Lets play wordsmith  
only once we have all the tech stuff solved.


[mp] As I can't think of anything better, happy to leave as is.


-
which MAY logically contain - if the configuration file is made
mandatory then the MAY should be a MUST



I think it is a MAY,  others?


Technically, Mark is correct. But leave it as a MAY (or maybe drop MAY
altogether) because this spec does not put conformance criteria on  
packaging.


[mp

Proposal for ISSUE-83

2009-04-21 Thread Frederick Hirsch

ISSUE-83 states:
Instantiated widget should not be able to read digital signature
http://www.w3.org/2008/webapps/track/issues/83

The following is a proposal of text to add to PC to address this  
issue, based on text from Marcos and adding the notion of allowing  
policy and access control mechanisms to be used:


Where a user agent that implements this specification interacts with  
implementations of other specifications, this user agent MUST deny  
other implementations access to digital signature documents unless an  
access control mechanism is in place to enable access according to  
policy. The definition of such a policy mechanism is out  of scope of  
this specification, but may be defined to  allow access to all or  
parts of the signature documents, or deny any such access. An  
exception is if a user agent that implements this specification also  
implements the OPTIONAL [Widgts-DigSig] specification, in which case  
the user agent MUST make signature documents available to the  
implementation of the [Widgets-DigSig] specification.


This message should complete ACTION-329 which should be closed.

regards, Frederick

Frederick Hirsch
Nokia






Re: [widget] [widget-digsig] Comment on WD of Widgets 1.0: Digital Signatures - use of Created property

2009-04-21 Thread Frederick Hirsch
if there is no need for the Created property in the Widgets Signature  
spec I suggest we remove it, though keep what we have in the Signature  
Properties specification.


regards, Frederick

Frederick Hirsch
Nokia



On Apr 15, 2009, at 5:45 AM, ext Priestley, Mark, VF-Group wrote:


Dear All,

I have a number of comments against the Created property.

As previously communicated on conference calls (although I can't  
find the relevant minutes) Vodafone objects to the mandatory use of  
the Created property. The main objection is that on mobile devices  
the user often does not set the correct time (or more usually the  
correct year) which means the device defaults to the time/year of  
manufacture. As a result many signatures will contain Created  
property values that, as far as the device is concerned, happen in  
the future. Without a requirement on a reliable and accurate  
timesource, which we are not proposing to introduce, the Created  
property cannot be relied on. This combined with the fact that the  
use of the Created property is down to the signer, or the signing  
scheme within which the signer is operating, mean we think its use  
should be optional.


This general comment translates to the specific comments below.

-
5.1

Each signature file MUST contain a dsp:Created signature properties  
element compliant with XML Signature Properties [XMLDSIG-Properties]  
and this specification.


We would like to see the above changed to a MAY.

-
5.6

As an example of use, assume a distributor's signing process is  
found to have been compromised. Thus, it is not practical to  
exchange the signature key. Being able to invalidate all signatures  
made before a particular date would be important in such a scenario.


I'm not sure the above is a good example? If the signing process has  
been compromised then I may want to invalidate signatures before  
this date, but wouldn't I also change my key at this time to stop  
creating new compromised signatures? In this case the end-entity  
cert should be revoked. My understanding of timestamps was that  
their main reason for being is to confirm that a signature was  
created at a particular instance in time. This information can then  
be used for non-repudiation and/or proof of existence of the signed  
object at a particular time in the past. The above use case seems to  
be suggesting something else which I do not fully understand.


As previously communicated I think there is a case for an Expires  
property, which could be used to state a point in time after which a  
Signature is no longer valid (to allow for Signature with shorter  
lives than the keys used to create them), but this is different from  
the Created property.


My suggestion is to rework the example.

-
7.2

The sentence:

A wall clock timestamp SHOULD be placed

is inconsistent with the text in 5.1 which states the element as a  
MUST.  If the text in 5.1 is changed to a MAY then the text in 7.2  
would be OK but we would prefer to make this a MAY as well.


-
7.3

The Created Signature Property value SHOULD represent a wall clock  
timestamp earlier than the current time, to the nearest minute. 


It's not clear what the user agent should do to respect this  
requirement? We think that this should be left to the signer or  
signing scheme to reflect use of the Created property through the  
UA's security policy. The text on the Created property could then be  
deleted from this section.


-
9.2.1

Upon signature generation, if this property is used, the time value  
is set to a reference time, as defined by the application. 


Again, this is inconsistent with the text in 5.1 in which the  
Created property is mandatory, unless the intention of the text is  
to be if the property is used by the UA?


-
9.2.2

We think it should be made clear that Validation of the Created  
property is optional.


Thanks,

Mark

Mark Priestley

Mobile: +44 (0)7717512838
E-mail: mark.priest...@vodafone.com

Vodafone Group Services Limited
Registered Office: Vodafone House, The Connection, Newbury,  
Berkshire RG14 2FN Registered in England No 3802001







Re: ISSUE-83 (digsig should not be read at runtime): Instantiated widget should not be able to read digital signature [Widgets]

2009-04-14 Thread Frederick Hirsch

+1

I do not understand the attack, but can envision cases where  
precluding access could cause problems. Examples might be user see  
what is signed or access to signature properties.


Is this an access control issue rather than a general specification  
rule?


regards, Frederick

Frederick Hirsch
Nokia



On Apr 13, 2009, at 7:03 AM, Barstow Art (Nokia-CIC/Boston) wrote:


On Apr 9, 2009, at 1:44 PM, ext Marcos Caceres wrote:




On 4/9/09 3:56 PM, Arthur Barstow wrote:

On Apr 9, 2009, at 9:52 AM, ext Marcos Caceres wrote:


On Thu, Apr 9, 2009 at 2:17 PM, Priestley, Mark, VF-Group
mark.priest...@vodafone.com wrote:

Hi Art, All,

If there is no use case for accessing this information (I was
after why
you would want to access this information because I think just
saying it
might be interesting to do so isn't justification enough), then
I think
my original proposal holds - make the signature files
unavailable to the
widget at runtime.

For clarification I was not suggesting that an API should be
added to
the DigSig spec but rather that some of the information could be
exposed
via an API defined in the APIs and Events spec. But I don't
think this
is necessary or worth the additional specification effort.



FWIW, I agree with Mark.


Please propose text that will address your concerns.


In the PC spec, I would add something like:

A user agent MUST make the digital signature available only to
implementations of the [Widgets-DigSig] specification.


I don't understand why we would want to create this type for a PC UA.



A user agent MUST
NOT allow read access to any digital signature in the widget
package at
runtime.


I think this conflates requirements for a PC UA with the
requirements for Widget [Runtime] UA. As such, I disagree with what
you are trying to prescribe here and think the specs should remain
silent on this (or perhaps defer this to a definition of a Widgets UA
runtime model).

I still cannot understand why you want to preclude a widget from
being able to access *all* of its resources. Perhaps it would be
helpful if you would elaborate on the risk(s) you are trying to
mitigate.

-Regards, Art Barstow



In other words, a user agent MUST NOT allow a start file, or
any other file or resource inside or outside the context of the  
widget

(e.g., a script or stylesheet), or API, or feature, to read any
digital
signature file within the widget package. At runtime, a user agent
MUST
make it seem as if digital signatures do not exist in the widget
package
by, for example, excluding them from any file listings, and not
allowing
them to be accessed via a URI.

That's just some quick draft text, please feel free to change, add,  
or

whatever.








[widget-digsig] Pls review: Additional considerations on elliptic curve algorithms to consider

2009-04-08 Thread Frederick Hirsch
The XML Security WG would like to refine the question about the   
suitability of elliptic curve as a mandatory to implement algorithm   
for XML Signature 1.1 by highlighting that the  scope of elliptic   
curve is greatly limited in what is proposed to be mandatory in XML   
Signature 1.1.


As T-Mobile pointed out previously in their comments [1], the specific  
curve being used in an instance of ECDSA is important and there are a  
few sets of well-known (named) curves that have been standardized.   
The P-256, P-384 and P-521 curves are three of the five NIST-defined  
prime curves.


Since the publication of the First Public Working Draft of XML   
Signature 1.1, the following clarifying text was added by the XML  
Security WG to  the end of section 6.4.3 of XML Signature 1.1 [2]:


This specification REQUIRES implementations to support the   
ECDSAwithSHA256 signature algorithm, which is ECDSA over the P-256   
prime curve specified in Section D.2.3 of FIPS 186-3 [FIPS186-3] (and   
using the SHA-256 hash algorithm). It is further RECOMMENDED that   
implementations also support ECDSA over the P-384 and P-521 prime   
curves; these curves are defined in Sections D.2.4 and D.2.5 of FIPS   
186-3, respectively.


It is important to realize  that by reducing the scope of the   
requirement to a specific curve that this should simplify evaluation
of whether it is desirable to make this  mandatory to implement.


The XML Security WG would also like to note the importance of this   
algorithm to US Government customers, as evidenced by their adoption   
of Suite B [3]. This is reflected in the XML Security WG Use Cases  
and  Requirements document in section 3.5.2.3 [4].


These considerations can also apply to the decision of which
algorithms should be required in Widget Signature.


Please share this additional information in your organization and   
indicate if it would cause any change in position regarding the   
mandatory to implement algorithms.


Thank you

regards, Frederick

Frederick Hirsch, Nokia
Chair XML Security WG


[1] http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0842.html

[2] 
http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-SignatureAlg

[3] Fact Sheet NSA Suite B Cryptography, 
http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml

[4] http://www.w3.org/TR/2009/WD-xmlsec-reqs-20090226/#algorithm-suiteb







Re: [BONDI Architecture Security] [widgets] new digsig draft, further comments

2009-03-27 Thread Frederick Hirsch

Marcin

[removed cross-posting, since my posting would fail anyway]

comments inline

regards, Frederick

Frederick Hirsch
Nokia



On Mar 27, 2009, at 5:27 AM, ext Marcin Hanclik wrote:


Hi Marcos,

These are my further comments to the DigSig spec:

1. There is no section about typographic conventions, as e.g.  
section 1.3 in PC spec. Therefore it is not possible to know e.g.  
which part of the spec is defining an example.




Having a notational conventions section is a good idea.

2. Section 4. My below comment 5. Section 4, item 3: is invalid,  
since ASCII sorting will not guarantee that signature2.xml will  
appear before signature11.xml when sorted. I am sorry for confusion.




so the spec is ok as written, noting numerical sorting of the numbers.  
No change here.



2.a. Section 4, item 6: Correspondingly to the above:
descending order
could become
descending numerical order
I would also define numerical order by taking an excerpt from  
another part of the spec:
Numerical order is the order based on the numeric portion of the  
signature file name.



good idea, agree


2.b. Section 4, item 6:
The ordering by file name can be used to allow consistent  
processing and possible optimization.
The term ordering by file name may be misinterpreted in the  
context of the numerical order, so I think that the whole statement  
could be removed.




How about

Ordering of widget signature files by the numeric portion of the file  
name can be used to allow consistent processing and possible  
optimization.


I think we should keep a sentence since Mark Priestly had earlier  
asked that we add it.



3. Section 4 + Section 5.3.1: Section 4 implies that sorting is an  
operation that takes place after the signature files are found  
within the widget package. So I would change the text in Section  
5.3.1. to distinguish between sorting (an operation) and file  
order in the widget package:
These signatures MUST be sorted numerically based on the numeric  
portion of the name.

could become
Within a widget package these signature files MUST be ordered based  
on the numeric portion of the signature file name.
The general question is whether the signature files MUST be ordered  
in the widget package, since the processing algorithm assumes that  
the signature files are sorted anyway after being extracted from the  
widget package.


My understanding is that the files may not appear in order in the  
package, but must processed in order, so the sorting may occur at  
processing time. I suggest we leave this text alone for that reason.  
This does not mean that an optimization is not possible if they are  
known to be in order in the widget package.


Marcin

can we agree to the change Thomas proposed, as a starting point?


The author signature asserts that the signing party is an author of
the widget, and binds the author's identity to the widget package.


or should we defer this one?

Thanks for the careful read.




Thanks.

Kind regards,
Marcin

Marcin Hanclik
ACCESS Systems Europe GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com

-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org 
] On Behalf Of Marcin Hanclik

Sent: Thursday, March 26, 2009 8:42 PM
To: marc...@opera.com; WebApps WG; otsi-arch-...@omtplists.org
Subject: RE: [BONDI Architecture  Security] [widgets] new digsig  
draft


Hi,

One correction to what I wrote:
Instead of
a) Replace root of the archive with root of the widget
I would now suggest
a) Replace root of the archive with root of the widget package

Thanks.

Kind regards,
Marcin

Marcin Hanclik
ACCESS Systems Europe GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com

-Original Message-
From: otsi-arch-sec-ow...@omtp.ieee-isto.org [mailto:otsi-arch-sec-ow...@omtp.ieee-isto.org 
] On Behalf Of Marcin Hanclik

Sent: Thursday, March 26, 2009 7:05 PM
To: marc...@opera.com; WebApps WG; otsi-arch-...@omtplists.org
Subject: RE: [BONDI Architecture  Security] [widgets] new digsig  
draft


Hi Marcos, All,

Please find below my - mostly editorial - comments to the latest  
digsig draft and one comment for PC.

Thanks.

Kind regards,
Marcin

1. Section 1: ... with XML signatures that each cryptographically  
include all of the non-signature ...


should become (missing s)

... with XML signatures that each cryptographically includes all of  
the non-signature ...


2. Unify case sensitive phrase. There are now both case- 
sensitive and case sensitive present in the text.


3. Section 1.2: Maybe the common terms could be unified between  
DigSig and PC? Both specs will probably be always used together.


A file entry is the compressed (or Stored) representation of a  
physical file or folder contained within a widget package, as  
defined in the [Widgets Packaging] specification.


The root

Re: [BONDI Architecture Security] [widgets] new digsig draft

2009-03-27 Thread Frederick Hirsch

Marcin


Thanks, for the careful review. some comment inline

[removed cross post, fails anyway]


regards, Frederick

Frederick Hirsch
Nokia



On Mar 26, 2009, at 2:04 PM, ext Marcin Hanclik wrote:


Hi Marcos, All,

Please find below my - mostly editorial - comments to the latest  
digsig draft and one comment for PC.

Thanks.

Kind regards,
Marcin

1. Section 1: ... with XML signatures that each cryptographically  
include all of the non-signature ...


should become (missing s)

... with XML signatures that each cryptographically includes all of  
the non-signature ...



this is already fixed in the latest draft

2. Unify case sensitive phrase. There are now both case- 
sensitive and case sensitive present in the text.



ok, lets go with case-sensitive since Websters has that.


3. Section 1.2: Maybe the common terms could be unified between  
DigSig and PC? Both specs will probably be always used together.


the goal was to be as clear as possible in widgets signature, and  
omitting detail not needed.





A file entry is the compressed (or Stored) representation of a  
physical file or folder contained within a widget package, as  
defined in the [Widgets Packaging] specification.


The root of the archive is the top-most path level of the widget  
package, which MAY logically contain one or more file entries, as  
defined in the [Widgets Packaging] specification.


A file name is the name of a file contained in a widget package  
(derived from the file name field of a local file header of a file  
entry), as defined in the [Widgets Packaging] specification. All  
file names MUST be treated as case-sensitive. In other words, case  
matters in file name comparisons. 


Proposed changes:

a) Replace root of the archive with root of the widget



root of the widget package, as you corrected in later email
ok

b) Clarify file name in PC (the definition in DigSig says about  
deriving from file name field and it seems strange to me).

why? it is the string file name?




c) Replace all the lines above with the following:
The file entry, root of the widget and file name terms are to be  
interpreted as defined in the [Widgets Packaging] specification.


I think I disagree, I think it is helpful to be able to read the  
widgets spec without constantly referring to P  C (even though they  
are closely related)





4. Section 1.2:
This specification uses [ABNF] syntax to define file names. Rules  
are concatenated by being written next to each other. A rule ended  
by * means zero or more. See [ABNF] for details on this syntax.

-
This specification uses [ABNF] syntax to define file names.

Additional clarifications may only confuse the reader, since [ABNF]  
is detailed enough and the actual semantics remains the same.




I see no harm in making it clear

5. Section 4, item 3: ascending numerical order - numerical order  
is implied by simple ASCII sorting, so I suggest ascending  
numerical order becomes simply ascending order. This would also  
match the descending order in item 6 where numerical is not  
present.


numerical order is not implied by ascii sorting, see 02 vs 12 as  
opposed to 2 and 12, they sort differently if you treat as strings  
or as numbers because of the leading 0.





6. Section 4, item 5: .. treat this as.. - what is this? I  
suggest to change the text to ... treat this widget package as ...


ok




7. Section 4, item 6: Validate the signature files in the  
signatures list - signatures looks weird, the cause is var vs.  
code in HTML.


agree.




8. Section 5.3.1: A file entry whose file name that does not match  
the - that should be removed


yes, thanks



9. Section 5.4: identify the X.509 version fully. The X.509  
certificate format MUST could become The X.509v1 certificate  
format MUST


No, it should be v3 but other versions are allowed, as noted. I think  
we should leave this alone.



9.a. The following references can be added:

9.a.i. X.509v1: http://www.itu.int/rec/T-REC-X.509-198811-S/en

9.a.ii. X.509v3: http://www.itu.int/rec/T-REC-X.509-199708-S/en


RFC 5280 covers enough doesn't it, PKIX.

10. Section 7.2: The time SHOULD reflect the time that signature  
generation completes. - The time SHOULD reflect the time when  
signature generation completed.




ok

11. Section 7.3: If present then user agents MUST perform Basic -  
If present, the user agents MUST perform Basic


ok




12. Section 9.2.1: The time SHOULD reflect the time that signature  
generation completes. - The time SHOULD reflect the time when  
signature generation completed.



ok


BTW: Comment to PC:
1. RFC 2119 terms are in lower-case in PC, whereas DigSig uses  
upper-case (that is more common).




should be upper case.



Marcin Hanclik
ACCESS Systems Europe GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com

-Original Message-
From: otsi-arch-sec-ow...@omtp.ieee-isto.org [mailto:otsi-arch-sec-ow

Re: [BONDI Architecture Security] [widgets] new digsig draft, further comments

2009-03-27 Thread Frederick Hirsch

Marcin

re author, would the term creator in the sentence from Thomas help,  
e.g.


The author signature asserts that the signing party is a creator of
the widget, and binds the creator's identity to the widget package.

this probably doesn't help, since by definition author means creator...

also, ok with your proposed change

Within a widget package these signature files MUST be ordered based on  
the numeric portion of the signature file name.


regards, Frederick

Frederick Hirsch
Nokia



On Mar 27, 2009, at 9:41 AM, ext Marcin Hanclik wrote:


Hi Frederick,

Thanks for your review of my comments.

Ordering of widget signature files by the numeric portion of the  
file

name can be used to allow consistent processing and possible
optimization.

I think we should keep a sentence since Mark Priestly had earlier
asked that we add it.

Agreed.


can we agree to the change Thomas proposed, as a starting point?


The author signature asserts that the signing party is an author of
the widget, and binds the author's identity to the widget package.

Yes, we can agree to it as a good starting point.
For me the disputable is only part of that sentence, i.e.:
... asserts that the signing party is an author of the widget,  
and 

since the term author is ambiguous currently.


My understanding is that the files may not appear in order in the
package, but must processed in order, so the sorting may occur at
processing time. I suggest we leave this text alone for that reason.
This does not mean that an optimization is not possible if they are
known to be in order in the widget package.
I agree with your understanding. This is what I tried to clarify in  
the text of the spec.
As for me Section 4 defines the processing algorithm, whereas  
Section 5.3.1 defines a kind of static conformance.

The sentence:
These signatures MUST be sorted numerically based on the numeric  
portion of the name.

has a few problems as for me. They are as follows:

a) we seem to actually mean the signature files and not signatures  
(signature are contained in signature files). Thus I suggest  
changing signatures to signature files. For even more clarity I  
suggest prepending the sentence with Within a widget package,  
since the section 5.3.1 specifies syntax for a single distributor's  
signature and the plural form comes just suddenly.


b) there is a new term sorted numerically. I suggest using  
Numerical order instead as you also agreed to it.


c) name may be unclear, so I suggest to change it to file name.

The above points a) - c) result in the following text:
Within a widget package these signature files MUST be ordered based  
on the numeric portion of the signature file name.





ok


I hope we will come to a conclusion soon.
Thanks.

Kind regards,
Marcin

Marcin Hanclik
ACCESS Systems Europe GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com

-Original Message-
From: Frederick Hirsch [mailto:frederick.hir...@nokia.com]
Sent: Friday, March 27, 2009 2:09 PM
To: Marcin Hanclik
Cc: Frederick Hirsch; marc...@opera.com Caceres; WebApps WG
Subject: Re: [BONDI Architecture  Security] [widgets] new digsig  
draft, further comments


Marcin

[removed cross-posting, since my posting would fail anyway]

comments inline

regards, Frederick

Frederick Hirsch
Nokia



On Mar 27, 2009, at 5:27 AM, ext Marcin Hanclik wrote:


Hi Marcos,

These are my further comments to the DigSig spec:

1. There is no section about typographic conventions, as e.g.
section 1.3 in PC spec. Therefore it is not possible to know e.g.
which part of the spec is defining an example.



Having a notational conventions section is a good idea.


2. Section 4. My below comment 5. Section 4, item 3: is invalid,
since ASCII sorting will not guarantee that signature2.xml will
appear before signature11.xml when sorted. I am sorry for confusion.



so the spec is ok as written, noting numerical sorting of the numbers.
No change here.


2.a. Section 4, item 6: Correspondingly to the above:
descending order
could become
descending numerical order
I would also define numerical order by taking an excerpt from
another part of the spec:
Numerical order is the order based on the numeric portion of the
signature file name.



good idea, agree


2.b. Section 4, item 6:
The ordering by file name can be used to allow consistent
processing and possible optimization.
The term ordering by file name may be misinterpreted in the
context of the numerical order, so I think that the whole statement
could be removed.



How about

Ordering of widget signature files by the numeric portion of the file
name can be used to allow consistent processing and possible
optimization.

I think we should keep a sentence since Mark Priestly had earlier
asked that we add it.



3. Section 4 + Section 5.3.1: Section 4 implies that sorting is an
operation that takes place after the signature files are found
within

Re: [widgets] Author

2009-03-27 Thread Frederick Hirsch
No I agree, we are trying to stay away from legal statements , that  
requires much more.


regards, Frederick

Frederick Hirsch
Nokia



On Mar 27, 2009, at 10:40 AM, ext Marcin Hanclik wrote:


Hi Frederick,

re author, would the term creator in the sentence from Thomas  
help,
this probably doesn't help, since by definition author means  
creator...

Yes, it seems the same.
Thomas' statement:
 What the author certificate lets you verify is whether a single  
party is taking responsibility for two widgets.


There is indeed no *proof* of authorship here, but a statement that  
the signer is willing to assume the blame for being the widget's  
author.  Which is all we need, no?


As for me author is just some distinguished entity. That's all and  
nothing more.
I think we should not try to specify in the W3C spec that the author  
takes the responsibility for what the widget does. It could be  
legally binding. Is this what we really want?


Thanks.

Kind regards,
Marcin

Marcin Hanclik
ACCESS Systems Europe GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com




Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that  
is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure,  
copying or distribution of the information by anyone else is  
strictly prohibited.
If you have received this document in error, please notify us  
promptly by responding to this e-mail. Thank you.





Re: [BONDI Architecture Security] [widgets] new digsig draft

2009-03-27 Thread Frederick Hirsch

comments inline, thanks for reviewing this


regards, Frederick

Frederick Hirsch
Nokia



On Mar 27, 2009, at 1:26 PM, ext Hillebrand, Rainer wrote:


Dear Marcos,

I hope to have less critical comments than in my last feedback email.

1. Section 7.1: change The ds:SignatureMethod algorithm used in the  
ds:SignatureValue element MUST one of the signature algorithms. to  
The ds:SignatureMethod algorithm used in the ds:SignatureValue  
element MUST be one of the signature algorithms.


ok




2. Section 7.1: The ds:KeyInfo element MAY be included and MAY  
include certificate, CRL and/or OCSP information.: CRL and OCSP are  
not defined before. Do you have a reference for these abbreviations?


will add RFC references. (but should be common to those familar with  
certs )





3. Section 7.3: The set of acceptable trust anchors, and policy  
decisions based on the signer's identity are established through a  
security-critical out-of-band mechanism. I do not really understand  
this sentence. This is not subject for the processing rules, isn't  
it? What is an acceptable trust anchor? Are they really established  
or may they be established?


knowing  whom you can trust and how to establish that trust is out of  
scope.





4. Section 8: change Care should be taken to avoid resource  
exhaustion attacks through maliciously crafted Widget archives  
during signature verification. to Care should be taken to avoid  
resource exhaustion attacks through maliciously crafted [widget  
package]s during signature validation.


ok




5. Section 8: change Implementations should be careful about  
trusting path components found in the zip archive to  
Implementations should be careful about trusting path components  
found in the [widget package]


ok




6. Section 8: change and naive unpacking of widget archives into  
to and naive unpacking of [widget package]s into



ok

7. Section 8: change e.g., overwriting of startup or system files  
to e.g. overwriting of startup or system files


No, I believe the correct usage is to have the comma. e.g. means  
exempli gratia , meaning for example.

Thus
for example, some text
I think we should change to for example in this case.


8. Section 8: change There is no single signature file that  
includes all contents of a widget, including all of the signatures.  
to There is no single signature file that includes all files of a  
[widget package], including all of the signature files.


ok, since everything is a file




9. Section 8: change This leaves a widget package subject to an  
attack where distributor signatures can be removed (and an author  
signature if any corresponding distributor signature is also  
removed), or added. to This leaves a widget package subject to an  
attack where distributor signatures can be removed or added. An  
author signature could also be attacked by removing it and any  
distributor signatures if they are present.


better, thanks




Best Regards,

Rainer

*
T-Mobile International
Terminal Technology
Rainer Hillebrand
Head of Terminal Security
Landgrabenweg 151, D-53227 Bonn
Germany

+49 171 5211056 (My T-Mobile)
+49 228 936 13916 (Tel.)
+49 228 936 18406 (Fax)
E-Mail: rainer.hillebr...@t-mobile.net

http://www.t-mobile.net

This e-mail and any attachment are confidential and may be  
privileged. If you are not the intended recipient, notify the sender  
immediately, destroy all copies from your system and do not disclose  
or use the information for any purpose.


Diese E-Mail inklusive aller Anhänge ist vertraulich und könnte  
bevorrechtigtem Schutz unterliegen. Wenn Sie nicht der beabsichtigte  
Adressat sind, informieren Sie bitte den Absender unverzüglich,  
löschen Sie alle Kopien von Ihrem System und veröffentlichen Sie  
oder nutzen Sie die Information keinesfalls, gleich zu welchem Zweck.



T-Mobile International AG
Aufsichtsrat/ Supervisory Board: René Obermann (Vorsitzender/  
Chairman)
Vorstand/ Board of Management: Hamid Akhavan (Vorsitzender/  
Chairman), Michael Günther, Lothar A. Harings, Katharina Hollender

Handelsregister/Commercial Register Entry: Amtsgericht Bonn, HRB 12276
Steuer-Nr./Tax No.: 205 / 5777/ 0518
USt.-ID./VAT Reg.No.: DE189669124
Sitz der Gesellschaft/ Corporate Headquarters: Bonn






Re: [BONDI Architecture Security] [widgets] new digsig draft

2009-03-27 Thread Frederick Hirsch

I think we should remove it.

Also, I revised the e.g. as follows

... undesireable and security relevant effects, such as overwriting of  
startup or system files.


regards, Frederick

Frederick Hirsch
Nokia



On Mar 27, 2009, at 2:00 PM, ext Hillebrand, Rainer wrote:


Dear Frederick,

I added my comments inline.

Best Regards,

Rainer

*
T-Mobile International
Terminal Technology
Rainer Hillebrand
Head of Terminal Security
Landgrabenweg 151, D-53227 Bonn
Germany

+49 171 5211056 (My T-Mobile)
+49 228 936 13916 (Tel.)
+49 228 936 18406 (Fax)
E-Mail: rainer.hillebr...@t-mobile.net

http://www.t-mobile.net

This e-mail and any attachment are confidential and may be  
privileged. If you are not the intended recipient, notify the sender  
immediately, destroy all copies from your system and do not disclose  
or use the information for any purpose.


Diese E-Mail inklusive aller Anhänge ist vertraulich und könnte  
bevorrechtigtem Schutz unterliegen. Wenn Sie nicht der beabsichtigte  
Adressat sind, informieren Sie bitte den Absender unverzüglich,  
löschen Sie alle Kopien von Ihrem System und veröffentlichen Sie  
oder nutzen Sie die Information keinesfalls, gleich zu welchem Zweck.








T-Mobile International AG
Aufsichtsrat/ Supervisory Board: René Obermann (Vorsitzender/  
Chairman)
Vorstand/ Board of Management: Hamid Akhavan (Vorsitzender/  
Chairman), Michael Günther, Lothar A. Harings, Katharina Hollender

Handelsregister/Commercial Register Entry: Amtsgericht Bonn, HRB 12276
Steuer-Nr./Tax No.: 205 / 5777/ 0518
USt.-ID./VAT Reg.No.: DE189669124
Sitz der Gesellschaft/ Corporate Headquarters: Bonn




-Original Message-

From: Frederick Hirsch [mailto:frederick.hir...@nokia.com]
Sent: Freitag, 27. März 2009 18:55
To: Hillebrand, Rainer
Cc: Frederick Hirsch; marc...@opera.com; WebApps WG
Subject: Re: [BONDI Architecture  Security] [widgets] new
digsig draft

comments inline, thanks for reviewing this


regards, Frederick

Frederick Hirsch
Nokia



On Mar 27, 2009, at 1:26 PM, ext Hillebrand, Rainer wrote:


3. Section 7.3: The set of acceptable trust anchors, and policy
decisions based on the signer's identity are established through a
security-critical out-of-band mechanism. I do not really

understand

this sentence. This is not subject for the processing rules, isn't
it? What is an acceptable trust anchor? Are they really

established

or may they be established?


knowing  whom you can trust and how to establish that trust
is out of
scope.



RH: Would you like to keep this sentence or delete it? I wonder  
whether we need to mention the potential use of the KeyInfo which is  
out-of-scope anyhow.





[widget-digsig] Updated Editors Draft of Widget Signature

2009-03-27 Thread Frederick Hirsch
I have completed a major round of editorial updates to the Widget  
Signature editors draft.


http://dev.w3.org/2006/waf/widgets-digsig/

This is intended to be our public working draft for Monday, so please  
review the changes. Thanks to all who commented. This does not include  
changes for issues that might require more discussion.


The document date and type (working draft vs editors draft) should be  
changed upon final publication.


Changes to note (and please review)

1. Added new section, Conventions.

Note that I attempted to give examples of the formats rather than  
describe the formatting, since the formatting is based on a style  
sheet that might change.


2. Added reference for OCSP ( RFC 2560 ) and removed reference for  
X509 v3, referring to RFC 5280 instead. Reference RFC 5280 at first  
reference of CRL


http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0980.html

3. Generally changed widget archive to widget package

4. Completed changes agreed in
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0969.html

see [1] below

5. Completed changes agreed in
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0970.html

see [2] below

6.  Completed changes agreed in
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0972.html

see [3] below

7.  Completed changes agreed in
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0973.html

see [4] below

8. Replaced two lower case must with MUST

9. Removed trust anchor text in 7.3:
The set of acceptable trust anchors, and policy  decisions based on  
the signer's identity are established through a security-critical out- 
of-band mechanism.

http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0982.html
  regards, Frederick

Frederick Hirsch
Nokia

[1] added
pNumerical order is the order based on the numeric portion of the
signature file name. Thus the highest numbered distributor signature
  would be validated first./p
to section 4, #6
---

replace
pThe ordering by
spanfile name/span can be used to allow consistent
processing and possible
optimization.

in section 4 #6 with

Ordering of widget signature files by the numeric portion of the file
name can be used to allow consistent processing and possible
optimization.

===
[2]

1. Section 1: ... with XML signatures that each cryptographically
 include all of the non-signature ...

 should become (missing s)

 ... with XML signatures that each cryptographically includes all of
 the non-signature ...


2. Unify case sensitive phrase. There are now both case-
 sensitive and case sensitive present in the text.

ok, lets go with case-sensitive since Websters has that.

a) Replace root of the archive with root of the widget


root of the widget package, as you corrected in later email
ok

 6. Section 4, item 5: .. treat this as.. - what is this? I
 suggest to change the text to ... treat this widget package as ...

7. Section 4, item 6: Validate the signature files in the
 signatures list - signatures looks weird, the cause is var vs.
 code in HTML.

8. Section 5.3.1: A file entry whose file name that does not match
 the - that should be removed

10. Section 7.2: The time SHOULD reflect the time that signature
 generation completes. - The time SHOULD reflect the time when
 signature generation completed.

11. Section 7.3: If present then user agents MUST perform Basic -
 If present, the user agents MUST perform Basic
user agent..

12. Section 9.2.1: The time SHOULD reflect the time that signature
 generation completes. - The time SHOULD reflect the time when
 signature generation completed.



[3]

pThese signatures em class=ctMUST/em be sorted numerically
  based on the numeric
  portion of the name. /p

to

Within a widget package these signature files MUST be ordered based
 on the numeric portion of the signature file name.

[4]

The RECOMMENDED version of the certificate format is X.509 version 3  
[X509v3]. Implementations MUST be prepared to accept X.509 v3  
certificates [X509v3], [RFC5280]. 

could become
The RECOMMENDED version of the certificate format is X.509 version 3
as specified in [RFC5280]. Implementations MUST be prepared to accept
X.509 v3 certificates [RFC5280].

removed X509 v3 reference.






Re: [widgets] new digsig draft

2009-03-26 Thread Frederick Hirsch

Marcos

I checked in another revision to fix the broken link in 7. 2 (last  
sentence included s in span) and to fix various validation errors.


 The latest revision looks ok to me now, version 1.85 of  
Overview.src.html, version 1.93 of Overview.html


regards, Frederick

Frederick Hirsch
Nokia



On Mar 25, 2009, at 7:35 PM, ext Marcos Caceres wrote:


Hi Frederick,
On Wed, Mar 25, 2009 at 11:20 PM, Frederick Hirsch
frederick.hir...@nokia.com wrote:

Marcos

Thanks for taking this pass.

 I note a number of editorial corrections that I believe should be  
made

before publishing:

1. Introduction should not have normative statements, and these  
replicate

material later in the document, so change MAY to can in 2 places.

2. Section 4, #4, change must to MUST


fixed


3. Section 4, #6, change Security to security


fixed

4. Section 5.3.1, include blank line between bullet with DIGIT and  
next

bullet


fixed


5. Section 6, replace .. with . in editorial note


fixed


6. Section 6.1, change DSAwithSHA to DSAwithSHA1


fixed

7. Section 7.2, change link to be from signature file, it is  
currently

broken


seemed ok? replaced it anyway.

8. End of section 8, remove example from sentence, change For  
example,

end-users  to End-users and combine with previous paragraph.


Done.


9. Add note to  [XMLDSIG-Properties] reference as follows (at end of
reference entry):

Note, section 9 includes additions made in the XML Security WG to  
the XML
Signature Properties editors draft (subsequent to First Public  
Working

Draft) that are used in this specification.


Done.


---

I also suggest you make sure that all changes in the working draft  
are also
reflected in what is checked into the Editors draft in CVS so we  
can make
changes as needed without losing these latest changes for the  
working draft
(the only difference need be the setting as editors vs working  
draft I

think).


Done.

I also notice on a substantive level that you changed the  
namespace. Was the
reason to match a pre-existing choice for the Packaging and  
Configuration?

Is this an item for discussion?


Yes, I did that today but never got around to sending out an email
about it. Sorry. The change was to put it inline with PC. Do you see
any issues arising from the new NS? should I change it back? I'm of
the position that NSs should not be dated because changing NS and,
hence semantics, for elements in the future is probably a bad idea.


The other changes looked good, thanks for improving the draft.


My pleasure! Thanks for doing all the hard work and actual  
thinking! :)


Kind regards,
Marcos

--
Marcos Caceres
http://datadriven.com.au





additional widgets signature fix

2009-03-26 Thread Frederick Hirsch
I fixed one additional ordered list nit in widgets signature, so it  
validates correctly.


When published the document date will need to be updated to the  
publication date.


regards, Frederick

Frederick Hirsch
Nokia






Re: AW: Re: [BONDI Architecture Security] [widgets] new digsig draft

2009-03-26 Thread Frederick Hirsch

(removing cross-posting since it doesn't work for mail from everyone)

I'd like to point out that section 5.2 says what an author signature  
*can* do. I'm strongly against muddying this to account for various  
edge cases - I agree with Thomas that the meaning is clear.


However I understand the concern so suggest changing the following:
The author signature can be used to determine:

• the author of a widget,
• that the integrity of the widget is as the author intended,
• and whether two widgets came from the same author.

to

The author signature can be used to:

	• allow an author to sign the widget, and if the signing key be  
related to their identity allow determination of the author,
	• enable integrity protection of the widget as intended by the signer  
using the author role,
	•  establish that two widgets with author signatures having used the  
same signing key are from the same party .




regards, Frederick

Frederick Hirsch
Nokia



On Mar 26, 2009, at 12:14 PM, ext Hillebrand, Rainer wrote:


Hi Marcos!

I agree with your suggestions.

Best Regards,

Rainer
---
Sent from my mobile device


- Originalnachricht -
Von: Marcos Caceres marc...@opera.com
An: Hillebrand, Rainer
Cc: WebApps WG public-webapps@w3.org; otsi-arch-...@omtplists.org otsi-arch-...@omtplists.org 


Gesendet: Thu Mar 26 16:24:22 2009
Betreff: Re: [BONDI Architecture  Security] [widgets] new digsig  
draft


Hi Rainer,

On Thu, Mar 26, 2009 at 1:57 PM, Hillebrand, Rainer
rainer.hillebr...@t-mobile.net wrote:

Dear Marcos,

I have some proposals for editorial changes.

1. Section 1.2: change which MAY logically contains to which MAY  
logically contain


fixed.

2. Section 1.2: An unsigned widget package is a widget package  
that does not contain any signature files. It is left to the user  
agent's security policy how to deal with unsigned widget packages.  
Doesn't the same apply to signed widget packages, too? There is no  
W3C right now that specifies how a user agent shall deal with  
signed widget packages. I suggest to delete the sentence It is  
left to the user agent's security policy how to deal with unsigned  
widget packages.




Deleted.

3. Section 1.2: Rules are concatenated by being written next to  
each other and a rule prep ended by * means zero or more. I would  
suggest to split this sentence into two: Rules are concatenated by  
being written next to each other. A rule prep ended by * means zero  
or more. What is a rule prep?




Ok, split. Dunno what a prep is, so I removed it.

4. Section 2: change this specification supports SHA-256 the  
reference element and ds:SignedInfo element to this specification  
supports SHA-256, the reference element and ds:SignedInfo element




fixed.

5. Section 3: Implementers are encouraged to provide mechanisms to  
enable end-users to install additional root certificates. Trust in  
a root certificate is established through a security critical  
mechanism implemented by the user agent that is out of scope for  
this specification. A root certificate could be used for TLS as  
well but we mean certificates for widget package signature  
verification. additional could imply that a user agent is always  
provided with at least one certificate which does not need to be  
the case. Therefore, I would like to propose to change this part to  
Implementers are encouraged to provide mechanisms to enable end- 
users to install certificates for widget package digital signature  
verification. Trust in a certificate is established through a  
security critical mechanism implemented by the user agent that is  
out of scope for this specification.




Ok, I included your text, but modified it slightly:

Implementers are encouraged to provide mechanisms to enable end-users
to install certificates for enabling verification of digital
signatures within the widget package. Trust in a certificate is
established through a security critical mechanism implemented by the
user agent, which is out of scope for this specification.


6. Section 4: Process the signature files in the signatures list  
in descending order, with distributor signatures first (if any).  
The processing is not defined before and it is unclear whether  
there is a difference between processing and signature validation.  
Suggestion: Validate the signature files in the signatures list in  
descending order, with distributor signatures first (if any).




Fixed.

7. Section 5.1: change in [XML-Schema-Datatypes])within to in  
[XML-Schema-Datatypes]) within


Fixed.

8. Section 5.2: change header Author Signatures to Author  
Signature because we have zero or one author signature.




True. fixed.

9. Section 5.2: and whether two widgets came from the same  
author: Two signed widgets that were signed with the same  
certificate only indicate that these both widgets were signed with  
the same certificate. The signatures do not enable any confidence

Re: AW: Re: [BONDI Architecture Security] [widgets] new digsig draft

2009-03-26 Thread Frederick Hirsch
I think the draft provides enough assurance for the intended level of  
use. If you want higher levels of assurance more will be required, but  
I don't believe we have a requirement here for that.


regards, Frederick

Frederick Hirsch
Nokia



On Mar 26, 2009, at 12:20 PM, ext Hillebrand, Rainer wrote:


Dear Marcos,

We cannot technically guarantee that the author signature really  
comes from the widget's author. It is like having an envelop with an  
unsigned letter. The envelop and the letter can come from different  
sources even if the envelop has a signature.


Best Regards,

Rainer
---
Sent from my mobile device


- Originalnachricht -
Von: Marcos Caceres marc...@opera.com
An: Paddy Byers pa...@aplix.co.jp
Cc: Hillebrand, Rainer; WebApps WG public-webapps@w3.org; otsi-arch-...@omtplists.org 
 otsi-arch-...@omtplists.org

Gesendet: Thu Mar 26 17:12:20 2009
Betreff: Re: [BONDI Architecture  Security] [widgets] new digsig  
draft


On Thu, Mar 26, 2009 at 4:29 PM, Paddy Byers pa...@aplix.co.jp  
wrote:

Hi,


Agreed. Can we say were signed with the same certificate instead?


I understood that Webapps had agreed to add a signature profile that
designates a particular signature as the author signature - and  
where this
is present it is possible to come up with appropriate precise  
wording as to

whether or not two packages originate from the same author.


Well, that's basically what we have, but Rainer seems to imply that it
is impossible to do this. I think we get as close as we technically
can to achieving that goal. However, if that current solution is
inadequate, then please send us suggestions.

--
Marcos Caceres
http://datadriven.com.au


T-Mobile International AG
Aufsichtsrat/ Supervisory Board: René Obermann (Vorsitzender/  
Chairman)
Vorstand/ Board of Management: Hamid Akhavan (Vorsitzender/  
Chairman), Michael Günther, Lothar A. Harings, Katharina Hollender

Handelsregister/Commercial Register Entry: Amtsgericht Bonn, HRB 12276
Steuer-Nr./Tax No.: 205 / 5777/ 0518
USt.-ID./VAT Reg.No.: DE189669124
Sitz der Gesellschaft/ Corporate Headquarters: Bonn






Re: AW: Re: [BONDI Architecture Security] [widgets] new digsig draft

2009-03-26 Thread Frederick Hirsch
I agree with what Thomas said as well. I  suggest we think about  
whether we really  need to change the specification since I read what  
is there as consistent with what Thomas wrote.


The intent is to flag a signature as an author signature - more  
detail is in my opinion in the same category as policy and other such  
important considerations, which we have not detailed in the  
specification.


regards, Frederick

Frederick Hirsch
Nokia



On Mar 26, 2009, at 5:06 PM, ext Marcin Hanclik wrote:


Hi,

I support this view.
In the whole design of various widget signatures it seems important  
that there is a list of signatures and from this list one is the  
distinguished one.

Naming of the signatures is not very important, I think.
The term author is not defined anywhere. It does not have to be a  
human being.
Probably sooner or later (depending on the market) the author could  
be someone/some entity/something who/that takes the responsibility  
for what the widget actually does -  as pointed out by Thomas - or  
who/that initiated some idea behind the widget's functionality.

What then the distributor signatures are for?
I assume some responsibility could also be assigned to them, but it  
is out of the scope of the standard that is to only cover the  
technical aspects.
Verification of integrity and signature are one thing, and  
responsibilities are covered by other agreements.
I understand that the author signature could also be used to honour  
the actual developer (a person) of the widget, but this seems to be  
just some principle in the business world.


Thanks.

Kind regards,
Marcin

From: public-webapps-requ...@w3.org [public-webapps-requ...@w3.org]  
On Behalf Of Thomas Roessler [...@w3.org]

Sent: Thursday, March 26, 2009 7:05 PM
To: Hillebrand, Rainer
Cc: frederick.hir...@nokia.com; mark.priest...@vodafone.com; marc...@opera.com 
; pa...@aplix.co.jp; public-webapps@w3.org; otsi-arch-...@omtplists.org
Subject: Re: AW: Re: [BONDI Architecture  Security] [widgets] new  
digsig draft


What the author certificate lets you verify is whether a single party
is taking responsibility for two widgets.

There is indeed no *proof* of authorship here, but a statement that
the signer is willing to assume the blame for being the widget's
author.  Which is all we need, no?
--
Thomas Roessler, W3C  t...@w3.org







On 26 Mar 2009, at 19:00, Hillebrand, Rainer wrote:


Dear Frederick,

The intent is clear but the technical solution will only provide
confidence if you trust the owner of the author certificate. If you
trust the owner then it is very likely for you that a widget with
this author signature really comes from this author. However, there
is no technical relationship between the widget author and the owner
of the author certificate that you can technically verify.

Best Regards,

Rainer
---
Sent from my mobile device


- Originalnachricht -
Von: Frederick Hirsch frederick.hir...@nokia.com
An: ext Priestley, Mark, VF-Group mark.priest...@vodafone.com
Cc: Frederick Hirsch frederick.hir...@nokia.com; Hillebrand,
Rainer; marc...@opera.com marc...@opera.com; pa...@aplix.co.jp 
pa...@aplix.co.jp

; public-webapps@w3.org public-webapps@w3.org; otsi-arch-...@omtplists.org

otsi-arch-...@omtplists.org
Gesendet: Thu Mar 26 18:34:57 2009
Betreff: Re: [BONDI Architecture  Security] [widgets] new digsig
draft

I think I disagree, since the intent *is* to identify the author,  
that

is the semantics, and this proposed change makes it less clear.

Of course we can argue whether or not you achieve that if you cannot
associate the signature with the author, but that is out of scope.


regards, Frederick

Frederick Hirsch
Nokia



On Mar 26, 2009, at 12:58 PM, ext Priestley, Mark, VF-Group wrote:


Hi All,

As the author signature was something I had a hand in creating let
me add my 2 pence worth.

Rainer is correct in that the author signature need not actually
come from the author of the widget. It comes from someone who claims
to be the widget's author. Whether you believe this claim depends on
how much you trust the signer.

In [1] the current text says:

[
The author signature can be used to determine:

 * the author of a widget,
 * that the integrity of the widget is as the author intended,
 * and whether two widgets came from the same author.
]

I would suggest changing this to:

[
The author signature can be used to:

 * authenticate the identity of the entity that added the author
signature to the widget package,
 * confirm that no widget files have been modified, deleted or
added since the generation of the author signature.

The author signature may be used to:
 * determine whether two widgets came from the same author.
]

The reason the last point is a may is as follows:

If two widgets contain author signatures that were created using the
same private key then we can say that the widgets were both signed

[widget-digsig] Editors note to be added to widget signature

2009-03-19 Thread Frederick Hirsch
Based on the discussion on today's call, I will add the following  
editors note to Widget Signature in section 6, Algorithms [1]:


Note:

This Widget Signature  specification relies on XML Signature 1.1 and  
the Web Applications WG is also seeking feedback on required  
algorithms for widget signatures, in particular which algorithms  
should be required in addition to RSAwithSHA256.


The XML Security WG has not yet achieved consensus on required  
algorithms in XML SIgnature 1.1, in particular whether to mandate  
ECDSAwithSHA256. The XML Security WG is requesting feedback on the  
FPWD of XML SIgnature 1.1.


regards, Frederick

Frederick Hirsch
Nokia


[1] http://dev.w3.org/2006/waf/widgets-digsig/#algorithms




RE: [widget-digsig] proposed change to 7.1, common constraints, for algorithms

2009-03-19 Thread Frederick Hirsch

Mark

I'll change the sentence to read

The ds:Signature MUST be produced using a key of the recommended key  
length or stronger.


Probably should change term from recommended key length to minimum  
key length.


Later when we update algorithms we probably should review whether we  
need key length defined for each algorithm but can defer for now.


Will this change of sentence work ?

Thanks

regards, Frederick

Frederick Hirsch
Nokia

(for some reason this message of yours did not reach my personal  
inbox, but it was on the list)


Hi Frederick, I agree with all of your changes with two comments. The  
sentence: The Signature  MUST be produced using a key of the  
recommended key length http://dev.w3.org/2006/waf/widgets-digsig/#recommended-key-length 
  is still problematic given that we allow (although discourage)  
key lengths less than the recommended key length, and probably don't  
want to rule out the use of longer keys. Suggest changing to: The  
Signature SHOULD be produced using a key of the recommended key length  
http://dev.w3.org/2006/waf/widgets-digsig/#recommended-key-length .  
The Signature MUST comply with Signature method algorithm requirements  
in the Algorithms section of this document I also think we need to  
link recommended key length to algorithms now we allow other  
algorithms to be used, ie if ECDSA is used it would be OK to use  
shorter keys. Thanks, Mark _




[widget-digsig] Editorial update of Widget Signature

2009-03-19 Thread Frederick Hirsch

I have completed the following editorial update of Widget Signature [1]:

1. Added proposed change to 7.1

http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0827.html

also added minor change in response to review comment from Mark:

http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0853.html

2. Added editorial note to section 6, algorithms

http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0851.html

with some editorial tweaks (expanding acronyms etc)

3. Added new section 9, Draft update to XML SIgnature Properties

This section records new sections in the current XML Signature  
Properties editors draft that are not reflected in the First Public  
Working draft of that document. They are included here so reviewers  
can see the referenced material. The section includes an editors note  
explaining the status of the section.


The WG agreed earlier that we would add this material.

4. Changed Security Policy to lowercase as appropriate.

This should complete all my editorial actions before publication.  
Please review and  let me know of any corrections or noted omissions.


regards, Frederick

Frederick Hirsch
Nokia

[1] http://dev.w3.org/2006/waf/widgets-digsig/




Re: [widget-digsig] Editorial update of Widget Signature

2009-03-19 Thread Frederick Hirsch
Completed additional changes to Editorial note in section 6, added  
links to XML Security WG home page, list of comments on FPWD and  
mailto link for comments on XML Signature 1.1.


Also fixed editorial nit, final set to a final set

regards, Frederick

Frederick Hirsch
Nokia



On Mar 19, 2009, at 11:45 AM, Hirsch Frederick (Nokia-CIC/Boston) wrote:

I have completed the following editorial update of Widget Signature  
[1]:


1. Added proposed change to 7.1

http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/ 
0827.html


also added minor change in response to review comment from Mark:

http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/ 
0853.html


2. Added editorial note to section 6, algorithms

http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/ 
0851.html


with some editorial tweaks (expanding acronyms etc)

3. Added new section 9, Draft update to XML SIgnature Properties

This section records new sections in the current XML Signature
Properties editors draft that are not reflected in the First Public
Working draft of that document. They are included here so reviewers
can see the referenced material. The section includes an editors note
explaining the status of the section.

The WG agreed earlier that we would add this material.

4. Changed Security Policy to lowercase as appropriate.

This should complete all my editorial actions before publication.
Please review and  let me know of any corrections or noted omissions.

regards, Frederick

Frederick Hirsch
Nokia

[1] http://dev.w3.org/2006/waf/widgets-digsig/






[widget-digsig] zip relative path update

2009-03-18 Thread Frederick Hirsch

Marcos

Regarding the requirement for validity checking zip relative paths in  
widget signature [1]  references, does the following change make sense  
to you?:


Change last paragraph in section 5.1, Use of XML Signature in Widgets  
to (only last sentence is changed, to two new sentences):


Every ds:Reference used within a widget signature MUST have a URI  
attribute. Every ds:Reference to an item within the widget signature  
MUST use an IDREF value for the ds:Reference URI attribute, referring  
to a unique ID within the widget signature [XML-Schema-Datatypes].  
Every ds:Reference to a widget file MUST use a  URI expressing the zip  
relative path to the widget file, properly URL encoded [URI]. The zip  
relative path MUST conform to the requirements expressed in [Widgets  
Packaging].


Please let me know any comment or suggestion. Thanks for noting this  
concern.


regards, Frederick

Frederick Hirsch
Nokia


[1] http://dev.w3.org/2006/waf/widgets-digsig/

On Mar 17, 2009, at 8:15 AM, ext Marcos Caceres wrote:



Hi Frederick,

On 3/17/09 1:01 PM, Frederick Hirsch wrote:

The latest draft includes the revised text from Thomas.

Marcos, are you suggesting we add something more? It sounds like what
you are saying here, is that it should be a valid widget file. Isn't
that part of PC checking? I'm not sure what it means to check that  
the

paths are as secure as possible.


You might want to check the following section of the PC [1] and see  
if

it is usable in dig sigs. Given that the paths in the reference
elements MUST be zip-relative-paths, the rules for checking the  
validity

of those paths may apply to the Widgets Dig Sig spec.


[1] http://dev.w3.org/2006/waf/widgets/#zip-relative-paths





[widget-digsig] proposed change to 7.1, common constraints, for algorithms

2009-03-18 Thread Frederick Hirsch

Mark

One issue you raised was that we have MUSTS on algorithms in the  
processing rules in section 7.1, but allow other algorithms in the  
algorithm section with MAY.


After our previous email exchange, I suggest the following changes to  
section 7.1 in Widget Signature [1] to address this concern:


(1) Change item 3b from

The Algorithm attribute of the ds:digestMethod MUST be set to a digest  
algorithm specified in the Algorithms section of this document.


to

The Algorithm attribute of the ds:digestMethod MUST comply with the  
digest algorithm requirements specified in the Algorithms section of  
this document.


(2) Change 5a from

The Algorithm attribute of the ds:CanonicalizationMethod element MUST  
be set to a Canonicalization method specified in the Algorithms  
section of this document.


to

The Algorithm attribute of the ds:CanonicalizationMethod element MUST  
comply with the Canonicalization method algorithm requirements  
specified in the Algorithms section of this document.



(3) Change 5b from

The ds:SignatureValue element MUST contain a signature generated using  
a Signature method specified in the Algorithms section of this  
document and MUST use a key that is of the length of arecommended key  
length.


to

The Signature method algorithm used in the ds:SignatureValue element  
MUST  comply with Signature method algorithm requirements in the  
Algorithms section of this document. The Signature  MUST be produced  
using a key of the recommended key length



Does this change make sense? Do you have any suggestion or comment?

Thanks for the careful review of the draft.

regards, Frederick

Frederick Hirsch
Nokia

[1] http://dev.w3.org/2006/waf/widgets-digsig/


[mp] While this is better I think it misses the fact that we are
strongly recommending the use of certain algorithms. I still like the
idea of including authoring (signing) guidelines/recommendations, ie  
you
can sign your widget using any signature algorithm but if you want  
it to

work across all W3C widget user agents use algorithm X. Same sort of
thing for digest algorithm and key length. What do you think?






[widgets-digsig] Updated 5.1 with revised Reference constraint text

2009-03-18 Thread Frederick Hirsch
I have updated the Widgets Signature editors draft, section 5.1 (use  
of xml signature) with revised text for Reference constraints. This is  
revised from what I proposed on list earlier as I tried to make the  
two cases clear (and disallow other random external references):


I replaced:

Every ds:Reference used within a widget signature MUST have a URI  
attribute. Every ds:Reference to an item within the widget signature  
MUST use an IDREF value for the ds:Reference URI attribute, referring  
to a unique ID within the widget signature [XML-Schema-Datatypes].  
Every ds:Reference to a widget file MUST use a relative URI expressing  
the path from the root of the widget resource to the referenced widget  
file [URI].


with
Every ds:Reference used within a widget signature MUST have a URI  
attribute.


Every ds:Reference MUST be one of the following two kinds of reference:

Reference to content within the same ds:Signature element
Every ds:Reference to an item within the widget signature MUST use an  
IDREF value for theds:Reference URI attribute, referring to a unique  
ID within the widget signature [XML-Schema-Datatypes].


Reference to a widget file in the same widget resource
The URI attribute of every ds:Reference to a widget file MUST be a URL- 
encoded [URI] zip relative path that identifies a file inside the  
widget package. A zip relative path MUST conform to the [ABNF] for zip- 
rel-path as specified in [Widgets Packaging].



Please let me know any additional comment or corrections. Thanks  
Marcos for suggestions to this wording.


(Also removed Inc from Nokia in title page)

regards, Frederick

Frederick Hirsch
Nokia

[1] http://dev.w3.org/2006/waf/widgets-digsig/



[widget-digsig] changed widget signature files processing rule in section 4

2009-03-18 Thread Frederick Hirsch
I have updated the latest Widget Signature editors draft section 4  
(locating and processing digital signatures) to no longer require the  
first signature to be processed.


http://dev.w3.org/2006/waf/widgets-digsig/#locating-signatures

The language is now (numbering ok in draft):

Process the digital signatures in the signatures list in descending  
order, with distributor signatures first.


The decision of which (if any) distributor signatures are to be  
validated and whether the author signature is validated is out of  
scope of this specification. This may be determined by the Security  
Policy used by the user agent.


The ordering by widget file name can be used to allow consistent  
processing and possible optimization.


Every signature that is validated MUST be validated according to  
Signature Validation defined in this specification.

Please indicate any comment or correction.

The latest draft also changes all usage of widget user agent to  
user agent.


regards, Frederick

Frederick Hirsch
Nokia


On Mar 16, 2009, at 4:46 PM, ext Priestley, Mark, VF-Group wrote:


[mp] My view is that whether zero, one or more signatures is processed
is up to the widget user agents security policy therefore we don't  
need

to say anything about which signatures (if any) must be processed. The
purpose of sorting the distributor signatures into ascending order  
is to

allow some optimisation of signature processing under certain
conditions. Maybe good to further clarify - I can try and come up with
something if you'd like (and of course if you agree)?








Re: [widgets] Comments on Widget Signature update (was RE: Widget Signature update)

2009-03-17 Thread Frederick Hirsch


 I already made this change :) to widget user agent.  I think that  
should work...


On Mar 17, 2009, at 6:28 AM, ext Marcos Caceres wrote:


On Thu, Mar 12, 2009 at 5:53 PM, Priestley, Mark, VF-Group
mark.priest...@vodafone.com wrote:

---
Editorial comments
---

General Terminology

Widget agent, widget platform, application? - widget user
agent?


Lets just use user agent. I don't think we should have a notion of a
widget user agent. A user agent is one that attempts to implement
the said specification; that is, one that only implements signatures.
It should be possible to build a user agent that only processes
signatures and is unaware any other of the widget 1.0 specifications.



[Comment] by application do you mean widget user agent?


as above.

--
Marcos Caceres
http://datadriven.com.au


regards, Frederick

Frederick Hirsch
Nokia






Re: [widgets] Comments on Widget Signature update (was RE: Widget Signature update)

2009-03-17 Thread Frederick Hirsch

The latest draft includes the revised text from Thomas.

Marcos, are you suggesting we add something more? It sounds like what  
you are saying here, is that it should be a valid widget file. Isn't  
that part of PC checking? I'm not sure what it means to check that  
the paths are as secure as possible.


regards, Frederick

Frederick Hirsch
Nokia

On Mar 17, 2009, at 7:22 AM, ext Marcos Caceres wrote:


On Mon, Mar 16, 2009 at 12:17 PM, Thomas Roessler t...@w3.org wrote:

I'd suggest this instead:

Implementations should be careful about trusting path components  
found in
the zip archive:  Such path components might be interpreted by  
operating

systems as pointing at security critical files outside the widget
environment proper, and naive unpacking of widget archives into  
the file
system might lead to undesirable and security relevant effects,  
e.g.,

overwriting of startup or system files.


What do you think?


I support this change. Makes sense. The other thing is to force
implementations of the dig sig spec to verify that a path conforms to
a zip-relative-path as defined in the packaging spec. And that we
check that zip-relative-paths as defined in the PC spec are secure as
possible.



--
Marcos Caceres
http://datadriven.com.au









Re: [widgets] Comments on Widget Signature update (was RE: Widget Signature update)

2009-03-17 Thread Frederick Hirsch

Marcos

Rather than replicating this, which might be error prone and hard to  
maintain, perhaps Widget Signature should reference P  C for this.  
What do you think ?


regards, Frederick


On Mar 17, 2009, at 8:15 AM, ext Marcos Caceres wrote:



Hi Frederick,

On 3/17/09 1:01 PM, Frederick Hirsch wrote:

The latest draft includes the revised text from Thomas.

Marcos, are you suggesting we add something more? It sounds like what
you are saying here, is that it should be a valid widget file. Isn't
that part of PC checking? I'm not sure what it means to check that  
the

paths are as secure as possible.


You might want to check the following section of the PC [1] and see  
if

it is usable in dig sigs. Given that the paths in the reference
elements MUST be zip-relative-paths, the rules for checking the  
validity

of those paths may apply to the Widgets Dig Sig spec.


[1] http://dev.w3.org/2006/waf/widgets/#zip-relative-paths



regards, Frederick

Frederick Hirsch
Nokia






[widgets-digsig] Editors Draft update and open issues

2009-03-16 Thread Frederick Hirsch
I have updated the Widgets Signature editors draft [1] according to  
the following, please review the changes:


1) Added ABNF update

http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0731.html
and
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0732.html

See section 1.2, 5.2, 5.3 and References

2) Added ds:Reference constraint

http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0742.html

See section 5.1 and References.

3) Clarified and updated security considerations text

http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0750.html

See section 8.

4) Misc editorial cleanup

http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0743.html

Security considerations as noted for 3, and clear editorial comments.

Throughout.

The following issues are still open (see message 743):

a) Remove Only the first distributor signature MUST be processed. ?

I think I agree that Widgets Signature should be silent on this. if  
so, where is this going to be noted?

Agreement to remove?

b) Remove DSAwithSHA1 requirement? Status of requirement R47 (Section  
2)?
 Support for Multiple Signature Algorithms: DSA-SHA-1, RSA-SHA-1, DSA- 
SHA-256 and RSA-SHA-256.


c) I suggest removing the restatement of algorithm requirements in  
section 7.1 , specifically remove #5a and #5b.


Are there any other changes needed that we are aware of?

Thanks

regards, Frederick

Frederick Hirsch
Nokia

[1] http://dev.w3.org/2006/waf/widgets-digsig/




Re: Revised Proposal for Widget Signature ABNF

2009-03-13 Thread Frederick Hirsch
Yes, I made this change since we decided this week to have case  
sensitivity. Too bad we have to use literals in hex for this case ...



On Mar 13, 2009, at 4:23 AM, ext Marcin Hanclik wrote:


Hi Jere,

Although I did not author the text below, I think the literals are  
specified as case-sensitive to match the experience from J2ME/MIDP  
[1].
Also case-sensitivity is more efficient when comparing strings, e.g.  
in constrained devices, and may be important for inter-operability  
reasons.

I.e. the spec seems intentional.

Thanks.

Kind regards,
Marcin

[1] 
http://java.sun.com/javame/reference/apis/jsr118/javax/microedition/midlet/package-summary.html


Marcin Hanclik
ACCESS Systems Europe GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com
From: jere.kapy...@nokia.com [mailto:jere.kapy...@nokia.com]
Sent: Friday, March 13, 2009 9:02 AM
To: Marcin Hanclik; frederick.hir...@nokia.com
Cc: marc...@opera.com; public-webapps@w3.org
Subject: Re: Revised Proposal for Widget Signature ABNF

Just wanted to ask if you’re using the character code terminals  
(%x61.75 etc.) intentionally because of case sensitivity? Literals  
like “signature” and “.xml” are allowed in ABNF [1], and they’re  
much easier for humans to read, but the catch is that they are case  
insensitive (and US-ASCII only). For case-sensitivity, you need to  
specify the character codes individually, as you’ve now done. So I  
guess that’s the intent?


--Jere

[1] http://tools.ietf.org/html/rfc5234#section-2.3


On 12.3.2009 23.45, ext Marcin Hanclik marcin.hanc...@access-company.com 
 wrote:

Hi Frederick,

I have further, again formal comments. I am sorry for not spotting  
that earlier.
The terminals (section 2.3 for RFC5234) can be concatenated with a  
dot ..

So

author-signature-filename = %x61 %x75 %x74 %x68 %x6f %x72 %x2d %x73
%x69 %x67 %x6e %x61 %x74 %x75 %x72 %x65 %x2e %x78 %x6d %x6 (missing  
'c')


can be represented as

author-signature-filename = %x61.75.74.68.6f.72.2d.73.69.67.6e. 
61.74.75.72.65.2e.78.6d.6c


This format also seems to guarantee that the whole string is kept in  
one line in majority of text editors (if line can be long enough).
Otherwise in the final spec a white space has to be put in each  
following line to satisfy the following rule (section 4.).


rule   =  rulename defined-as elements c-nl
; continues if next line starts
;  with white space

Thanks.

Kind regards,
Marcin

From: Frederick Hirsch [frederick.hir...@nokia.com]
Sent: Thursday, March 12, 2009 10:15 PM
To: Marcin Hanclik
Cc: Frederick Hirsch; Kapyaho Jere (Nokia-D-MSW/Tampere); ext Marcos  
Caceres; WebApps WG

Subject: Revised Proposal for Widget Signature ABNF

here is revised proposal, thanks Jere and Marcin

regards, Frederick

---

1) Change section 1.1, Notational conventions as follows:

Replace
This specification uses the following syntax to define filenames.
Characters are appended to numbers to indicate cardinality: ? (0 or
1) * (0 or more) + (1 or more)

A range of values is indicated by brackets, .i.e [1-9] indicates a
digit from the range 1 through 9 inclusive.

Concatenated values are written next to each other, with strings
indicated in quotes. Thus signature [1-9][0-9]* .xmlmeans a string
consisting of signature followed by a digit in the range 1-9
inclusive, followed by zero or more digits in the range 0-9 inclusive,
for example, signature12.xml.

with
This specification uses the following ABNF [ABNF] syntax to define
filenames. Rules are concatenated by being written next to each other
and a rule prepended by * means zero or more. See he ABNF RFC for
details.

2) Changes in the Naming convention for a author signature: in
section 5.2 Author Signatures:

The following ABNF [ABNF] rule defines the format of a author
signature file name:

Replace

The reserved file name author-signature.xml

with

The reserved lower-case (case sensitive) file name author-
signature.xml, as defined by the following ABNF [ABNF] rule:

author-signature-filename = %x61 %x75 %x74 %x68 %x6f %x72 %x2d %x73
%x69 %x67 %x6e %x61 %x74 %x75 %x72 %x65 %x2e %x78 %x6d %x6

3) Changes in the Naming convention for a distributor signature: in
section 5.3 Distributor Signatures:

3a) Replace

signature [1-9][0-9]* .xml

with

The following ABNF [ABNF] rule defines the format of a distributor
signature file name:

distributor-signature-filename = signature-string non-zero-digit
*DIGIT  xml-suffix string

signature-string = %x73 %x69 %x67 %x6e %x61 %x74 %x75 %x72 %x65

non-zero-digit = %x31-39

xml-suffix-string =  %x2e %x78 %x6d %x6c

The signature-string rule defines the lower-case (case sensitive)
string signature and the xml-suffix-string defines the lower-case
(case sensitive) string .xml. non-zero-digit defines a digit in the
range 1-9. DIGIT is defined in RFC-5234 [ABNF] to mean

Widget Signature Proposal: Add constraints on ds:Reference URIs

2009-03-13 Thread Frederick Hirsch
The following is a proposal to add text to the Widget Signature draft  
[1] to address the concern expressed by Thomas Roessler [2] regarding  
the need to constrain allowed ds:Reference URIs.


(1) Add to end of section 5.1, Use of XML Signature in Widgets, the  
following new paragraph (items within  are linked definitions, []  
are references):


Every ds:Reference used within a widget signature MUST have a URI  
attribute. Every ds:Reference to an item within the widget signature  
MUST use an IDREF value for the ds:Reference URI attribute, referring  
to a unique ID within the widget signature [XM-schema].  Every  
ds:Reference to a widget file MUST use a relative URI expressing the  
path from the  root of the widget resource to the referenced widget  
file [URI].


(2) Add reference

[XML-schema-datatypes]
XML Schema Part 2: Datatypes W3C Recommendation. P. Biron, A.  
Malhotra. May 2001.http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/


regards, Frederick

Frederick Hirsch
Nokia

[1] http://dev.w3.org/2006/waf/widgets-digsig/

[2] http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0547.html




Re: [widgets] Comments on Widget Signature update (was RE: Widget Signature update)

2009-03-13 Thread Frederick Hirsch

Mark

Thanks for your review, I have some comments inline. Thomas, can you  
please review my proposed change to the security considerations text  
Mark mentioned?


Thanks

regards, Frederick

Frederick Hirsch
Nokia

On Mar 12, 2009, at 12:53 PM, ext Priestley, Mark, VF-Group wrote:


Hi Frederick, All,

Some comments on the updated specification but first let me again say
thanks for doing a great job making all the changes!

---
Substantive comments
---

3

Implementers are encouraged to provide mechanisms to enable end-users
to install additional root certificates. Trust in a root certificate  
is

established through a security critical mechanism implemented by the
widget platform that is out of scope for this specification

[Comment] I know this was discussed before, and while I agree with the
overall sentiment of the text, if we are encouraging implementers to  
do

this then I wonder if we should also add some warning text to the
security considerations section, eg mechanisms to install new root
certificates should be subject to security critical mechanisms, for
example it end-users should be made aware of what they are doing and  
why

when installing a new root certificate.


sounds reasonable to add text to security considerations, will do.



4

5 Process the digital signatures in the signatures list in descending
order, with distributor signatures first.

  a. Only the first distributor signature MUST be processed.

[Comment] Why is it required to always process the first distributor
signature? What if the widget user agents security policy is only
concerned with the author signature?  I think 5a should be removed.


ok, but where do we say that only one need be processed in the set of  
specifications?
Do we need to clarify that even if more than one is present, not all  
need be processed? This seems to be important assumption/decision that  
will get lost.





6.1

Required for signature verification, optional for generation:
DSAwithSHA1

[Comment] When we discussed this before I think we agreed that it  
might

be necessary to support DSAwithSHA1 (and RSAwithSHA1?) for the
verification of signatures in certificate chains but we ruled out the
use of DSAwithSHA1 (and RSAwithSHA1) for widget signature generation
(and therefore verification) as they are already considered too weak.
Did I miss something?


What is the status of Requirement R47? looks like the algorithm MUSTs  
etc and requirement both need adjustment.






7.1

Constraint 3b

The Algorithm attribute of the ds:digestMethod MUST be set to a  
Digest

method specified in the Algorithms section of this document.

Constraint 5b

The ds:SignatureValue element MUST contain a signature generated  
using
a Signature method specified in the Algorithms section of this  
document

and MUST use a key that is of the length of a recommended key length.

[Comment] These constraints are MUSTs however the sections where we
describe Digest Algorithms, Signature Algorithms and recommended key
lengths the text currently allow the use of undefined other algorithms
and key lengths. This seems inconsistent. I think we need to allow for
the use of other algorithms and key lengths but at the same time we  
have

to somehow state that a widget user agent MUST support the base set
defined in the specification, and authors should use these if they  
want

to ensure interoperability. As such, perhaps 3b and 5b would be better
included as authoring guidelines?


how about replacing:

The ds:Signature MUST meet the following requirements:

	• The Algorithm attribute of the ds:CanonicalizationMethod element  
MUST be set to a Canonicalization method specified in the Algorithms  
section of this document.
	• The ds:SignatureValue element MUST contain a signature generated  
using a Signature method specified in the Algorithms section of this  
document and MUST use a key that is of the length of a recommended key  
length.

with



The ds:Signature MUST meet the following requirements:

	* Algorithms MUST conform to requirements given in the algorithms  
section of this specification.


re is really no need to say this except to make sure it is not missed,  
since the algorithms section outlines algorithm requirements. I'm also  
ok with removing this entirely. What do you think?)





8

Implementations that store the content of widget archives to the file
system during signature verification MUST NOT trust any path  
components
of file names present in the archive, to avoid overwriting of  
arbitrary

files during signature verification.




{Comment] I don't understand this sentence - which may well be a  
problem

with my understanding rather than the sentence - please can you
enlighten me, thanks.





I think this is better worded as:

Implementations MUST NOT overwrite widget files during signature  
verification, as this could open the possibility of an attack based on  
substituting content for files

widget signature proposed change: ABNF

2009-03-12 Thread Frederick Hirsch
Here is a revised proposal to updated Widget Signature to use ABNF. We  
have to make adjustments since the strings are case sensitive now.  
Here are the change to the editors draft [1] required:


1) Change section 1.1, Notational conventions as follows:

Replace
This specification uses the following syntax to define filenames.  
Characters are appended to numbers to indicate cardinality: ? (0 or  
1) * (0 or more) + (1 or more)


A range of values is indicated by brackets, .i.e [1-9] indicates a  
digit from the range 1 through 9 inclusive.


Concatenated values are written next to each other, with strings  
indicated in quotes. Thus signature [1-9][0-9]* .xmlmeans a string  
consisting of signature followed by a digit in the range 1-9  
inclusive, followed by zero or more digits in the range 0-9 inclusive,  
for example, signature12.xml.


with
This specification uses the following ABNF [ABNF] syntax to define  
filenames. Rules are concatenated by being written next to each other  
and a rule prepended by * means zero or more. See he ABNF RFC for  
details.


2) Changes in the Naming convention for a author signature: in  
section 5.2 Author Signatures:


The following ABNF [ABNF] rule defines the format of a author  
signature file name:


Replace

The reserved file name author-signature.xml

with

The reserved lower-case (case sensitive) file name author- 
signature.xml, as defined by the following ABNF [ABNF] rule:


author-signature-filename = %d097 %d117 %d116 %d104 %d111 %d114 %d045  
%d115 %d105 %d103 %d110   %d097 %d116 %d117 %d114 %d101 %d046 %d120  
%d109 %d108


3) Changes in the Naming convention for a distributor signature: in  
section 5.3 Distributor Signatures:


3a) Replace

signature [1-9][0-9]* .xml

with

The following ABNF [ABNF] rule defines the format of a distributor  
signature file name:


distributor-signature-filename = signature-string non-zero-digit  
*DIGIT  xml-suffix string


signature-string = %d115 %d105 %d103 %d110 %d097 %d116 %d117 %d114 %d101

non-zero-digit = %d049-%d057

xml-suffix-string =  %d046 %d120 %d109 %d108

The signature-string rule defines the lower-case (case sensitive)  
string signature and the xml-suffix-string defines the lower-case  
(case sensitive) string .xml. non-zero-digit defines a digit in the  
range 1-9. DIGIT is defined in RFC-5234 [ABNF] to mean a digit in the  
range 0-9.


3b) in first bullet, replace 'consisting of the string signature'  
with 'consisting of the lower-case string signature' and replace  
'then .xml, as stated by the BNF' with 'then the lower-case string  
.xml, as stated by the ABNF'


3c) replace BNF with ABNF in the third bullet

4) Add reference to ABNF in references section, with source Jere noted:

dtdfn id=abnf[ABNF]/dfn/dt
  ddRFC 5234, a href=http://www.ietf.org/rfc/ 
rfc5234.txtciteAugmented BNF

for Syntax Specifications: abbr title=Augmented
Backus-Naur FormABNF/abbr/cite/a. D. Crocker   
and P. Overell.

  January 2008./dd


Unless I hear otherwise by Monday, I will make this change to the  
editors draft. If you agree with the change please let me know.


Thanks

regards, Frederick

Frederick Hirsch
Nokia

[1] http://dev.w3.org/2006/waf/widgets-digsig/


On Mar 12, 2009, at 9:43 AM, Kapyaho Jere (Nokia-D-MSW/Tampere) wrote:


One (possibly minor) point regarding the filename rule:

At least the Widgets 1.0 PC spec uses ABNF (RFC 5234) and refers to  
it, maybe this would be good also in the DigSig spec?


The rule expressed in ABNF would be something like:




signature-filename = “signature” non-zero-digit *DIGIT  “.xml”
non-zero-digit = %x31-39

Here, DIGIT is a prefabricated rule defined in RFC 5234. This rule  
says that in between the strings there must be at least one non-zero  
digit, followed by zero or more “normal” digits.


The normative reference for ABNF would be (grabbed from the PC spec):

dtdfn id=abnf[ABNF]/dfn/dt
  ddRFC 5234, a href=http://www.ietf.org/rfc/ 
rfc5234.txtciteAugmented BNF

for Syntax Specifications: abbr title=Augmented
Backus-Naur FormABNF/abbr/cite/a. D.  
Crocker  and P. Overell.

  January 2008./dd

--Jere

On 9.3.2009 22.51, Hirsch Frederick (Nokia-CIC/Boston) frederick.hir...@nokia.com 
 wrote:


I updated section 4 to correspond to  this:

If the signatures list is not empty, sort the list of signatures by
the file name field in ascending numerical order (e.g.signature1.xml
followed by signature2.xml followed by signature3.xml etc).


regards, Frederick

Frederick Hirsch
Nokia



On Mar 6, 2009, at 10:07 AM, ext Marcos Caceres wrote:

 Hi Frederick,

 On 3/6/09 3:59 PM, Frederick Hirsch wrote:
 I've updated the widget signature document distributor file naming
 convention to the following after discussing this with Josh (thanks
 Josh):

 Naming convention for a distributor signature:
|signature [1-9][0-9]* .xml|

*

  Each distributor signature /MUST/ have a name consisting

Re: widget signature proposed change: ABNF

2009-03-12 Thread Frederick Hirsch
the ABNF spec used decimal for the character encoding examples and hex  
for the digit range. I thought I should try to be consistent :).  
Thanks for the fix on the range, there also a couple of typos in the  
proposal text I can fix.


Shall I keep the characters in decimal and change the non-zero-range  
to hex? That would match the RFC approach...


regards, Frederick

Frederick Hirsch
Nokia



On Mar 12, 2009, at 12:06 PM, ext Marcin Hanclik wrote:


Hi Frederick,

One line of the ABNF quoted below could be adjusted to match
RFC5234: 3.4. Value Range Alternatives: %c##-##.

non-zero-digit = %d049-%d057

could be

non-zero-digit = %d049-057

Also I think that decimal encoding could be changed to hex encoding.
Since the strings are already encoded, I think, hex has more compact  
representation and is used in ABNF spec itself.


Thanks.

Kind regards,
Marcin

Marcin Hanclik
ACCESS Systems Europe GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com

-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org 
] On Behalf Of Frederick Hirsch

Sent: Thursday, March 12, 2009 4:40 PM
To: Kapyaho Jere
Cc: Frederick Hirsch; ext Marcos Caceres; WebApps WG
Subject: widget signature proposed change: ABNF

Here is a revised proposal to updated Widget Signature to use ABNF. We
have to make adjustments since the strings are case sensitive now.
Here are the change to the editors draft [1] required:

1) Change section 1.1, Notational conventions as follows:

Replace
This specification uses the following syntax to define filenames.
Characters are appended to numbers to indicate cardinality: ? (0 or
1) * (0 or more) + (1 or more)

A range of values is indicated by brackets, .i.e [1-9] indicates a
digit from the range 1 through 9 inclusive.

Concatenated values are written next to each other, with strings
indicated in quotes. Thus signature [1-9][0-9]* .xmlmeans a string
consisting of signature followed by a digit in the range 1-9
inclusive, followed by zero or more digits in the range 0-9 inclusive,
for example, signature12.xml.

with
This specification uses the following ABNF [ABNF] syntax to define
filenames. Rules are concatenated by being written next to each other
and a rule prepended by * means zero or more. See he ABNF RFC for
details.

2) Changes in the Naming convention for a author signature: in
section 5.2 Author Signatures:

The following ABNF [ABNF] rule defines the format of a author
signature file name:

Replace

The reserved file name author-signature.xml

with

The reserved lower-case (case sensitive) file name author-
signature.xml, as defined by the following ABNF [ABNF] rule:

author-signature-filename = %d097 %d117 %d116 %d104 %d111 %d114 %d045
%d115 %d105 %d103 %d110   %d097 %d116 %d117 %d114 %d101 %d046 %d120
%d109 %d108

3) Changes in the Naming convention for a distributor signature: in
section 5.3 Distributor Signatures:

3a) Replace

signature [1-9][0-9]* .xml

with

The following ABNF [ABNF] rule defines the format of a distributor
signature file name:

distributor-signature-filename = signature-string non-zero-digit
*DIGIT  xml-suffix string

signature-string = %d115 %d105 %d103 %d110 %d097 %d116 %d117 %d114  
%d101


non-zero-digit = %d049-%d057

xml-suffix-string =  %d046 %d120 %d109 %d108

The signature-string rule defines the lower-case (case sensitive)
string signature and the xml-suffix-string defines the lower-case
(case sensitive) string .xml. non-zero-digit defines a digit in the
range 1-9. DIGIT is defined in RFC-5234 [ABNF] to mean a digit in the
range 0-9.

3b) in first bullet, replace 'consisting of the string signature'
with 'consisting of the lower-case string signature' and replace
'then .xml, as stated by the BNF' with 'then the lower-case string
.xml, as stated by the ABNF'

3c) replace BNF with ABNF in the third bullet

4) Add reference to ABNF in references section, with source Jere  
noted:


dtdfn id=abnf[ABNF]/dfn/dt
  ddRFC 5234, a href=http://www.ietf.org/rfc/
rfc5234.txtciteAugmented BNF
for Syntax Specifications: abbr title=Augmented
Backus-Naur FormABNF/abbr/cite/a. D. Crocker
and P. Overell.
  January 2008./dd


Unless I hear otherwise by Monday, I will make this change to the
editors draft. If you agree with the change please let me know.

Thanks

regards, Frederick

Frederick Hirsch
Nokia

[1] http://dev.w3.org/2006/waf/widgets-digsig/


On Mar 12, 2009, at 9:43 AM, Kapyaho Jere (Nokia-D-MSW/Tampere) wrote:


One (possibly minor) point regarding the filename rule:

At least the Widgets 1.0 PC spec uses ABNF (RFC 5234) and refers to
it, maybe this would be good also in the DigSig spec?

The rule expressed in ABNF would be something like:




signature-filename = signature non-zero-digit *DIGIT  .xml
non-zero-digit = %x31-39

Here, DIGIT is a prefabricated rule defined in RFC 5234. This rule
says that in between

Revised Proposal for Widget Signature ABNF

2009-03-12 Thread Frederick Hirsch

here is revised proposal, thanks Jere and Marcin

regards, Frederick

---

1) Change section 1.1, Notational conventions as follows:

Replace
This specification uses the following syntax to define filenames.
Characters are appended to numbers to indicate cardinality: ? (0 or
1) * (0 or more) + (1 or more)

A range of values is indicated by brackets, .i.e [1-9] indicates a
digit from the range 1 through 9 inclusive.

Concatenated values are written next to each other, with strings
indicated in quotes. Thus signature [1-9][0-9]* .xmlmeans a string
consisting of signature followed by a digit in the range 1-9
inclusive, followed by zero or more digits in the range 0-9 inclusive,
for example, signature12.xml.

with
This specification uses the following ABNF [ABNF] syntax to define
filenames. Rules are concatenated by being written next to each other
and a rule prepended by * means zero or more. See he ABNF RFC for
details.

2) Changes in the Naming convention for a author signature: in
section 5.2 Author Signatures:

The following ABNF [ABNF] rule defines the format of a author
signature file name:

Replace

The reserved file name author-signature.xml

with

The reserved lower-case (case sensitive) file name author-
signature.xml, as defined by the following ABNF [ABNF] rule:

author-signature-filename = %x61 %x75 %x74 %x68 %x6f %x72 %x2d %x73  
%x69 %x67 %x6e %x61 %x74 %x75 %x72 %x65 %x2e %x78 %x6d %x6


3) Changes in the Naming convention for a distributor signature: in
section 5.3 Distributor Signatures:

3a) Replace

signature [1-9][0-9]* .xml

with

The following ABNF [ABNF] rule defines the format of a distributor
signature file name:

distributor-signature-filename = signature-string non-zero-digit
*DIGIT  xml-suffix string

signature-string = %x73 %x69 %x67 %x6e %x61 %x74 %x75 %x72 %x65

non-zero-digit = %x31-39

xml-suffix-string =  %x2e %x78 %x6d %x6c

The signature-string rule defines the lower-case (case sensitive)
string signature and the xml-suffix-string defines the lower-case
(case sensitive) string .xml. non-zero-digit defines a digit in the
range 1-9. DIGIT is defined in RFC-5234 [ABNF] to mean a digit in the
range 0-9.

3b) in first bullet, replace 'consisting of the string signature'
with 'consisting of the lower-case string signature' and replace
'then .xml, as stated by the BNF' with 'then the lower-case string
.xml, as stated by the ABNF'

3c) replace BNF with ABNF in the third bullet

4) Add reference to ABNF in references section, with source Jere
noted:

dtdfn id=abnf[ABNF]/dfn/dt
 ddRFC 5234, a href=http://www.ietf.org/rfc/
rfc5234.txtciteAugmented BNF
   for Syntax Specifications: abbr title=Augmented
   Backus-Naur FormABNF/abbr/cite/a. D. Crocker
and P. Overell.
 January 2008./dd


Unless I hear otherwise by Monday, I will make this change to the
editors draft. If you agree with the change please let me know.

Thanks

regards, Frederick

Frederick Hirsch
Nokia

[1] http://dev.w3.org/2006/waf/widgets-digsig/




Re: Widget Signature update

2009-03-09 Thread Frederick Hirsch

I updated section 4 to correspond to  this:

If the signatures list is not empty, sort the list of signatures by  
the file name field in ascending numerical order (e.g.signature1.xml  
followed by signature2.xml followed by signature3.xml etc).



regards, Frederick

Frederick Hirsch
Nokia



On Mar 6, 2009, at 10:07 AM, ext Marcos Caceres wrote:


Hi Frederick,

On 3/6/09 3:59 PM, Frederick Hirsch wrote:

I've updated the widget signature document distributor file naming
convention to the following after discussing this with Josh (thanks  
Josh):


Naming convention for a distributor signature:
   |signature [1-9][0-9]* .xml|

   *

 Each distributor signature /MUST/ have a name consisting of
 the string signature followed by a digit in the range 1-9
 inclusive, followed by zero or more digits in the range 0-9
 inclusive and then .xml, as stated by the BNF. An  
example is

 signature20.xml.

   *

 Leading zeros are disallowed in the numbers.

   *

 Any file name that does not match this BNF /MUST/ be  
ignored.
 Thus a file named signature01.xml will be ignored. A  
warning

 /MAY/ be generated.

   *

 There is no requirement that all the signature file names  
form

 a contiguous set of numeric values.

   *

 These signatures /MUST/ be sorted numerically based on the
 numeric portion of the name. Thus signature2.xml preceeds
 signature11.xml, for example.


See draft
http://dev.w3.org/2006/waf/widgets-digsig/#distributor-signatures

I also updated the notation section, changed the code format to be
italic (without color), and updated the body style to not be quite  
so large.


Please indicate any comment or corrections on the list.



The changes look good to me! thank you.

Kind regards,
Marcos





Re: numbering

2009-03-05 Thread Frederick Hirsch

Josh,

This does not seem quite right since it requires 10 or more signatures?

e.g. disallows signature01.xml, signature02.xml etc
and requires signature10.xml etc

---

I propose the following alternative in section 5.3

Naming convention for a distributor signature:signature [0-9]* .xml

Every distributor signature MUST have the same number of digits in the  
file name and use leading zeros for numbers less than the maximum  
numeric value. This is to enable consistent sorting.


To give an example, if nine distributor signatures are expected the  
numbers should range from 01 to 09, e.g. signature01.xml to  
signature09.xml.

---

Does this make sense?

regards, Frederick


Frederick Hirsch
Nokia



On Mar 5, 2009, at 9:15 AM, ext timeless wrote:


http://dev.w3.org/2006/waf/widgets-digsig/#locating-signatures

4.3
If the signatures list is not empty, sort the list of signatures by  
the file name field in descending order (e.g. signature001.xml  
followed by signature9.xml followed by signature.xml).


How do you sort signature009.xml and signature9.xml?

The proposal is to only allow [1-9][0-9]*, which should solve this.

And validators should complain about archives containing files of the
form signature [0][0-9]* .xml






Re: [widgets] Minutes from 5 March 2009 Voice Conference

2009-03-05 Thread Frederick Hirsch
I updated the style for code items in the Digital Signature  
specification to brown.


Does this work better? It does not conflict with other color uses as  
far as I can tell.


Please look at
http://dev.w3.org/2006/waf/widgets-digsig/  (refresh)


regards, Frederick

Frederick Hirsch
Nokia



On Mar 5, 2009, at 10:11 AM, Barstow Art (Nokia-CIC/Boston) wrote:


The minutes from the March 5 Widgets voice conference are available
at the following and copied below:

 http://www.w3.org/2009/03/05-wam-minutes.html

WG Members - if you have any comments, corrections, etc., please send
them to the public-webapps mail list before 12 March 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

05 Mar 2009

   [2]Agenda

  [2] http://lists.w3.org/Archives/Public/public-webapps/
2009JanMar/0622.html

   See also: [3]IRC log

  [3] http://www.w3.org/2009/03/05-wam-irc

Attendees

   Present
  Art, Frederick, Josh, Jere, Marcos, Arve, David, Benoit

   Regrets
  Claudio, Bryan

   Chair
  Art

   Scribe
  Art

Contents

 * [4]Topics
 1. [5]Review and tweak agenda
 2. [6]Announcements
 3. [7]DigSig + PC synchronization
 4. [8]Issue-19 - Widgets digital Signatures spec does not  
meet

required use cases and requirements;
 5. [9]Issue-80 - Runtime localization model for widgets
 6. [10]Issue-82 - potential conflict between the XHTML
access and Widget access element.
 7. [11]Issue-83 - Instantiated widget should not be able to
read digital signature.
 8. [12]Widget requirement #37 (URI scheme etc) - see e-mail
from Thomas:
 9. [13]Open Actions
10. [14]June f2f meeting
11. [15]TPAC meeting in November
12. [16]Window Modes
13. [17]Editorial Tasks
14. [18]Anything Else
 * [19]Summary of Action Items
 _



   scribe ScribeNick: ArtB

   scribe Scribe: Art

   Date: 5 March 2009

   fjh widgets signature editors draft update

   fjh
   [20]http://dev.w3.org/2006/waf/widgets-digsig/#locating-signatures

 [20] http://dev.w3.org/2006/waf/widgets-digsig/#locating-
signatures

   fjh
   [21]http://dev.w3.org/2006/waf/widgets-digsig/#locating-signatures

 [21] http://dev.w3.org/2006/waf/widgets-digsig/#locating-
signatures

Review and tweak agenda

   AB: agenda posted March 4 - is
   [22]http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/ 
06

   22.html
   ... the main agenda items are Open Issues. I only want to spend a
   few minutes on each of them to get a sense of where we are e.g.
   still Open, pending inputs, can be Closed. Any detailed technical
   discussions should occur on public-webapps mail list.
   ... Are there any change requests?

 [22] http://lists.w3.org/Archives/Public/public-webapps/
2009JanMar/0622.html

   [ None ]

Announcements

   AB: I don't have any urgent announcements
   ... what about others?

   FH: please submit comments on XML Sig 1.1 drafts

   DR: I will respond to Art's BONDI 1.0 email so please look at that

   fjh please review XML Signature 1.1 and XML Signature Properties
   FPWD

   fjh [23]http://www.w3.org/News/2009#item25

 [23] http://www.w3.org/News/2009#item25

   MC: I uploaded the Window Modes spec; would like to get that on the
   agenda

DigSig + PC synchronization

   AB: earlier this week Frederick asked me if the DigSig + PC specs
   are now in synch, based on last week's discussions?

   fjh
   [24]http://dev.w3.org/2006/waf/widgets-digsig/#locating-signatures

 [24] http://dev.w3.org/2006/waf/widgets-digsig/#locating-
signatures

   AB: I believe the answer is yes.
   ... where are we on this?

   MC: FH and I talked about this
   ... I think this is mostly now addressed
   ... PC has no real depedency on DigSig

   fjh marcos notes merged steps 4 +5, moved locating to dig sig,
   removed signature variable from p + c

   MC: I haven't completed the PC changes yet
   ... e.g. renumber some steps

   fjh fjh notes revised text on locating to fit it within digsig  
but

   essence is same

   FH: I had to revise the location text a bit but the logic is the
   same
   ... Josh asked about the sorting
   ... I need to think about that a bit more

   JS: need to clarify diff between 9 and 009
   ... we can take this discussion to the list

   FH: I agree we need more rigor here

   MC: I agree too
   ... need to address case sensitivity too

   AB: can we point to some existing work?

   FH: I don't think this is a big issue and agree we can discuss on
   the list

   AB: what needs to be done then?

   FH: I need to make a few changes to DigSig and MC needs to do a bit
   more on PC

   JS

Re: [widgets] Minutes from 5 March 2009 Voice Conference

2009-03-05 Thread Frederick Hirsch

yes that has been the case ever since I've started working on this.

Perhaps there is a W3C standard stylesheet we should be using. I'm not  
sure why the spec defines its own styles


regards, Frederick

Frederick Hirsch
Nokia



On Mar 5, 2009, at 11:45 AM, Kapyaho Jere (Nokia-D-MSW/Tampere) wrote:

Easier on the eye, but to me it’s pretty close to the color of RFC  
2119 keyword style (em.ct).


Seems like the body text font has grown in size somewhat, compared  
to other specs.


--Jere

On 5.3.2009 18.03, Hirsch Frederick (Nokia-CIC/Boston) frederick.hir...@nokia.com 
 wrote:


I updated the style for code items in the Digital Signature
specification to brown.

Does this work better? It does not conflict with other color uses as
far as I can tell.

Please look at
http://dev.w3.org/2006/waf/widgets-digsig/  (refresh)


regards, Frederick

Frederick Hirsch
Nokia



On Mar 5, 2009, at 10:11 AM, Barstow Art (Nokia-CIC/Boston) wrote:

JS: re styling, orange doesn't work well for me regarding
readability

MC: I can help with that

FH: I'll take a pass at that






Updated Widgets 1.0 Signature editors draft

2009-03-05 Thread Frederick Hirsch

I have updated the Widgets 1.0 Signature editors draft [1] as follows:

1) Added new section Locating and Processing Widget Signatures as  
noted on today's call.


This section contains material that was formerly in the Packaging and  
Configuration Specification.


2) Updated the definitions section

3) Updated the references to reference the current XML Security First  
Public Working Drafts and more recent Widgets drafts.


4) Revised processing rules section to have common constraints for  
both signing and validation, rewrote some of the text, updated  
language related to signature failure.


5) Changed code style to brown and fixed various other editorial nits.

There is currently some new text regarding distributor file naming  
from today's call, but this will probably change as we are discussing  
this on the list (I sent a proposed revision to the list)


Still to do are possible changes related to Thomas's comments re ID  
reference language and additional properties.


regards, Frederick

Frederick Hirsch
Nokia

[1] http://dev.w3.org/2006/waf/widgets-digsig/





Re: [widgets] Minutes from 5 March 2009 Voice Conference

2009-03-05 Thread Frederick Hirsch

how about simple italics for code?

I'll also look into reducing body text

regards, Frederick

Frederick Hirsch
Nokia



On Mar 5, 2009, at 11:59 AM, Hirsch Frederick (Nokia-CIC/Boston) wrote:


yes that has been the case ever since I've started working on this.

Perhaps there is a W3C standard stylesheet we should be using. I'm not
sure why the spec defines its own styles

regards, Frederick

Frederick Hirsch
Nokia



On Mar 5, 2009, at 11:45 AM, Kapyaho Jere (Nokia-D-MSW/Tampere) wrote:


Easier on the eye, but to me it’s pretty close to the color of RFC
2119 keyword style (em.ct).

Seems like the body text font has grown in size somewhat, compared
to other specs.

--Jere

On 5.3.2009 18.03, Hirsch Frederick (Nokia-CIC/Boston) 
frederick.hir...@nokia.com

wrote:


I updated the style for code items in the Digital Signature
specification to brown.

Does this work better? It does not conflict with other color uses as
far as I can tell.

Please look at
http://dev.w3.org/2006/waf/widgets-digsig/  (refresh)


regards, Frederick

Frederick Hirsch
Nokia



On Mar 5, 2009, at 10:11 AM, Barstow Art (Nokia-CIC/Boston) wrote:


  JS: re styling, orange doesn't work well for me regarding
  readability

  MC: I can help with that

  FH: I'll take a pass at that








Re: Review of latest Widget Signature Draft

2009-03-03 Thread Frederick Hirsch

Thomas

Thank you for your constructive comments on Widget Signature.

As outlined below, the latest draft incorporates changes to address  
your comments. Please let me know if any additional change is needed  
for the items that I indicate have been corrected in the draft. Unless  
I hear otherwise, I will assume the comments have been addressed  
adequately.


The latest draft is available at

http://dev.w3.org/2006/waf/widgets-digsig/

Redline is at http://dev.w3.org/2006/waf/widgets-digsig/Overview-diff.html

A few of your comments remain open but should be addressed soon

+ Text for ID based references
+ Timestamp and serial number, expiration

As you note the issue of second hash algorithm might be more difficult  
and may also depend on XML Signature 1.1 decisions, so that has not  
also been addressed.


Thanks

regards, Frederick

Frederick Hirsch
Nokia



On Feb 25, 2009, at 7:06 AM, ext Thomas Roessler wrote:


In reviewing the latest draft, a couple of comments.

  Widgets 1.0: Digital Signatures
  Editor's Draft 23 February 2009
  http://dev.w3.org/2006/waf/widgets-digsig/

(Mostly) editorial:

- I would propose including a table of namespace prefixes and
namespace URIs, and just saying that the prefixes are editorial
conventions.  The current text in 1.1 and 1.2 is a bit hard to refer
to, and the text in 1.2 sounds like it comes from a time when
namespaces were new.  (It is, since it's lifted straight from XML
Signature 1.0. ;-)



The current editors draft includes a change to address this.


- 4.2 claims that the author signature serves to determine whether or
not two widgets came from the same author. Actually, author
signatures from the same identity can only confirm that they come from
the same author; signatures from different identities could still be
from the same author.  Strike or not.



Change made in latest draft


- 4.3 mentions that distributor signatures may have implications in
security policies.  The same isn't said for author signatures.  I
propose either saying this generically, or striking it from 4.3.



Modified to say generically


- 4.3 says no distributor signatures are to be included.  I know
what that's supposed to mean, but think this might cause confusion.  I
suggest to say something along the following lines:


The ds:Signature MUST include ds:References for all resources of the
widget including any author signatures, but excluding any
distributor signatures.  In other words, distributor signatures MUST
countersign author signatures, but MUST NOT countersign other
distributor signatures.





Adopted this text in latest draft


- 5.1 says as required by [XMLDSIG11] -- I propose striking that,
since this specification is making its own, possibly diverging choice
of mandatory to implement algorithms.



Change made in latest draft.



Not so editorial:

- In the example in 1.4, the signature doesn't cover the signature
properties.



Example updated in latest draft to do this.



- 5.2 and 5.3 have an issue about additional algorithms.  I suggest
just being silent about them.



Editors notes removed in latest draft


- The processing model in 6.2 sounds as if it requires implementations
to do a deep-dive into other signature files in order to determine
whether an author signature, if present, is covered by a distributor
signature.  That sounds error-prone.  I wonder if there should be a
simple file name convention to distinguish author and distributor
signatures, to make signature validation independent of parsing more
than one signature resource.



This is taken care of by the file names, clarified in latest draft.



- The processing model in 6.2 does not currently enforce the MUST NOT
on distributor signatures countersigning each other.  I'm having a
hunch that that might get abused by malevolent distributors in order
to interfere with each other; I therefore suggest that distributorr
signatures that countersign each other are a reason for validation
failure.



Added this in latest draft


- In 6.1, I wonder whether it's worthwhile to rebuild the signature
properties piece a bit -- the current description is mildly convoluted
(by describing a tree from the leaves, not the root).



Rewrote this section for clarity



- We're not currently saying how same-document references are done.
The example suggests ID-based references.  That should be said
explicitly -- or else people might start using complex xpointers.  It
might also be useful to recommend the use of random strings for the
IDs.  Corresponding to that, the validation model does not enforce the
position of the signature properties within the overall XML document.
That might lead to interesting differences in implementations that
could cause different implementations to see different things.



This remains to be added.


- In 4.4, we currently perform a dance around X.509 version numbers.
Thinking this through more thoroughly, it worries me that this came
up, for the following reason:  You need an X

Additional Widgets 1.0 Digital Signatures updates

2009-03-02 Thread Frederick Hirsch
I have completed additional changes to the Widgets 1.0 Digital  
Signatures draft:


http://dev.w3.org/2006/waf/widgets-digsig/

Redline of recent changes
http://dev.w3.org/2006/waf/widgets-digsig/Overview-diff.html

Additional changes include
- change stylesheet to be for editors draft
- rewrite namespace section for clarity and to list other namespaces,  
move before notational conventions to remove duplicate material

- update text on certificate chain processing
- remove unnecessary editorial notes
- incorporate editorial changes suggested by Thomas ,
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0548.html

Remaining to do item is to add additional signature properties  
including signature id, expires/timestamp.


regards, Frederick

Frederick Hirsch
Nokia






Re: [widgets] Digsig optimization

2009-02-27 Thread Frederick Hirsch

Marcos

Yes, logically there would be two self contained signatures with  
references to every file in the package.


Again Policy indicates which signatures must be verified. What does  
the packaging spec currently say? To date it has been one distributor  
spec that must be verified. We should be clearer on this - I think  
this goes with the changes we make regarding filename sorting and  
processing.


However if both are to be verified, and if the algorithms are the same  
(which is currently the case given one hash algorithm in widget  
signatures) an implementation could be smart and calculate the  
reference hashes once, eliminating that overhead if it were a concern.


regards, Frederick

Frederick Hirsch
Nokia



On Feb 27, 2009, at 6:48 AM, ext Marcos Caceres wrote:


Hi Frederick, Mark,
I have a concern wrt the author signature. It seems that both the
author signature and the distributor signature need to sign every file
in the package. Does this mean that, to verify a package, you would
need to effectively verify everything in the package twice? or is
verification of the author signature optional?

Kind regards,
Marcos


--
Marcos Caceres
http://datadriven.com.au





Re: Review of latest Widget Signature Draft

2009-02-25 Thread Frederick Hirsch

Thomas

Thanks for the careful review.

comments inline

regards, Frederick

Frederick Hirsch
Nokia



On Feb 25, 2009, at 7:06 AM, ext Thomas Roessler wrote:


In reviewing the latest draft, a couple of comments.

  Widgets 1.0: Digital Signatures
  Editor's Draft 23 February 2009
  http://dev.w3.org/2006/waf/widgets-digsig/

(Mostly) editorial:

- I would propose including a table of namespace prefixes and
namespace URIs, and just saying that the prefixes are editorial
conventions.  The current text in 1.1 and 1.2 is a bit hard to refer
to, and the text in 1.2 sounds like it comes from a time when
namespaces were new.  (It is, since it's lifted straight from XML
Signature 1.0. ;-)

I thought we needed a namespace section so added one. It can use some  
refinement.

I considered adding a list of namespace URIs used, can do that.


- 4.2 claims that the author signature serves to determine whether or
not two widgets came from the same author. Actually, author
signatures from the same identity can only confirm that they come from
the same author; signatures from different identities could still be
from the same author.  Strike or not.


ok




- 4.3 mentions that distributor signatures may have implications in
security policies.  The same isn't said for author signatures.  I
propose either saying this generically, or striking it from 4.3.



I suggest generically in 4.1


- 4.3 says no distributor signatures are to be included.  I know
what that's supposed to mean, but think this might cause confusion.  I
suggest to say something along the following lines:


The ds:Signature MUST include ds:References for all resources of the
widget including any author signatures, but excluding any
distributor signatures.  In other words, distributor signatures MUST
countersign author signatures, but MUST NOT countersign other
distributor signatures.




good, thanks



- 5.1 says as required by [XMLDSIG11] -- I propose striking that,
since this specification is making its own, possibly diverging choice
of mandatory to implement algorithms.




this is an open  issue regarding alignment


Not so editorial:

- In the example in 1.4, the signature doesn't cover the signature
properties.



oops, thanks


- 5.2 and 5.3 have an issue about additional algorithms.  I suggest
just being silent about them.


ok to remove the issues?


- The processing model in 6.2 sounds as if it requires implementations
to do a deep-dive into other signature files in order to determine
whether an author signature, if present, is covered by a distributor
signature.  That sounds error-prone.  I wonder if there should be a
simple file name convention to distinguish author and distributor
signatures, to make signature validation independent of parsing more
than one signature resource.



we have a naming convention listed with the property sections. Should  
mention that here.




- The processing model in 6.2 does not currently enforce the MUST NOT
on distributor signatures countersigning each other.  I'm having a
hunch that that might get abused by malevolent distributors in order
to interfere with each other; I therefore suggest that distributorr
signatures that countersign each other are a reason for validation
failure.



sounds reasonable


- In 6.1, I wonder whether it's worthwhile to rebuild the signature
properties piece a bit -- the current description is mildly convoluted
(by describing a tree from the leaves, not the root).



i think it is complicated , I'll think about better text, suggestions  
welcome.



- We're not currently saying how same-document references are done.
The example suggests ID-based references.  That should be said
explicitly -- or else people might start using complex xpointers.  It
might also be useful to recommend the use of random strings for the
IDs.  Corresponding to that, the validation model does not enforce the
position of the signature properties within the overall XML document.
That might lead to interesting differences in implementations that
could cause different implementations to see different things.



agree, text on references would be useful.


- In 4.4, we currently perform a dance around X.509 version numbers.
Thinking this through more thoroughly, it worries me that this came
up, for the following reason:  You need an X.509 v3 extension to
express the basic constraints on a certificate.  Without the basic
constraints extension, it is impossible to distinguish a CA
certificate from an end entity certificate.  Which in turn suggests
that somebody might have inadvertently generated a CA certificate
instead of an end entity certificate...  In other words, we shouldn't
ever see an end entity certificate that is X.509 v1 or v2.  (And if we
see one, it's a good idea to break it.)



so you suggest simplifying this to v3?


- The current draft has a relatively complex set of interacting
signatures, but does not timestamp these at all.  I'd *really* like us
to mandate a timestamp property on each

Re: ACTION-306: Trust anchors

2009-02-25 Thread Frederick Hirsch

Thanks for the proposal Thomas.

This proposal requiring Basic Path Validation seems to conflict with  
X509Data being optional, the current language that I think we  
discussed during the meeting:


Generation:
5c) The ds:KeyInfo element MAY be included and MAY include  
certificate, CRL and/or OCSP information. If so, it MUST be compliant  
with the[XMLDSIG11] specification. If certificates are used they MUST  
conform to the mandatory certificate format.


Validation:
If a ds:KeyInfo element is present then it MUST conform to the  
[XMLDSIG11]specification. If present then any certificate chain SHOULD  
be validated and any CRL or OCSP information may be used as  
appropriate [RFC5280]..


I suggest we could also adopt your text by changing the final sentence  
above  to


If present then user agents MUST perform Basic Path
Validation [RFC 5280] on the signing key and SHOULD perform revocation  
checking as appropriate.  The set of acceptable

trust anchors, and policy decisions based on the signer's identity
are established through a security-critical out-of-band mechanism.

Question:
Should re require use of X509Data to convey certificates?

I was suggesting not, since this could be conveyed out of band and it  
might not always be appropriate to include in every signature.


Thoughts on this one?

regards, Frederick

Frederick Hirsch
Nokia



On Feb 25, 2009, at 9:23 AM, ext Thomas Roessler wrote:


I propose that we add te following text in the beginning of 6.2:


The validation procedure given in this section describes extensions
to XML Signature Core Validation.  In addition to the steps defined
in these two specifications, user agents MUST perform Basic Path
Validation [RFC 5280] on the signing key.  The set of acceptable
trust anchors, and policy decisions based on the signer's identity
are established through a security-cirtical out-of-band mechanism.


(If somebody can think of something nicer to say, that's fine as
well.  Note that the Basic Path Validation requirement isn't really
new -- it's implicit to our use of X.509, if done properly.
Nevertheless, worth calling out properly.)

--
Thomas Roessler, W3C  t...@w3.org













Updated Widgets 1.0 Signature editors draft

2009-02-24 Thread Frederick Hirsch
I've taken a major pass to reorganize and update the Widgets 1.0  
Signature specification, taking into account the decision to have  
author and distributor roles and to no longer mandate Certificate/OCSP/ 
CRL processing. I also updated and corrected the example and  added a  
section on namespaces as well as other editorial cleanup.


http://dev.w3.org/2006/waf/widgets-digsig/

Please take a look and indicate any other proposed changes.  We can  
probably remove editors notes related to Certificates/OCSP/CRL.


I have not yet added the file processing rules from the packaging  
document since we are discussing this item on the mailing list.


Thanks

regards, Frederick

Frederick Hirsch
Nokia






Re: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging Configuration spec

2009-02-24 Thread Frederick Hirsch
The Widget Signature spec is not an API definition so probably does  
not need to define how signature status information is returned. I  
also agree that it would be incorrect to define in the Widget  
Signature spec whether or not a widget is valid, that is out of scope.  
The spec limits itself to signature validation.  However I would not  
want to be prescriptive in the specification to the level of status  
return codes.


We may want to add a security considerations note along the lines of

As distributor signatures are not included in an overall widget  
signature, it is possible for signatures to be added or removed and  
hence a secure channel for widget delivery  might be preferable.


regards, Frederick

Frederick Hirsch
Nokia



On Feb 6, 2009, at 10:51 AM, ext Priestley, Mark, VF-Group wrote:




Hi Marcos,

More responses to your comments below (marked [mp]). Still need to get
back to you on the access element but I need to think about it a bit
more first.

Thanks,

Mark



--
Step 5 Process the Digital Signatures

We disagree with the stage 2, specifically If the file entry is
deemed by the [Widgets-DigSig] to be an invalid widget, then a widget
user agent must treat this widget as an invalid widget., on two

grounds:


(1) Because one signature is invalid it doesn't mean that all of the
signatures are invalid;
(2) Just because one signature or all signatures are invalid does not
mean that the widget should not be installed, only that it should
_not_ be treated as a signed widget. The security policy of the  
device


might be configured not to install an unsigned widget or a widget  
with



an invalid signature but this should be dependent on the security
policy implemented.


Sorry, I think you might have misunderstood what I was trying to say
here (probably I did not write it clearly enough). This assertion is
here to deal with instances where the digital signature deemed by the
Widgets Dig Sig spec to be somehow fully broken or completely
non-conforming in such a way that all processing must stop. I don't  
yet
know if Widgets Dig Sig will spit out such a result for any digsig  
it is

processing, but it seemed like a good idea to put this in here at the
time.

[mp] No this was pretty much my understanding. Maybe my comment wasn't
clear enough... IMO [Widgets-DigSig] should result in a list of
signature status values. How the widget user agent responds to those
values should be dependent on the security policy of the widget user
agent.

In other words, this is something that is controlled by the Widgets  
Dig

Sig spec. If it turns out that Widgets Dig Sig never results in an
invalid widget situation, then I will take this out. I've created a  
red
note in the spec that says Issue: [Widgets-DigSig] may never  
identify a
widget package as invalid as a reminder that we need to sort this  
out.


[mp] Well I would argue that the [Widgets-DigSig] will never  
identify a

widget package as invalid although it may decide that one or more
signature(s) are invalid. The security policy of the device may decide
that the widget shouldn't be installed based on the result of  
processing

the signature file(s) but that is a different thing. I think that best
we can do in the PC spec is say whether or not the widget is signed
(and even this could be tricky).

FWIW, I think step 5  is buggy and needs a rewrite (I've added another
issue to the spec stating as such). I'll need to work with you to  
fix it

as we progress the Dig Sig spec.

[mp] I'll be available to work on this next week


---
Step 4 Locate Digital Signatures for the Widget

I'm not sure whether the packaging and configuration specification is
the correct place to do this but IMHO there needs to be a statement
that a files with a file name corresponding to the naming convention
for digital signatures are not accessible from the widget once the
widget is installed / instantiated. Failure to impose this  
restriction



will make it possible to include a signature and then reference it
from the signed code, which presents a security hole.


Good point. This seems like something that needs to be in the yet to  
be
written a widget runtime security spec.  I've added an issue note to  
the

spec so we don't forget about this.

Just out of interest, can you present the nature of the security hole?
i.e., once an attacker has the signature, say, via an XSS attack, what
could they do with it?

[mp] The hole is that signature files are excluded from the generation
of the signature values in any other signature files. This means that
if, for example, an attacker added to the widget resource a signature
file containing some malicious content, the malicious content of that
file wouldn't be covered by any of the other signatures but the widget
user agent thinks the entire widget resource is signed. This could
happen regardless of whether or not the signature file was actually
valid

Re: [widgets] Comment on Widgets 1.0: Digital Signatures - the Usage property

2009-02-24 Thread Frederick Hirsch
+1, I think the current Widget Signature draft reflects this point of  
view with the focus on author and distributor signatures and no usage  
or concern with updates specific to Widget Signature. That said, we  
may wish to review the update mechanism from a security point of view,  
but I don't believe that is specific to Widget Signature.


regards, Frederick

Frederick Hirsch
Nokia



On Feb 13, 2009, at 8:26 AM, ext Marcos Caceres wrote:



2009/2/12 Priestley, Mark, VF-Group mark.priest...@vodafone.com:


[mp] As a general comment, I think this is a pretty difficult  
problem to address in a secure manner. IMO the most reliable way of  
authorising an update would be through the use of an update  
signature however, HTTPS provides a workable alternative and plain  
HTTP might be fine in other circumstances. For what it's worth I  
think that the real security issue is how the update is handled but  
this doesn't mean defining an update signature is not useful.




I agree that an update signature would be useful, but would like to
see this just be solved with HTTP and HTTPS for v1. That should cover
most use cases.

Here is my current thinking. Widget version 1 is distributed and
signed. The config looks like this:

widget version=1.0
  update href=https://some.com/update?version=1.0; /
/widget

Because the widget was signed, the update href can be considered
authoritative/trusted. That securely downloads the update description
document:

widgetupdate xmlns=http://www.w3.org/ns/widgets;
 src=https://example.com/myWidget/v1.1b/awesome.wgt;
 version=1.1
 id=http://example.com/myWidget;
 size=1024
 notify=https://example.com/myWidget/updateManager.php?this-v=1.1amp;was-v= 
{version}

 details href=http://a.com/myWidget/1.1/whatsnew;
   We fixed some bugs and improved performance!
 /details
/widgetupdate

The src is downloaded and treated as a normal widget package. If it is
not signed, or the signature cannot be validated, then the usual
warnings are given. If it is signed, then it is processed as normal.

Is there much wrong with the current model?

Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au






Re: Using different widget signature roles

2009-02-19 Thread Frederick Hirsch

Attached is comment I sent on Mark's notes:
---
Mark

yes I think this is appropriate. I would suggest that the processing  
rules for signature verification be uniform, apart from the fact that  
a distributor signature includes author signature Reference.


Then I would argue it is application dependent on what to do with  
regards to failure, since this depends on the bigger widget picture  
(eventually policy but for  now out of scope of the widget signature  
spec).


For simplicity we might remove the 07 from the URIs.

Thanks for writing this down.

By the way I expect XML Signature 1.1 and Properties to be published  
as First Public Working Draft very soon, barring any last minute  
difficulties.


regards, Frederick

Frederick Hirsch
Nokia



On Feb 17, 2009, at 6:01 AM, ext Priestley, Mark, VF-Group wrote:


Hi Frederick,

Just thought I'd try and help with the generation of a proposal on  
the use of widget digital signature properties. Hopefully the below  
is a useful summary of what I think the main requirements are.


It should be possible to create a signature - lets call it the  
author signature - which is used solely for determining who the  
author of a widget is, and as a result whether or not two widgets  
came from the same author. The most reliable way of doing this would  
be if two signatures were created using the same private key but  
this need not be specified.


It should be possible to create a signature - lets call it the  
distributor signature - that is used to determine that a  
particular distributor has distributed this widget. Typically this  
signature might be used to mean something by the consuming widget  
user agent's security policy, such as allocate this widget to trust  
domain X. Again I don't think the use of this signature needs to be  
specified here.


The properties for each signature type are as follows.

Author signature

- Instances allowed: zero or one
- Located: at the root of the widget
- Name: Some reserved file name, eg author-signature .xml
- Generated over: All widget resources excluding distributor  
signatures

- Role property:  eg http://www.w3.org/2009/07/widgets-digsig#role-author

Distributor signature

- Instances allowed: zero or more
- Located: at the root of the widget
- Name: signature *[0-9].xml
- Generated over: All widget resources excluding other distributor  
signatures but including the author signature (if present)

- Role property: eg http://www.w3.org/2009/07/widgets-digsig#role-distributor
In addition to the above, the rules for generation and verification  
of the reference elements would need to be updated to be dependent  
on the role of the signature. I think that's the only significant  
change needed to the current spec, along with changing of the usage  
property to a role property. To make life easy for readers it may  
also be desirable to define different types of signature  
corresponding to the different roles.


Does the above all make sense given last weeks call? Please let me  
know if not.


Regards,

Mark

Mark Priestley

Security Expert
Vodafone Group RD

Mobile: +44 (0)7717512838
E-mail: mark.priest...@vodafone.com

www.betavine.net  - Web
betavine.mobi  - Mobile Web

Vodafone Group Services Limited
Registered Office: Vodafone House, The Connection, Newbury,  
Berkshire RG14 2FN Registered in England No 3802001







  1   2   >