Call for Consensus (CfC) to close the Web Intents Task Force - Deadline October 29, 2015
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
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 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
+1 to FPWD of FindText API > On Oct 7, 2015, at 11:38 AM, Robert Sanderson wrote: > > +1 to FPWD > > On Wed, Oct 7, 2015 at 8:34 AM, Ivan Herman wrote: > I am happy to have this documents published as FPWD. > > Ivan > > > > On 06 Oct 2015, at 22:32 , Frederick Hirsch 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
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
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 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
> 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 > 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 > >
Re: Proposal for a Permissions API
[cross posted to DAP]
I’d like to point out that work such as this would be allowed under the W3C
Device APIs WG charter [1] if this is of interest (not being sure of current
plans):
[[
The scope of this Working Group is this creation of API specifications for a
device’s services that can be exposed to Web applications . Devices in this
context include desktop computers, laptop computers, mobile Internet devices
(MIDs), cellular phones, TVs, cameras and other connected devices.
Priority will be given to developing simple and consensual APIs, leaving more
complex features to future versions.
This Working Group’s deliverables must address issues of accessibility,
internationalization, mobility,security and privacy.
]]
Discussed at 4 Sep teleconference [2]
regards, Frederick
Frederick Hirsch, Nokia
Chair DAP
@fjhirsch
[1] http://www.w3.org/2011/07/DeviceAPICharter
[2] minutes
http://lists.w3.org/Archives/Public/public-device-apis/2014Sep/att-0020/minutes-2014-09-04.html#item07
For Tracker, this completes DAP-ACTION-717
On Sep 2, 2014, at 9:51 AM, Mounir Lamouri wrote:
> TL;DR:
> Permissions API would be a single entry point for a web page to check if
> using API /foo/ would prompt, succeed or fail.
>
> You can find the chromium.org design document in [1].
>
> # Use case #
>
> The APIs on the platform are lacking a way to check whether the user has
> granted them. Except the Notifications API, there is no API that I know
> of that expose such information (arguably, somehow, the Quota API does).
> The platform now has a lot of APIs using permissions which is expressed
> as permission prompts in all browsers. Without the ability for web pages
> to know whether a call will prompt, succeeded or fail beforehand,
> creating user experience on par with native applications is fairly hard.
>
> # Straw man proposal #
>
> This proposal is on purpose minimalistic and only contains features that
> should have straight consensus and strong use cases, the linked document
> [1] contains ideas of optional additions and list of retired ideas.
>
> ```
> /* Note: WebIDL doesn’t allow partial enums so we might need to use a
> DOMString
> * instead. The idea is that new API could extend the enum and add their
> own
> * entry.
> */
> enum PermissionName {
> };
>
> /* Note: the idea is that some APIs would extend this dictionary to add
> some
> * API-specific information like a “DOMString accuracy” for an
> hypothetical
> * geolocation api that would have different accuracy granularity.
> */
> dictionary Permission {
> required PermissionName name;
> };
>
> /* Note: the name doesn’t matter, not exposed. */
> enum PermissionState {
> // If the capability can be used without having to ask the user for a
> yes/no
> // question. In other words, if the developer can’t ask the user in
> advance
> // whether he/she wants the web page to access the feature. A feature
> using a
> // chooser UI is always ‘granted’.
> “granted”,
> // If the capability can’t be used at all and trying it will be a
> no-op.
> “denied”,
> // If trying to use the capability will be followed by a question to
> the user
> // asking whether he/she wants to allow the web page to be granted the
> // access and that question will no longer appear for the subsequent
> calls if
> // it was answered the first time.
> “prompt”
> };
>
> dictionary PermissionStatus : Permission {
> PermissionState status;
> };
>
> /* Note: the promises would be rejected iff the Permission isn’t known
> or
> * misformatted.
> */
> interface PermissionManager {
> Promise has(Permission permission);
> };
>
> [NoInterfaceObject, Exposed=Window,Worker]
> interface NavigatorPermissions {
> readonly attribute PermissionManager permissions;
> };
>
> Navigator implements NavigatorPermissions;
> WorkerNavigator implements NavigatorPermissions;
> ```
>
> The intent behind using dictionaries is to simplify the usage and
> increase flexibility. It would be easy for an API to inherit from
> Permission to define new properties. For example, a Bluetooth API could
> have different permissions for different devices or a Geolocation API
> could have different level of accuracies. See [1] for more details.
>
> WDYT?
>
> [1]
> https://docs.google.com/a/chromium.org/document/d/12xnZ_8P6rTpcGxBHiDPPCe7AUyCar-ndg8lh2KwMYkM/preview
>
> -- Mounir
>
Re: [ambient light events LC] Feedback ( LC-2736)
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
Re: Re: Indicating certificate order in XML Dig Sig ( LC-2504)
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
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 th
Re: Minor DigSig feedback
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
Re: Minor DigSig feedback
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
Review of update to Widget Signature
Marcos Thanks for taking the time to propose a revision to Widget Signature based on your experience working on the test cases. This looks like a very good improvement in readability and clarity of conformance requirements. From a technical point of view it looks to be fundamentally the same to me, with a couple of changes noted here, though I may have missed something in the large number of changes. Here are a few questions: 1. You removed requirement that signature be at root of widget package? This seems an important requirement here for knowing which signatures are valid (even if in packaging and config) 2. The following signature validation rule in section 6 seems incorrect since it does not account for author signatures: "A validator MUST ignore any file entry whose file name does not conform to the naming convention for a distributor signature." Change to: "A validator MUST ignore any file entry whose file name does not conform to the naming convention for an author or distributor signature." 3. The abstract was revised to generalize beyond widgets, which I don't understand given that the entire specification is widget specific. What did you have in mind. allow a packaged Web application such as widgets 4. Typo section 8, in note: Signign Regarding process, some of the changes and deletions remove material that was added through decision of the WG earlier - although to me it appears to be an improvement. So we need WG to agree to accept changes. Given that the conformance targets have been redefined, that normative language has been removed or changed, is another full Last Call (3 weeks) be required? Maybe, but I'm not sure since apart from the questions above it looks like the same net effect on implementations. Thanks regards, Frederick Frederick Hirsch Nokia
Re: Reminder: RfC: LCWD of Digital Signatures for Widgets; deadline 6 May 2010
Marcos Given the massive number of changes, it would help if you could please summarize: 1. which original normative statement no longer are applicable (ie despite rewording, which no longer need be met) 2. which new normative statements you have added Thanks regards, Frederick Frederick Hirsch Nokia On Apr 29, 2010, at 12:17 PM, ext Marcos Caceres wrote: I have fund a number of issues with the dig sig spec: 1. The conformance model is all screwy: it mixes conformance criteria for too many products (including ones on which were it makes no sense, like signature documents). The conformance criteria makes the spec really hard to write test for. Only two classes of products should be allowed to conform: signers and validators. 2. The spec requires zip-relative-paths to be URL encoded during signing. I think this is an oversight, specially because during signature validation it does not say that the paths be decoded. URL Encoded of paths should be removed from the spec, IMO. Zip-relative paths are supposed to be URI safe, hence should not require URL Encoding (and when they violate URI's path rule, they should be treated as invalid widgets anyway as per the P&C spec). 3. The document is full of editorial redundancies (about 100+). It is also badly structured, with behavioral conformance criteria mixed in with definitions and support requirements (making the spec really hard to follow). In the interest of saving time, I have created a new version of the spec that addresses all the issues above: http://dev.w3.org/2006/waf/widgets-digsig/ To compare my draft with latest WG endorsed editorial draft: http://tinyurl.com/26bxclc In addition, the new draft has the advantage of being fully testable and written using the method defined in [1] (meaning we can plug in WebApps test suite creation infrastructure, which assures that all conformance requirements in the spec will get tested!). I encourage the working group to adopt my modified version once it has been reviewed. Aside from the URL Encoding thing, the modified version does not change the behavior existing implementations: it just makes it much more clear what each kind of product needs to do to conform. Kind regards, Marcos [1] http://www.w3.org/TR/test-methodology/ On Thu, Apr 29, 2010 at 2:21 PM, Arthur Barstow wrote: Reminder: May 6 is the deadline for comments re the April 15 LCWD of the Digital Signatures for Widgets spec: http://www.w3.org/TR/2010/WD-widgets-digsig-20100415/ Please send comments to public-weba...@w3.org. Begin forwarded message: From: "Barstow Art (Nokia-CIC/Boston)" Date: April 16, 2010 5:25:27 PM EDT To: public-webapps , "public-xml...@w3.org" Subject: Request for Comments: LCWD of Digital Signatures for Widgets; deadline 6 May 2010 Archived-At: <http://www.w3.org/mid/8679d7d8-a881-4fd2-b1a3-693507fb6...@nokia.com > On April 15 the WebApps WG published a new LCWD of the Digital Signatures for Widgets spec (formerly titled Widgets 1.0: Digital Signatures): http://www.w3.org/TR/2010/WD-widgets-digsig-20100415/ This spec was last published as a CR [CR]. The new LC includes a fix to a bug [Bug] that was identified during the implementation of the spec's June 2009 Candidate. The deadline for this LC's comments is 6 May 2010. We will explicitly ask the XML Security WG to review this LC and comments from others are welcome. -Art Barstow [Bug] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/ 0054.html [CR] http://www.w3.org/TR/2009/CR-widgets-digsig-20090625/ -- Marcos Caceres http://datadriven.com.au
Updated Digital Signatures for Widgets Editors Draft
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)
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 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? --- original Nachricht Ende
Re: Widget Signature modification proposal (revised)
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 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? --- original Nachricht Ende
Re: Widget Signature modification proposal (revised)
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?
Widget Signature modification proposal (revised)
Below is revised widget signature modification proposal that includes
limiting Reference canonicalization to same-document references and
allows for verification backward compatibility, while also retaining
the restriction on Transforms for non same-document references.
Thanks for the review comments.
regards, Frederick
Frederick Hirsch
Nokia
- start -
(A) Revised Proposal (correction for limiting canonicalization of XML
to same document references and backward compatibility)
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 (editors draft , http://dev.w3.org/2006/waf/widgets-digsig/
):
(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 same-document 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. A ds:Reference that is not to same-document XML content
MUST NOT have any ds:Transform elements.
An implementation SHOULD be able to process a ds:Reference to same-
document XML content when that ds:Reference does not have
ds:Transform, for backward compatibility. In this case the default
canonicalization algorithm Canonical XML 1.0 will be used, as
specified in XML Signature 1.1.
Note: The relevant section in XML Signature 1.1 is section 4.4.3.2,
"The Reference Processing Model". This section states "Unless the URI-
Reference is such a 'same-document' reference , the result of
dereferencing the URI-Reference MUST be an octet stream. In
particular, an XML document identified by URI is not parsed by the
signature application unless the URI is a same-document reference or
unless a transform that requires XML parsing is applied." In the same
section the specification notes, "In this specification, a 'same-
document' reference is defined as a URI-Reference that consists of a
hash sign ('#') followed by a fragment or alternatively consists of an
empty URI...".
Sectjon 7.2, add
Every ds:Reference to same-document 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 will require a ds:Transform element to specify
canonicalization method. A reference to config.xml will not, however,
since it is not a same-document reference.
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. A validator SHOULD be able to process a ds:Reference to same-
document XML content when that ds:Reference does not have
ds:Transform, for backward compatibility
(2) Non-normative change:
1.4 Example, (formatting appropriately and renumbering lines)
Change
to
http://www.w3.org/2006/12/xml-
c14n11"/>
--
(B) Clarification
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 same-document XML
referenced using a ds:Reference, for example the ds:Object element
in the Widget Signature case.
In this 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 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 Referenc
Re: Widget Signature Issue and Proposed Resolution
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
to
http://www.w3.org/2006/12/xml-
c14n11"/>
Change
to
http://www.w3.org/2006/12/xml-
c14n11"/>
--
(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] http://www.w3.org/TR/2000/REC-xhtml1-2126/";>
[s06]
[s07] http://www.w3.org/2006/12/xml-c14n11"/>
[s08]
[s09] http://www.w3.org/2001/04/
xmlenc#sha256"/>
[s10] dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK...
[s11]
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.
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 fr
Widget Signature Issue and Proposed Resolution
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 http://www.w3.org/2006/12/xml- c14n11"/> as the first child element of the following Reference elements in the example 1.4 (formatting appropriately and renumbering lines): -- 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
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
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)" > Date: January 8, 2010 8:39:27 AM EST To: XMLSec WG Public List Cc: "Hirsch Frederick (Nokia-CIC/Boston)" 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
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)"
Date: January 7, 2010 1:31:20 PM EST
To: ext Scott Cantor
Cc: "Hirsch Frederick (Nokia-CIC/Boston)"
, XMLSec WG Public List , "Barstow Art (Nokia-CIC/Boston)"
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
to
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
Re: [WARP4U] WARP with UPnP, was: RE: [widgets] Draft Minutes for 19 November 2009 Voice Conference
+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 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: Renaming WebDatabase and WebSimpleDB
how about "Indexed Sequential Web Database", losing the acronym, even if familiar to those who work with databases? (not web-indexed, however...) regards, Frederick Frederick Hirsch Nokia On Nov 30, 2009, at 8:11 PM, ext Michael Nordman wrote: Web-Indexed-Storage On Mon, Nov 30, 2009 at 4:52 PM, Nikunj R. Mehta > wrote: On Nov 30, 2009, at 3:14 PM, Michael(tm) Smith wrote: Jeremy Orlow , 2009-11-30 14:46 -0800: I agree with Mike, but I'd also note that "Web Key-Value Database" could easily be confused with WebStorage given that it also uses a Key-Value model. True but we know the distinction is that Web Storage does not use a database. Do we make naming decisions considering just us WG members as its audience or that of the general public? I think the general public is well within its rights to treat Web Storage as a persistence technology that seems to be like "Key-Value" database. I want to emphasize here that I think "key-value" in the title misses the subtlety - it is the use of index sequential access that is at the heart of WebSimpleDB, and not key-value storage. Nikunj http://o-micron.blogspot.com
Re: Security evaluation of an example DAP policy
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: func="equal"/> match="weather.example.com" func="equal"/> internationalresource-match> //this seems not needed nationalresource-match> 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 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 a
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 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 > 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: /.+/match> 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 wrote: Hi Adam, I think that /(C|c):\\(.+)\\(.+)/ should be /(C|c):\\([^\\]+)\\. +/ 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
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: /.+/match> 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 wrote: Hi Adam, I think that /(C|c):\\(.+)\\(.+)/ should be /(C|c):\\([^\\]+)\\. +/ 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: DAP and security (was: Rename "File API" to "FileReader API"?)
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
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”?
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 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
Re: Proposed additional topic for joint DAP/WebApps Widgets F2F session
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
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
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
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 element in the example provided in http://www.w3.org/TR/widgets-digsig/ section 1.4 is not correct in that the occurs before the . 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 . 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 in the wrong order. Kind regards, Christian
Re: HTML extension for system idle detection.
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 wrote: On Thu, 17 Sep 2009 00:05:58 +0200, 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. 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 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)
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 P&C) [4], defines a method to express the dependency of the widget on a resource/component, namely the element. P&C in [5] - the definition of the 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." P&C [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 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 and 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 sec
Re: [cors] Additional Comments on 17 March 2009 cors draft
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 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 or 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/
Re: [cors] Additional Comments on 17 March 2009 cors draft
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 req
[cors] Comments on 17 March 2009
ction 1 Replace "User agents are enabled to discover whether a cross-origin resource is prepared to accept requests using a non-GET method from a given origin." with "User agents are enabled via 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: [widgets] dig sig RelaxNG schema
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
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-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." 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 P&C. ---[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
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-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." 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 P&C. ---[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 stat
Re: Widgets 1.0: Digital Signatures
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 http://www.w3.org/2006/12/xml-c14n11"/> 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: ... - 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: Reminder: Comments for LCWD of Widgets 1.0: Digital Signatures due June 1
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. ... ... ... 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 speci
Re: [widgets] dig sig and requirements ready for pub!
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,
[widgets-digsig] minor editorial update
Updated widget signature with minor editorial update in algorithms section. In previous text: "Note that this 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). 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. " Removed "Note that" and called out "Although" etc as a note. http://dev.w3.org/2006/waf/widgets-digsig/#algorithms regards, Frederick Frederick Hirsch Nokia
Re: [widgets] dig sig and requirements ready for pub!
I was aware of what you quoted Marcos, but it was implicit. If it is ok, then I'm not sure why we've been having this email thread... regards, Frederick Frederick Hirsch Nokia On May 5, 2009, at 6:38 AM, ext Marcos Caceres wrote: On Tue, May 5, 2009 at 12:33 PM, Arthur Barstow 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. that is already in the spec: "Each widget signature MUST contain a dsp:Identifier signature properties element compliant with XML Signature Properties [XMLDSIG-Properties] and this specification." Kai - please let us know if Frederick's proposal is acceptable. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] dig sig and requirements ready for pub!
The spec is more than a UA spec, it also describes signature format which affects parties other than the UA (e.g. audit etc) regards, Frederick Frederick Hirsch Nokia On May 4, 2009, at 12:42 PM, ext Marcos Caceres wrote: On Mon, May 4, 2009 at 4:13 PM, Frederick Hirsch wrote: The Identifier property is useful for audit and management in the backend. I believe this should remain in the specification and should remain a normative section, agreeing with Thomas note in the chat. It was added based on requirements from WG members. I understand the use case, but i still don't understand why we are mandating the use of the dsp:Identifier if it's not going to be used by the UA? If a signer wants to use dsp:Identifier for whatever reason, then are free to do so by using the Signature Properties spec. Putting something in the spec that does not do anything doesn't make sense to me. Thomas mentioned in the chat the means to obtain unique values, e.g. large random number, serial number + DNS etc, but I think this can be out of scope of the spec. Currently the specification states Each widget signature MUST contain a dsp:Identifier signature properties element compliant with XML Signature Properties [XMLDSIG- Properties] and this specification. We can add, "A signer MUST place the dsp:Identifier signature property into the signature when generating the signature." if necessary. regards, Frederick Frederick Hirsch Nokia On May 4, 2009, at 9:38 AM, Barstow Art (Nokia-CIC/Boston) wrote: Kai - this is a good question. Frederick - we (MC, TLR and I) talked about this in IRC today. Please take a look and let us know your thoughts: <http://krijnhoetmer.nl/irc-logs/webapps/20090504> -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, -- Marcos Caceres http://datadriven.com.au
Re: [widgets] dig sig and requirements ready for pub!
The Identifier property is useful for audit and management in the backend. I believe this should remain in the specification and should remain a normative section, agreeing with Thomas note in the chat. It was added based on requirements from WG members. Thomas mentioned in the chat the means to obtain unique values, e.g. large random number, serial number + DNS etc, but I think this can be out of scope of the spec. Currently the specification states Each widget signature MUST contain a dsp:Identifier signature properties element compliant with XML Signature Properties [XMLDSIG- Properties] and this specification. We can add, "A signer MUST place the dsp:Identifier signature property into the signature when generating the signature." if necessary. regards, Frederick Frederick Hirsch Nokia On May 4, 2009, at 9:38 AM, Barstow Art (Nokia-CIC/Boston) wrote: Kai - this is a good question. Frederick - we (MC, TLR and I) talked about this in IRC today. Please take a look and let us know your thoughts: <http://krijnhoetmer.nl/irc-logs/webapps/20090504> -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,
[widget-digsig] XML Signature Properties published
from the w3c home page: XML Signature Properties Draft Published 2009-04-30: The XML Security Working Group [1] has published a Working Draft of XML Signature Properties [2]. This document 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. Learn more about the Security Activity [3] . (Permalink [4] ) [1] http://www.w3.org/2008/xmlsec/ [2] http://www.w3.org/TR/2009/WD-xmldsig-properties-20090430/ [3] http://www.w3.org/Security/ [4] http://www.w3.org/News/2009#item63 regards, Frederick Frederick Hirsch Nokia
[widget-digsig] Update to widget signature
I have updated Widget Signature [1] as follows: 1. Editorial changes as noted in email http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0401.html 2. Additional formatting change to format dsp:Role as code in two places where added in recent change. 3. Updated Packaging and Config reference to have date of today, 29 April 2009. Show url in body of reference. 4 Change SHOULD NOT to MUST NOT, resulting in following text: The signer MUST NOT generate signatures using key lengths of less than 2048 bits unless the life time of the signature is less than one year. 5. Updated status of the document section. regards, Frederick Frederick Hirsch Nokia [1] http://dev.w3.org/2006/waf/widgets-digsig/
Re: [widgets] Dig Sig review in prep for LC
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: [[ Note to Last Call Reviewers This section is non-normative. The 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, it is extremely likely that this document has been superseded. Instead of reviewing this published draft, please review the http://dev.w3.org/2006/waf/widgets-digsig/";>latest editor's draft and make sure to cite the date of that draft in the feedback sent to the Web Apps Working Group's public mailing list mailto:public-webapps@w3.org";>public-Webapps@w3.org. Please also be sure to check the mailing list http://lists.w3.org/Archives/Public/public-webapps/";>archive to see if any issues uncovered have already been addressed. To help with cataloging issues, prefix emails to the mailing list with the string [widgets]. Any and all feedback is welcomed. ]] 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" -> "Numerical order 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
Re: [widgets] Dig Sig review in prep for LC
+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: [[ Note to Last Call Reviewers This section is non-normative. The 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, it is extremely likely that this document has been superseded. Instead of reviewing this published draft, please review the http://dev.w3.org/2006/waf/widgets- digsig/">latest editor's draft and make sure to cite the date of that draft in the feedback sent to the Web Apps Working Group's public mailing list mailto:public-webapps@w3.org";>public-Webapps@w3.org. Please also be sure to check the mailing list http://lists.w3.org/Archives/Public/public-webapps/";>archive to see if any issues uncovered have already been addressed. To help with cataloging issues, prefix emails to the mailing list with the string [widgets]. Any and all feedback is welcomed. ]] Well... Doesn't "Last Call" suggest that you're actually beyond the phase of rapid changes?
Updates to Widget Signature
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
Proposal to update signature text in Packaging and Config, remove from Widget Signature
I suggest the following remove from widgets signature: http://dev.w3.org/2006/waf/widgets-digsig/#use "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." change packaging and config, http://dev.w3.org/2006/waf/widgets/#digital-signatures replace 2nd paragraph which is currently "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." with this "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. 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 is to adopt Art's simplified proposal By the way I really think P&C should use uppercase MUSTs etc. regards, Frederick Frederick Hirsch Nokia
Re: [widget-digsig] Updated Widget Signature editors draft
how about this: Note that with an optional algorithm interoperability may not always be possible if user agents have not implemented it. Implementation of this algorithm is encouraged since it can become mandatory in a subsequent release of this specification, and this may become necessary if a security issue is discovered with the currently required algorithm. regards, Frederick Frederick Hirsch Nokia On Apr 24, 2009, at 5:20 AM, ext Priestley, Mark, VF-Group wrote: "I would like to see some text cautioning authors not to rely on this algorithm, since it is optional in user agents." Agreed - in fact I think a general statement about use of optional algorithms would be beneficial -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org ] On Behalf Of Marcos Caceres Sent: 24 April 2009 09:46 To: Frederick Hirsch Cc: Web Applications Working Group WG Subject: Re: [widget-digsig] Updated Widget Signature editors draft Hi Frederick, Thanks for updating the spec! comment below. On Fri, Apr 24, 2009 at 3:14 AM, Frederick Hirsch > wrote: I have updated the Widget Signature draft to reflect decisions on today's call, as follows: Added ECDSAwithSHA256 as SHOULD signature algorithm I would like to see some text cautioning authors not to rely on this algorithm, since it is optional in user agents. 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 -- Marcos Caceres http://datadriven.com.au
[widget-digsig] Updated Widget Signature editors draft
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: [widget-digsig] Pls review: Additional considerations on elliptic curve algorithms to consider
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 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
Re: [widgets] New WD of Widgets 1.0: Digital Signatures spec published on March 31
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 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 of the widget, producing [XMLDSIG11] 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 personal
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 > 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 of the widget, producing [XMLDSIG11] 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
[widget-digsig] updated Widget Signature editors draft
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
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 P&C 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 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 of the widget, producing [XMLDSIG11] 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
Re: [widgets] Agenda for 23 April 2009 Voice Conference
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 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] Agenda for 23 April 2009 Voice Conference
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. P&C spec
<http://dev.w3.org/2006/waf/widgets/>
a. Simple approach for ; 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: [widget] [widget-digsig] Comment on WD of Widgets 1.0: Digital Signatures - use of Created property
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: [widgets] New WD of Widgets 1.0: Digital Signatures spec published on March 31
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 of the widget, producing [XMLDSIG11] 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 - "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? - "physical file" -> file ? Marcos? ok with file personally - "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" - "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? - 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 P&C question. Marcos? - "(i.e., a third party that is distributing the widget on behalf of the author)." - in some cases the author may also be (one of) the distributor(s). suggest changing "i.e." to "e.g." I think i.e. is correct. In the case you suggest they just happen to be the same entity fulfilling two roles. - 3 "As well as sections marked as non-normative, examples and notes in this specification are non-normative. Everything else in this specification is normative. The security considerations section is non-normative." Suggest change to the following for readability: "As well as sections marked as non-normative, the examples and notes, and security considerations in this specification are non-normative. Everything else in this specification is normative." yes, better. - 4 "This section defines how to locate digital signatures in a widget package for processing. An implementation MUST achieve the same result as the following algorithm used to locate digital signatures in a widget package:" In the sentence above, change "digital signatures" to "signature files" (in both cases) ok - "This MAY be determined by the security policy used by the user agent." Can we say will or, better yet, SHOULD or MUST? Otherwise, what do we mean when we say MAY? Who (what) else may enforce security policy? we mean may since security policy is out of scope. How can we mandate what is no
Proposal for ISSUE-83
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 P&C 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: [widgets] Jar signing vs. XML signatures
I believe Thomas gave technical reasons, that I agree with, why it is unnecessary to do this rework. We are not using the transform chain where complexity and performance issues occur, and the schema concerns as far as I can tell are a non- issue as Thomas noted. What does " rely on XSD" as an issue mean, when we do not require schema validation? Is it a problem to use schema to express types (e.g. anyURI to mean put a URI as an attribute value etc) XML Security is also an existing solution since 2002 and is profiled down in this case. There are already XML implementations. So apart from personal preference I do not see why a change is needed. regards, Frederick Frederick Hirsch Nokia On Apr 15, 2009, at 3:00 PM, ext Jonas Sicking wrote: On Tue, Apr 14, 2009 at 4:38 AM, Marcos Caceres wrote: Although I agree that it was probably a short-sightedness mistake on our part to not have looked at JAR signing at the start of this process, I think it is too late for you to ask us to dump over a year worth of work on this spec - especially as we are about to go to Last Call and have significant industry support (BONDI) for using XML Signatures. Although I also agree that there are issues with canonicalization, I find it hard to believe that JAR signatures are not without their own problems. I think it would be more productive to help us address the issues that you mentioned, instead of asking us to dump everything and start again. This is a really bad reason not to rework the widget signing spec. I really hope that there are other more technical reasons that is keeping us from reworking the spec. As an example the CORS spec had been in the works for the better part of two years when we started making some serious changes to it based technical input from reviews. In the end we ended up adding and removing so many things that nothing from the original spec was left in. And we were all better off because of it. Signing of archives is something that has been solved for a long time at a significantly lower complexity than the current spec. So it really shouldn't take that much effort to rework the spec by taking input from existing solutions. I'm not suggesting scrapping the spec and starting over. However do take a look at even the bigger technical solutions in the spec and see if they can be improved. Given W3Cs philosophy of what is allowed to be standardized under W3Cs roof, the fact that the spec reuses W3C specs carries very little weight with me. For example the fact that it relies on XSD means that it's a non-started for me. I'm also not sure why we need to rely on canonicalizing XML files. / Jonas
Re: ISSUE-83 (digsig should not be read at runtime): Instantiated widget should not be able to read digital signature [Widgets]
+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 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 P&C 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 P&C 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 P&C 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
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: ISSUE-83 (digsig should not be read at runtime): Instantiated widget should not be able to read digital signature [Widgets]
I think we may need to be more precise since in this context a "signature" means an xml signature structure. An XML Signature is an XML structure that includes a signature value but may also include other information such as properties recorded in the ds:Object element within the ds:Signature element. Thus access to property values may be an important reason for access. If KeyInfo includes CRL or OCSP information that may also be important. If we are concerned about integrity of the signature we should note that all important aspects should be included in the cryptographic signature value. Maybe we should rely on the security of the key and leave it at that? Apart from the risk of addition or removal of signatures noted in the security considerations section, it appears that cryptographically the signature should be protected as long as the key is secure (and of course there are no attacks available against the algorithms and so on). regards, Frederick Frederick Hirsch Nokia On Apr 2, 2009, at 5:20 PM, ext Priestley, Mark, VF-Group wrote: Hi Art, All, I tracked down my original explanation with subsequent qualification [1]. The problem in a nutshell is that by allowing multiple signatures, which is something we want to do, we create a situation in which not all of a signed widget's files are covered by the signature. This is fine if the parts that aren't signed can not be "used" by the widget. My suggestion was that the contents of the signature files were simply made unavailable to the widget at runtime. To me this seemed like a straight forward solution to mitigating the threat. However I understand that there have been comments that there may be cases in which a widget might want to read the contents of it's own signature files. So while I don't want to divert attention away from more important discussions, before we close this issue I would like to hear what the requirement is for a widget to access it's own signatures? What are the use cases. For example, I would like to understand whether it would be enough for those use cases to only allow the widget access valid signatures? Thanks, Mark [1] http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/ 0466.html -Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: 05 March 2009 17:37 To: Priestley, Mark, VF-Group Cc: Web Applications Working Group WG Subject: Re: ISSUE-83 (digsig should not be read at runtime): Instantiated widget should not be able to read digital signature [Widgets] Mark - during the March 5 widgets voice conference we discussed this issue that you raised [1]. Marcos created this issue from the following e-mail thread: <http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/ 0521.html> A couple of the people on the call asked for some more information, in particular the specific threat scenario. We would appreciate it if you would please elaborate on your concern. -Regards, Art Barstow On Feb 22, 2009, at 11:53 AM, ext Web Applications Working Group Issue Tracker wrote: ISSUE-83 (digsig should not be read at runtime): Instantiated widget should not be able to read digital signature [Widgets] http://www.w3.org/2008/webapps/track/issues/83 Raised by: Mark Priestley On product: Widgets Need to mention somewhere that the digital signature must not be accessible by the start file once the widget is running.
Re: [widget-digsig] Updated Editors Draft of Widget Signature
I ran this through the W3C validator and fixed validation errors and warnings, it now validates cleanly. regards, Frederick Frederick Hirsch Nokia On Mar 27, 2009, at 3:02 PM, Hirsch Frederick (Nokia-CIC/Boston) wrote: 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 Numerical order is the order based on the numeric portion of the signature file name. Thus the highest numbered distributor signature would be validated first. to section 4, #6 --- replace The ordering by file name 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 vs. 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] These signatures MUST be sorted numerically based on the numeric portion of the name. 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.
[widget-digsig] Updated Editors Draft of Widget Signature
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 Numerical order is the order based on the numeric portion of the signature file name. Thus the highest numbered distributor signature would be validated first. to section 4, #6 --- replace The ordering by file name 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 vs. > 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] These signatures MUST be sorted numerically based on the numeric portion of the name. 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: [BONDI Architecture & Security] [widgets] new digsig draft
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.
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: 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: [widgets] Author
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, further comments
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 P&C 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 processin
Re: [BONDI Architecture & Security] [widgets] new digsig draft
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 P&C. 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 P&C? 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 P&C (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 vs. 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 whe
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 P&C 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 P&C. 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
Re: AW: Re: [BONDI Architecture & Security] [widgets] new digsig draft
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 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 An: ext Priestley, Mark, VF-Group Cc: Frederick Hirsch ; Hillebrand, Rainer; marc...@opera.com ; pa...@aplix.co.jp ; public-webapps@w3.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 by someone who had access to that key. That would normally mean the same entity (author, company, whatever). If the owner of that ke
Re: AW: Re: [BONDI Architecture & Security] [widgets] new digsig draft
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 An: Paddy Byers Cc: Hillebrand, Rainer; WebApps WG ; 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 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
(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 An: Hillebrand, Rainer Cc: WebApps WG ; 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 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": T
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 by someone who had access to that key. That would normally mean the same entity (author, company, whatever). If the owner of that key shares it with others then obviously this no longer is true. However, this is the choice of the owner of the key - normally you would not share your private key! One additional point to add. We also define a distributor signature. Distributor signatures cover the author signature. As such a distributor signature may (depending on other factors) be making an implicit statement that the distributor believes the owner of the author signature to be the widget's author. Any clearer? Thanks, Mark [1] http://dev.w3.org/2006/waf/widgets-digsig/Overview.html -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Hillebrand, Rainer Sent: 26 March 2009 16:20 To: marc...@opera.com; pa...@aplix.co.jp Cc: public-webapps@w3.org; otsi-arch-...@omtplists.org Subject: AW: Re: [BONDI Architecture & Security] [widgets] new digsig draft 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 An: Paddy Byers Cc: Hillebrand, Rainer; WebApps WG ; 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 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
additional widgets signature fix
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: [widgets] new digsig draft
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 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 P&C. 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
Re: [widgets] new digsig draft
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" 3. Section 4, #6, change "Security" to "security" 4. Section 5.3.1, include blank line between bullet with DIGIT and next bullet 5. Section 6, replace ".." with "." in editorial note 6. Section 6.1, change "DSAwithSHA" to "DSAwithSHA1" 7. Section 7.2, change link to be from "signature file", it is currently broken 8. End of section 8, remove example from sentence, change "For example, end-users" to "End-users" and combine with previous paragraph. 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. --- 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). 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? The other changes looked good, thanks for improving the draft. regards, Frederick Frederick Hirsch Nokia On Mar 25, 2009, at 11:41 AM, ext Marcos Caceres wrote: Hi All, A new Working Draft of the Widgets 1.0: Dig Sig is ready to be published [1]. I've put the date of publication as the 31 of March, with the hope the W3C will publish it some time next week. If possible, the editors would be greatly appreciate if someone could check over it before it gets published. Please send any feedback you might have by the end of the week. Kind regards, Marcos [1] http://dev.w3.org/2006/waf/widgets-digsig/ -- Marcos Caceres http://datadriven.com.au
Re: [widget-digsig] Editorial update of Widget Signature
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] Editorial update of Widget Signature
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] changed widget signature files processing rule in section 4
I think the current text is clearer since it make clear which direction to process the list, which would be ambiguous otherwise. regards, Frederick Frederick Hirsch Nokia On Mar 19, 2009, at 9:40 AM, ext Priestley, Mark, VF-Group wrote: Hi Frederick, Small comment. I would change the sentence: "Process the digital signatures in the signatures list in descending order, with distributor signatures first." to "Process the digital signatures in the signatures list in list order starting with the first file-entry." or something similar (They should already be in descending order, with distributor signatures first, as list has been sorted in previous steps.) Thanks, Mark From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org ] On Behalf Of Frederick Hirsch Sent: 18 March 2009 21:07 To: WebApps WG Cc: Frederick Hirsch Subject: [widget-digsig] changed widget signature files processing rule in section 4 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: [widget-digsig] proposed change to 7.1, common constraints, for algorithms
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 _
Re: [widget-digsig] Editors note to be added to widget signature
revised to be as follows, now that I look at it more closely: Note: The Web Applications WG is seeking feedback on required algorithms for widget signatures, in particular which algorithms should be required in addition to RSAwithSHA256. The WG has not yet agreed on final set of required algorithms. This Widget Signature specification relies on XML SIgnature 1.1 which introduces new and stronger algorithms to XML Signature. 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 also requesting feedback on the FPWD of XML SIgnature 1.1. regards, Frederick Frederick Hirsch Nokia On Mar 19, 2009, at 9:48 AM, Hirsch Frederick (Nokia-CIC/Boston) wrote: 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
[widget-digsig] Editors note to be added to widget signature
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: [widgets] Minutes from 25 February 2009 Widgets F2F Meeting
Please take a look at the FPWD of XML Signature 1.1 which describes the use of Elliptic Curve algorithms in the context of XML Signature: http://www.w3.org/TR/2009/WD-xmldsig-core1-20090226/ Ideally widgets signature should just reference XML Signature 1.1 algorithms. I also note that the XML Security WG continues to refine XML Signature 1.1 and is looking for feedback. Thanks regards, Frederick Frederick Hirsch Nokia On Mar 19, 2009, at 6:17 AM, ext Hillebrand, Rainer wrote: Dear Art, May I give feedback on an old action item regarding the preference for ECDSA vs. DSA. I hope that T-Mobile's position statement is not too late. T-Mobile favors ECDSA. DSA has no advantage regarding speed and memory consumption against the classic RSA. ECDSA improves the security level. Please note that ECDSA supports prime field cases and binary field cases. Especially the binary field cases are covered by patents. Due to the fact that different parameters for the elliptic curves can be used or are standardized, these parameters are relevant too. The NIST recommends fifteen elliptic curves (five prime curves and ten binary curves, see also http://en.wikipedia.org/wiki/Elliptic_curve_cryptography) . The so-called Brainpool curves are preferred in Germany (see also http://www.ietf.org/internet-drafts/draft-lochter-pkix-brainpool-ecc-03.txt) . 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: [widgets] Agenda for 19 March 2009 Voice Conference
I include some updates and questions inline on Widget Signature with
pointers to mail archive.
regards, Frederick
Frederick Hirsch
Nokia
On Mar 18, 2009, at 9:41 AM, Barstow Art (Nokia-CIC/Boston) wrote:
Below is the draft agenda for the March 19 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: *** STILL 1-HOUR EARLIER FOR non-US PARTICIPANTS ***
Time: 22:00 Tokyo; 15:00 Helsinki; 14:00 Paris; 13:00 London;
09:00 Boston; 06:00 Seattle
Duration = 60 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. DigSig spec:
Widgets DigSig: <http://dev.w3.org/2006/waf/widgets-digsig/>
XML Sig Props: <http://www.w3.org/2008/xmlsec/Drafts/xmldsig-
properties/Overview.html>
a. Open issues Frederick identified in:
<http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/
0764.html>
b. Remove "Only the first distributor signature MUST be processed."?
Changed this in editors draft, Section 4, see
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0830.html
WG agree with the change as made?
c. Remove DSAwithSHA1 requirement? Status of requirement R47 (Section
2)?
Still open
d. Suggest removing the restatement of algorithm requirements in
section 7.1, specifically remove #5a and #5b.
Proposal on list, see
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0827.html
If agreed would like to add before publishing.
additional items not in agenda:
e. reference widgets packaging zip relative path
See message from Marcos
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0787.html
also see for change made to editors draft, including additional
clarification (constraining to these two references types only)
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0829.html
Does WG agree to this change?
f. changed "widget user agent" to "user agent" throughout
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/
0791.html (Marcos)
g. revised security considerations text per thomas and mark
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0786.html
h. Changed "Nokia, Inc" to "Nokia"
earlier changes, including ABNF
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0764.html
i. Any other changes needed?
e. Proposal to publish new Working Draft
4. P&C spec: status of P&C LC comment handling; next steps
<http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-
widgets-20081222/>
5. P&C spec: should the config file be mandatory? Complete discussion
started on March 12; see Marcos' proposal:
<http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/
0679.html>
<http://www.w3.org/2009/03/12-wam-minutes.html#item07>
6. Window Modes spec: status and next steps
7. A&E spec: status and next steps
[widget-digsig] changed widget signature files processing rule in section 4
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)?
[widgets-digsig] Updated 5.1 with revised Reference constraint text
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] proposed change to 7.1, common constraints, for algorithms
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?
[widget-digsig] zip relative path update
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 P&C 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 P&C [1] and see if it is usable in dig sigs. Given that the paths in the 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
Re: [widgets] Comments on Widget Signature update (was RE: Widget Signature update)
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 P&C 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 P&C [1] and see if it is usable in dig sigs. Given that the paths in the 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
