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 frederick.hir...@nokia.com wrote: Marcos Thanks for taking this pass. I note a number of editorial corrections that I believe should be made before publishing: 1. Introduction should not have normative statements, and these replicate material later in the document, so change MAY to can in 2 places. 2. Section 4, #4, change must to MUST fixed 3. Section 4, #6, change Security to security fixed 4. Section 5.3.1, include blank line between bullet with DIGIT and next bullet fixed 5. Section 6, replace .. with . in editorial note fixed 6. Section 6.1, change DSAwithSHA to DSAwithSHA1 fixed 7. Section 7.2, change link to be from signature file, it is currently broken seemed ok? replaced it anyway. 8. End of section 8, remove example from sentence, change For example, end-users to End-users and combine with previous paragraph. Done. 9. Add note to [XMLDSIG-Properties] reference as follows (at end of reference entry): Note, section 9 includes additions made in the XML Security WG to the XML Signature Properties editors draft (subsequent to First Public Working Draft) that are used in this specification. Done. --- I also suggest you make sure that all changes in the working draft are also reflected in what is checked into the Editors draft in CVS so we can make changes as needed without losing these latest changes for the working draft (the only difference need be the setting as editors vs working draft I think). Done. I also notice on a substantive level that you changed the namespace. Was the reason to match a pre-existing choice for the Packaging and Configuration? Is this an item for discussion? Yes, I did that today but never got around to sending out an email about it. Sorry. The change was to put it inline with PC. Do you see any issues arising from the new NS? should I change it back? I'm of the position that NSs should not be dated because changing NS and, hence semantics, for elements in the future is probably a bad idea. The other changes looked good, thanks for improving the draft. My pleasure! Thanks for doing all the hard work and actual thinking! :) Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
RE: [BONDI Architecture Security] [widgets] new digsig draft
Dear Marcos, I have some proposals for editorial changes. 1. Section 1.2: change which MAY logically contains to which MAY logically contain 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. 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? 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 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. 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). 7. Section 5.1: change in [XML-Schema-Datatypes])within to in [XML-Schema-Datatypes]) within 8. Section 5.2: change header Author Signatures to Author Signature because we have zero or one author signature. 9. Section 5.2: and whether two widgets came from the same author: Two signed widgets that were signed with the same certificate only indicate that these both widgets were signed with the same certificate. The signatures do not enable any confidence in the relationship between a widget author and a widget signer. There are no means that hinder me as an attacker to strip off all widget's signatures, sign it with my own certificate with which I signed another but rogue widget from somebody else. Therefore, I would recommend to delete this bullet point. 10. Section 5.2: change A widget package MAY contain zero or one author signatures. to A widget package MAY contain zero or one author signature. More change proposals may come tomorrow (if identified tomorrow). 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 26 March 2009 Voice Conference ; 90 Minutes
Regrets, attending a MWI BPWG all-day (for me, night) session. Best regards, Bryan Sullivan | ATT -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: Wednesday, March 25, 2009 4:50 AM To: public-webapps Subject: [widgets] Agenda for 26 March 2009 Voice Conference ; 90 Minutes 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 = 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. PC spec: L10N model - one master config file only or locale- specific config files to override definitions in the master config file: http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/ 0899.html/ 4. PC spec: status of access element: http://dev.w3.org/2006/waf/widgets/#the-access-element 5. PC spec: what do we do about the update element given Apple's patent disclosure for the Widgets Updates spec: http://dev.w3.org/2006/waf/widgets/#the-update-element 6. PC spec: step 7 - need to add preference element and the screenshot element; what is the status: http://dev.w3.org/2006/waf/widgets/#step-7-process-the- configuration-document 7. PC spec: XML Base http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/ 0883.html 8. AE spec: discuss issues in latest ED and assign related actions; what needs to be done to publish LCWD: http://dev.w3.org/2006/waf/widgets-api/ 9. Window Modes spec: status and next steps; dependencies 10. AOB
Re: access and IRI equivalence
On 26 Mar 2009, at 14:44, Anne van Kesteren wrote: On Thu, 26 Mar 2009 14:40:16 +0100, Thomas Roessler t...@w3.org wrote: 1. I think it's a good thing to phrase this in terms of the BNF from 3986 and 3987. I don't think it's obvious that this piece of the spec needs to reuse the HTML URI parser. AFAICT that parser is used for HTTP, CSS, HTML, XMLHttpRequest, DOM APIs, etc. I phrased this poorly. The question at hand is whether the spec needs a dependency on HTML's use of URI references, or whether a reference to the URI spec is sufficient. I suspect that the latter is in fact the case; implementations would still be free to be a bit more lenient.
Re: access and IRI equivalence
On Thu, 26 Mar 2009 14:51:02 +0100, Thomas Roessler t...@w3.org wrote: I phrased this poorly. The question at hand is whether the spec needs a dependency on HTML's use of URI references, or whether a reference to the URI spec is sufficient. I suspect that the latter is in fact the case; implementations would still be free to be a bit more lenient. Wouldn't that lead to interoperability issues? -- Anne van Kesteren http://annevankesteren.nl/
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
[widgets] Minutes from 26 March 2009 Voice Conference
The minutes from the March 26 Widgets voice conference are available at the following and copied below: http://www.w3.org/2009/03/26-wam-minutes.html WG Members - if you have any comments, corrections, etc., please send them to the public-webapps mail list before 2 April 2009 (the next Widgets voice conference); otherwise these minutes will be considered Approved. -Regards, Art Barstow [1]W3C [1] http://www.w3.org/ - DRAFT - Widgets Voice Conference 26 Mar 2009 [2]Agenda [2] http://lists.w3.org/Archives/Public/public-webapps/ 2009JanMar/0926.html See also: [3]IRC log [3] http://www.w3.org/2009/03/26-wam-irc Attendees Present Art, Thomas, Frederick, Mark, Andy, Robin, Arve, Marcos Regrets Jere, Bryan Chair Art Scribe Art Contents * [4]Topics 1. [5]Review and tweak agenda 2. [6]Announcements 3. [7]DigSig 4. [8]PC spec: L10N model 5. [9]PC spec: status of access element: 6. [10]PC spec: update element given Apple's patent disclosure 7. [11]PC spec: step 7 - need to add preference element and the screenshot element; 8. [12]PC spec: XML Base 9. [13]AE spec 10. [14]Window Modes spec * [15]Summary of Action Items _ scribe ScribeNick: ArtB scribe Scribe: Art Date: 26 March 2009 Review and tweak agenda AB: I posted the agenda on March 25 [16]http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/09 26.html Note DigSig is not on today's agenda. ... Are there any change requests? [16] http://lists.w3.org/Archives/Public/public-webapps/ 2009JanMar/0926.html FH: want to add DigSig namespaces AB: OK but will limit the time ... any other requests? [None] Announcements AB: any short announcements? I don't have any. [ None ] DigSig AB: go ahead Frederick FH: I made a few changes ... checker complained MC: will fix it FH: namespace question ... is it OK to not use date TR: I need to check the namespace policy tlr [17]http://www.w3.org/2005/07/13-nsuri [17] http://www.w3.org/2005/07/13-nsuri RB: namespace policy should permit this TR: I don't see any problems; we can go ahead FH: then I think we're all set MC: agreed AB: the DigSig WD should be published early next week PC spec: L10N model AB: one of the open issues is if the PC's localization model should be one master config file only versus a master config file plus locale-specific config files to override definitions in the master config file. Marcos created lists of advantages and disadvantages of both models. Some people have expressed their preference. The tally appears to be: Only one: Marcos; One Plus: Josh, Benoit; Can Live With Either: Jere. The thread is here: [18]http://lists.w3.org/Archi ... I would like to get consensus i.e. a resolution on this today and a gentle reminder that I Can Live With It will help us get the next LCWD published. Let's start with Marcos - do you see a single model that addresses everyone's concerns? [18] http://lists.w3.org/Archi MC: the new model doesn't address the concern where multiple localizers are involved in the process pipeline ... the new model is easier to implement ... agree the config file could grow to an un-manageable size ... the I18N WG said the new model is OK ... I think we could merge the models BS: I don't understand the merge model Marcos MC: have the main config file but if the app has lots of localized data that data can be put in separate files AB: any other comments? w3c_ when using both models there would need a sort of precedence of some sort so that 2 information do not overlap RB: so is the idea to have a single file for v1.0 and then in v1.* move to support the old model MC: yes, that is true darobin RB: I think it makes sense to start with something simple and only add the more advanced features if we need them later MC: the model is to use a single config doc for 1.0 ... inside that file the xml:lang attr is used to localize specific elements and attrs ... in subsequent version of P+C we add support for locale-specific conf files AB: is this right Marcos? MC: yes AB: any comments about this evolution path ... Note that timeless is not on the call ... He objected to the new model but did not include any rationale for his objection ... Benoit, what are your thoughts on this evolution proposal? BS: I think I can live with it ... I do think localizers having their separate files is better ... but having just one config file wil be easier for the developer AB: I think we have consensus to go
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 marc...@opera.com An: Paddy Byers pa...@aplix.co.jp Cc: Hillebrand, Rainer; WebApps WG public-webapps@w3.org; otsi-arch-...@omtplists.org otsi-arch-...@omtplists.org Gesendet: Thu Mar 26 17:12:20 2009 Betreff: Re: [BONDI Architecture Security] [widgets] new digsig draft On Thu, Mar 26, 2009 at 4:29 PM, Paddy Byers pa...@aplix.co.jp wrote: Hi, Agreed. Can we say were signed with the same certificate instead? I understood that Webapps had agreed to add a signature profile that designates a particular signature as the author signature - and where this is present it is possible to come up with appropriate precise wording as to whether or not two packages originate from the same author. Well, that's basically what we have, but Rainer seems to imply that it is impossible to do this. I think we get as close as we technically can to achieving that goal. However, if that current solution is inadequate, then please send us suggestions. -- Marcos Caceres http://datadriven.com.au T-Mobile International AG Aufsichtsrat/ Supervisory Board: René Obermann (Vorsitzender/ Chairman) Vorstand/ Board of Management: Hamid Akhavan (Vorsitzender/ Chairman), Michael Günther, Lothar A. Harings, Katharina Hollender Handelsregister/Commercial Register Entry: Amtsgericht Bonn, HRB 12276 Steuer-Nr./Tax No.: 205 / 5777/ 0518 USt.-ID./VAT Reg.No.: DE189669124 Sitz der Gesellschaft/ Corporate Headquarters: Bonn
RE: Re: [BONDI Architecture Security] [widgets] new digsig draft
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 marc...@opera.com An: Paddy Byers pa...@aplix.co.jp Cc: Hillebrand, Rainer; WebApps WG public-webapps@w3.org; otsi-arch-...@omtplists.org otsi-arch-...@omtplists.org Gesendet: Thu Mar 26 17:12:20 2009 Betreff: Re: [BONDI Architecture Security] [widgets] new digsig draft On Thu, Mar 26, 2009 at 4:29 PM, Paddy Byers pa...@aplix.co.jp wrote: Hi, Agreed. Can we say were signed with the same certificate instead? I understood that Webapps had agreed to add a signature profile that designates a particular signature as the author signature - and where this is present it is possible to come up with appropriate precise wording as to whether or not two packages originate from the same author. Well, that's basically what we have, but Rainer seems to imply that it is impossible to do this. I think we get as close as we technically can to achieving that goal. However, if that current solution is inadequate, then please send us suggestions. -- Marcos Caceres http://datadriven.com.au T-Mobile International AG Aufsichtsrat/ Supervisory Board: René Obermann (Vorsitzender/ Chairman) Vorstand/ Board of Management: Hamid Akhavan (Vorsitzender/ Chairman), Michael Günther, Lothar A. Harings, Katharina Hollender Handelsregister/Commercial Register Entry: Amtsgericht Bonn, HRB 12276 Steuer-Nr./Tax No.: 205 / 5777/ 0518 USt.-ID./VAT Reg.No.: DE189669124 Sitz der Gesellschaft/ Corporate Headquarters: Bonn
AW: RE: Re: [BONDI Architecture Security] [widgets] new digsig draft
Dear Mark, I agree to use your text. Best Regards, Rainer --- Sent from my mobile device - Originalnachricht - Von: otsi-arch-sec-ow...@omtp.ieee-isto.org otsi-arch-sec-ow...@omtp.ieee-isto.org An: Hillebrand, Rainer; marc...@opera.com marc...@opera.com; pa...@aplix.co.jp pa...@aplix.co.jp Cc: public-webapps@w3.org public-webapps@w3.org; otsi-arch-...@omtplists.org otsi-arch-...@omtplists.org Gesendet: Thu Mar 26 17:58:03 2009 Betreff: RE: Re: [BONDI Architecture Security] [widgets] new digsig draft 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 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: 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 marc...@opera.com An: Paddy Byers pa...@aplix.co.jp Cc: Hillebrand, Rainer; WebApps WG public-webapps@w3.org; otsi-arch-...@omtplists.org otsi-arch-...@omtplists.org Gesendet: Thu Mar 26 17:12:20 2009 Betreff: Re: [BONDI Architecture Security] [widgets] new digsig draft On Thu, Mar 26, 2009 at 4:29 PM, Paddy Byers pa...@aplix.co.jp wrote: Hi, Agreed. Can we say were signed with the same certificate instead? I understood that Webapps had agreed to add a signature profile that designates a particular signature as the author signature - and where this is present it is possible to come up with appropriate precise wording as to whether or not two packages originate from the same author. Well, that's basically what we have, but Rainer seems to imply that it is impossible to do this. I think we get as close as we technically can to achieving that goal. However, if that current solution is inadequate, then please send us suggestions. -- Marcos Caceres http://datadriven.com.au T-Mobile International AG Aufsichtsrat/ Supervisory Board: René Obermann (Vorsitzender/ Chairman) Vorstand/ Board of Management: Hamid Akhavan (Vorsitzender/ Chairman), Michael Günther, Lothar A. Harings, Katharina Hollender Handelsregister/Commercial Register Entry: Amtsgericht Bonn, HRB 12276 Steuer-Nr./Tax No.: 205 / 5777/ 0518 USt.-ID./VAT Reg.No.: DE189669124 Sitz der
AW: Re: [BONDI Architecture Security] [widgets] new digsig draft
Dear Frederick, The intent is clear but the technical solution will only provide confidence if you trust the owner of the author certificate. If you trust the owner then it is very likely for you that a widget with this author signature really comes from this author. However, there is no technical relationship between the widget author and the owner of the author certificate that you can technically verify. Best Regards, Rainer --- Sent from my mobile device - Originalnachricht - Von: Frederick Hirsch frederick.hir...@nokia.com An: ext Priestley, Mark, VF-Group mark.priest...@vodafone.com Cc: Frederick Hirsch frederick.hir...@nokia.com; Hillebrand, Rainer; marc...@opera.com marc...@opera.com; pa...@aplix.co.jp pa...@aplix.co.jp; public-webapps@w3.org public-webapps@w3.org; otsi-arch-...@omtplists.org otsi-arch-...@omtplists.org Gesendet: Thu Mar 26 18:34:57 2009 Betreff: Re: [BONDI Architecture Security] [widgets] new digsig draft I think I disagree, since the intent *is* to identify the author, that is the semantics, and this proposed change makes it less clear. Of course we can argue whether or not you achieve that if you cannot associate the signature with the author, but that is out of scope. regards, Frederick Frederick Hirsch Nokia On Mar 26, 2009, at 12:58 PM, ext Priestley, Mark, VF-Group wrote: Hi All, As the author signature was something I had a hand in creating let me add my 2 pence worth. Rainer is correct in that the author signature need not actually come from the author of the widget. It comes from someone who claims to be the widget's author. Whether you believe this claim depends on how much you trust the signer. In [1] the current text says: [ The author signature can be used to determine: * the author of a widget, * that the integrity of the widget is as the author intended, * and whether two widgets came from the same author. ] I would suggest changing this to: [ The author signature can be used to: * authenticate the identity of the entity that added the author signature to the widget package, * confirm that no widget files have been modified, deleted or added since the generation of the author signature. The author signature may be used to: * determine whether two widgets came from the same author. ] The reason the last point is a may is as follows: If two widgets contain author signatures that were created using the same private key then we can say that the widgets were both signed 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 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: 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 marc...@opera.com An: Paddy Byers pa...@aplix.co.jp Cc: Hillebrand, Rainer; WebApps WG public-webapps@w3.org; otsi-arch-...@omtplists.org otsi-arch-...@omtplists.org Gesendet: Thu Mar 26 17:12:20 2009 Betreff: Re: [BONDI Architecture Security] [widgets] new digsig draft On Thu, Mar 26, 2009 at 4:29 PM, Paddy Byers pa...@aplix.co.jp wrote: Hi, Agreed. Can we say were signed with the same certificate instead? I understood that Webapps had agreed to add a signature
Re: AW: Re: [BONDI Architecture Security] [widgets] new digsig draft
What the author certificate lets you verify is whether a single party is taking responsibility for two widgets. There is indeed no *proof* of authorship here, but a statement that the signer is willing to assume the blame for being the widget's author. Which is all we need, no? -- Thomas Roessler, W3C t...@w3.org On 26 Mar 2009, at 19:00, Hillebrand, Rainer wrote: Dear Frederick, The intent is clear but the technical solution will only provide confidence if you trust the owner of the author certificate. If you trust the owner then it is very likely for you that a widget with this author signature really comes from this author. However, there is no technical relationship between the widget author and the owner of the author certificate that you can technically verify. Best Regards, Rainer --- Sent from my mobile device - Originalnachricht - Von: Frederick Hirsch frederick.hir...@nokia.com An: ext Priestley, Mark, VF-Group mark.priest...@vodafone.com Cc: Frederick Hirsch frederick.hir...@nokia.com; Hillebrand, Rainer; marc...@opera.com marc...@opera.com; pa...@aplix.co.jp pa...@aplix.co.jp ; public-webapps@w3.org public-webapps@w3.org; otsi-arch-...@omtplists.org otsi-arch-...@omtplists.org Gesendet: Thu Mar 26 18:34:57 2009 Betreff: Re: [BONDI Architecture Security] [widgets] new digsig draft I think I disagree, since the intent *is* to identify the author, that is the semantics, and this proposed change makes it less clear. Of course we can argue whether or not you achieve that if you cannot associate the signature with the author, but that is out of scope. regards, Frederick Frederick Hirsch Nokia On Mar 26, 2009, at 12:58 PM, ext Priestley, Mark, VF-Group wrote: Hi All, As the author signature was something I had a hand in creating let me add my 2 pence worth. Rainer is correct in that the author signature need not actually come from the author of the widget. It comes from someone who claims to be the widget's author. Whether you believe this claim depends on how much you trust the signer. In [1] the current text says: [ The author signature can be used to determine: * the author of a widget, * that the integrity of the widget is as the author intended, * and whether two widgets came from the same author. ] I would suggest changing this to: [ The author signature can be used to: * authenticate the identity of the entity that added the author signature to the widget package, * confirm that no widget files have been modified, deleted or added since the generation of the author signature. The author signature may be used to: * determine whether two widgets came from the same author. ] The reason the last point is a may is as follows: If two widgets contain author signatures that were created using the same private key then we can say that the widgets were both signed 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 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: 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 marc...@opera.com An: Paddy Byers pa...@aplix.co.jp Cc: Hillebrand, Rainer; WebApps WG public-webapps@w3.org; otsi-arch-...@omtplists.org otsi-arch-...@omtplists.org Gesendet: Thu Mar
RE: [BONDI Architecture Security] [widgets] new digsig draft
Hi Marcos, All, Please find below my - mostly editorial - comments to the latest digsig draft and one comment for PC. Thanks. Kind regards, Marcin 1. Section 1: ... with XML signatures that each cryptographically include all of the non-signature ... should become (missing s) ... with XML signatures that each cryptographically includes all of the non-signature ... 2. Unify case sensitive phrase. There are now both case-sensitive and case sensitive present in the text. 3. Section 1.2: Maybe the common terms could be unified between DigSig and PC? Both specs will probably be always used together. A file entry is the compressed (or Stored) representation of a physical file or folder contained within a widget package, as defined in the [Widgets Packaging] specification. The root 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 b) Clarify file name in PC (the definition in DigSig says about deriving from file name field and it seems strange to me). 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. 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. 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. 6. Section 4, item 5: .. treat this as.. - what is this? I suggest to change the text to ... treat this widget package as ... 7. Section 4, item 6: Validate the signature files in the signatures list - signatures looks weird, the cause is var vs. code in HTML. 8. Section 5.3.1: A file entry whose file name that does not match the - that should be removed 9. Section 5.4: identify the X.509 version fully. The X.509 certificate format MUST could become The X.509v1 certificate format MUST 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 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 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. BTW: Comment to PC: 1. RFC 2119 terms are in lower-case in PC, whereas DigSig uses upper-case (that is more common). 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 Marcos Caceres Sent: Wednesday, March 25, 2009 4:42 PM To: WebApps WG; otsi-arch-...@omtplists.org Subject: [BONDI Architecture Security] [widgets] new digsig draft 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 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
Re: Web Sigining in Action
Dear Marcos Caceres, Thanks for your kind reply. Sorry my delay. Ian recommended us to continue this discussion in Webapps W/G[6]. Andres also has tried another effort to solve issue[7]. can you please send us a better summary. As you know, most of certificate service consist of three steps: 1. Issuing of personal certificate 2. Authentication and validation per each certificate 3. Digital signing for valid text or document. I meant this full process was lack in web browser right now, anyway many private or public CAs have did it in web browser. It means they couldn't help using plug-in method for missing link. I know some of european government also used plugins (http://www.openoces.org/index.html) as well as Verisign's private CA service. Actually all of plugins had same functions and cost in duplicated. In case of Korea, there are over 40 same function Active X plugin per each CA or PKI companies. If there is good spec. for web browser, it can be implemented soon. All browser already had certificate storage that issued personal certificates can be managed and own PKI library (open source or not) that validates certificate and does digital signing. Actually there were issuing certificate in web browser such as such as text-signing functions in web browser such as crypto.signText() and Microsoft capicom.dll. So I suggested form-based signing such as form signed=signined in HTML5 spec. If web browser count this form, it can be proceeded choosing certificate, signing text and send to server. Ian thought there are many apps based consideration not for only HTML spec. He recommended for me to suggest it in this w/g. Rebuilding of Web Signing Profile Maybe this long history was recognized by leading people of this group. I don’t convince whether the activity of web signing profile was made by this purpose or not. But, it seems to integrate with Widget’s digital signature and there is no action further. I dont understand. can you please make your comments against the current editor's draft of our spec? I don't blame for your current widget:digital signature and just wondered whether web signing profile is limited widget area or not. I still thank you and member's job for developing current spec and it'll be useful trust-building among widget vendors, providers and users. So my suggestion is complete another about your current job and want for w/g member to consider for future job. So I want for you to consider this issue in this working group with new baseline and for to browser vendors to join this issue quickly before many countries commit a fault as like Korea. Brower’s functions as like crypto.signText or IE’s CAPICOM dll were deprecated in right now. So it is essential making new standard and implementation them. I'm not sure what you wan us to do. Mine is very simple: Finding simple job in web browser to support full process of digital signing. In view of webapps, all of functions have better be declared by Javascript interface. It may be similar with old IE's capicom method http://msdn.microsoft.com/en-us/library/aa388154%28VS.85%29.aspx or http://docs.sun.com/source/816-6152-10/sgntxt.htm. Simple scheme is as followng fuctions: 1. issuing and validation of personal certificate auth.ceritificate.issue() auth.certificate.revoke() auth.certificate.validate() for OCSP protocol. 2. digital signing. auth.certificate.open() auth.certificate.validate() auth.signText() auth.signXML() auth.send() - xmlhttprequest.send() auth.close() e.x. resultString = auth.signText(stringToSign, caOption, [caNameString1, [caNameString2, . . . ]]) Channy
Re: Web Sigining in Action
Dear all, I agreed Andres said that it is unclear where a certain issue belong apps or not. I means everyone didn't care about this while many industrial vendors have made tireless same plugins in web space. Although Anders indicated there were less certificate applications, there are 14 million users in Korea and many countries have considered public CA area in web browser. Japan made own cryptographic algorithm called Camella with Nokia pushing it to all browsers. It means Japan is interested in offering public CA to all citizen. European I said. For several years, innovation from web browsers changed world. It's time to action not to only thinking and I believe that html5 and webapps w/g can do this. Frankly speaking, my suggestion is very old, but it's cost-effective for existing vendors both web browser and plugin based CAs. Thanks, Channy - http://www.linkedin.com/in/channy Daum Developers Network Affiliates http://dna.daum.net On Wed, Mar 25, 2009 at 7:00 AM, Anders Rundgren anders.rundg...@telia.comwrote: I think a problem is that it is unclear where a certain issue belong. IMO all of the stuff I wrote about belong to the app-area but some people think it is about security only. XML protocols in browsers is an app, at least as I see it. Anders - Original Message - From: Marcos Caceres marc...@opera.com To: Anders Rundgren anders.rundg...@telia.com Cc: channy cha...@gmail.com; WebApps HG public-webapps@w3.org; Jungshik Shin jungs...@google.com; Gen Kanai g...@mozilla.com; Ian Hickson i...@hixie.ch; Thomas Roessler t...@w3.org Sent: Tuesday, March 24, 2009 22:24 Subject: Re: Web Sigining in Action On Tue, Mar 24, 2009 at 9:37 PM, Anders Rundgren anders.rundg...@telia.com wrote: Hi Everybody, There are simply TONS of issues related to usage of certificates in conjunction with a browser. If you want, you can take a peek at the current thread client certficates unusable? in mozilla-dev :-) I personally find it annoying that there are maybe some 100M USB memory sticks in circulation that could have been a wonderful container for keys but unfortunately it never happened. Well, a few US compaines tried to create proprietary solutions with SanDisk but (of course) they all failed. Who want to *pay* for a card driver? It is really something that you would like the OS to have from the beginning! What does this have to do with Web Signing you may wonder? Well, IMO we need to take this in a step-wise fashion and if we can't even get the keyring´right, it seems that the rest will be of secondary interest. That doesn't say I'm not interested in Web Signing, I have just put it on the back-burner in favor of key storage and execution. The absence of a useful keygen standard is a disaster. Will the browser- vendors be able to address this issue? I don't expect that. Regarding Web Signing a large groups of banks have turned to MSFT to get this solved. I think they are overly optimistic about MSFT's capability and interest in this area but it is a good thing that they are trying at least :-) Based on 13 years of experience with eID, I believe most of the web standards in this are will not come from standardization forums because they have proved to good for really general purpose stuff, but much less successful for applications like Web Sign and keygen. A scheme like my current KeyGen2 would not take less than 3 years to standardize and the result would probably be not be very useful anyway. Why? Because there are too many choices and people cannot work under such premisses. Whatever keygen or WebSign we will get, it will most certainly be an open source effort rather than a standard. What W3C could/should standardize is a way to get XML protocols running in a browser and leave the content parts to other groups. IETF's KEYPROV will fail as hard as XKMS did if we ignore the browser connection all the time. I see. thanks for the history. However, what, if anything, should our working group do? I don't see anything that is in scope or anything directed at any one of our specifications. If we are screwing something up somewhere, then please be clear as to where and we will do our best to fix it. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
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 marc...@opera.com An: Hillebrand, Rainer Cc: WebApps WG public-webapps@w3.org; otsi-arch-...@omtplists.org otsi-arch-...@omtplists.org Gesendet: Thu Mar 26 16:24:22 2009 Betreff: Re: [BONDI Architecture Security] [widgets] new digsig draft Hi Rainer, On Thu, Mar 26, 2009 at 1:57 PM, Hillebrand, Rainer rainer.hillebr...@t-mobile.net wrote: Dear Marcos, I have some proposals for editorial changes. 1. Section 1.2: change which MAY logically contains to which MAY logically contain fixed. 2. Section 1.2: An unsigned widget package is a widget package that does not contain any signature files. It is left to the user agent's security policy how to deal with unsigned widget packages. Doesn't the same apply to signed widget packages, too? There is no W3C right now that specifies how a user agent shall deal with signed widget packages. I suggest to delete the sentence It is left to the user agent's security policy how to deal with unsigned widget packages. Deleted. 3. Section 1.2: Rules are concatenated by being written next to each other and a rule prep ended by * means zero or more. I would suggest to split this sentence into two: Rules are concatenated by being written next to each other. A rule prep ended by * means zero or more. What is a rule prep? Ok, split. Dunno what a prep is, so I removed it. 4. Section 2: change this specification supports SHA-256 the reference element and ds:SignedInfo element to this specification supports SHA-256, the reference element and ds:SignedInfo element fixed. 5. Section 3: Implementers are encouraged to provide mechanisms to enable end-users to install additional root certificates. Trust in a root certificate is established through a security critical mechanism implemented by the user agent that is out of scope for this specification. A root certificate could be used for TLS as well but we mean certificates for widget package signature verification. additional could imply that a user agent is always provided with at least one certificate which does not need to be the case. Therefore, I would like to propose to change this part to Implementers are encouraged to provide mechanisms to enable end- users to install certificates for widget package digital signature verification. Trust in a certificate is established through a security critical mechanism implemented by the user agent that is out of scope for this specification. Ok, I included your text, but modified it slightly: Implementers are encouraged to provide mechanisms to enable end-users to install certificates for enabling verification of digital signatures within the widget package. Trust in a certificate is established through a security critical mechanism implemented by the user agent, which is out of scope for this specification. 6. Section 4: Process the signature files in the signatures list in descending order, with distributor signatures first (if any). The processing is not defined before and it is unclear whether there is a difference between processing and signature validation. Suggestion: Validate the signature files in the signatures list in descending order, with distributor signatures first (if any). Fixed. 7. Section 5.1: change in [XML-Schema-Datatypes])within to in [XML-Schema-Datatypes]) within Fixed. 8. Section 5.2: change header Author Signatures to Author Signature because we have zero or one author signature. True. fixed. 9. Section 5.2: and whether two widgets came from the same author: Two signed widgets that were signed with the same certificate only indicate that these both widgets were signed with the same certificate. The signatures do not enable any confidence
Re: AW: Re: [BONDI Architecture Security] [widgets] new digsig draft
I think the draft provides enough assurance for the intended level of use. If you want higher levels of assurance more will be required, but I don't believe we have a requirement here for that. regards, Frederick Frederick Hirsch Nokia On Mar 26, 2009, at 12:20 PM, ext Hillebrand, Rainer wrote: Dear Marcos, We cannot technically guarantee that the author signature really comes from the widget's author. It is like having an envelop with an unsigned letter. The envelop and the letter can come from different sources even if the envelop has a signature. Best Regards, Rainer --- Sent from my mobile device - Originalnachricht - Von: Marcos Caceres marc...@opera.com An: Paddy Byers pa...@aplix.co.jp Cc: Hillebrand, Rainer; WebApps WG public-webapps@w3.org; otsi-arch-...@omtplists.org otsi-arch-...@omtplists.org Gesendet: Thu Mar 26 17:12:20 2009 Betreff: Re: [BONDI Architecture Security] [widgets] new digsig draft On Thu, Mar 26, 2009 at 4:29 PM, Paddy Byers pa...@aplix.co.jp wrote: Hi, Agreed. Can we say were signed with the same certificate instead? I understood that Webapps had agreed to add a signature profile that designates a particular signature as the author signature - and where this is present it is possible to come up with appropriate precise wording as to whether or not two packages originate from the same author. Well, that's basically what we have, but Rainer seems to imply that it is impossible to do this. I think we get as close as we technically can to achieving that goal. However, if that current solution is inadequate, then please send us suggestions. -- Marcos Caceres http://datadriven.com.au T-Mobile International AG Aufsichtsrat/ Supervisory Board: René Obermann (Vorsitzender/ Chairman) Vorstand/ Board of Management: Hamid Akhavan (Vorsitzender/ Chairman), Michael Günther, Lothar A. Harings, Katharina Hollender Handelsregister/Commercial Register Entry: Amtsgericht Bonn, HRB 12276 Steuer-Nr./Tax No.: 205 / 5777/ 0518 USt.-ID./VAT Reg.No.: DE189669124 Sitz der Gesellschaft/ Corporate Headquarters: Bonn
RE: [BONDI Architecture Security] [widgets] new digsig draft
Hi, One correction to what I wrote: Instead of a) Replace root of the archive with root of the widget I would now suggest a) Replace root of the archive with root of the widget package Thanks. Kind regards, Marcin Marcin Hanclik ACCESS Systems Europe GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: otsi-arch-sec-ow...@omtp.ieee-isto.org [mailto:otsi-arch-sec-ow...@omtp.ieee-isto.org] On Behalf Of Marcin Hanclik Sent: Thursday, March 26, 2009 7:05 PM To: marc...@opera.com; WebApps WG; otsi-arch-...@omtplists.org Subject: RE: [BONDI Architecture Security] [widgets] new digsig draft Hi Marcos, All, Please find below my - mostly editorial - comments to the latest digsig draft and one comment for PC. Thanks. Kind regards, Marcin 1. Section 1: ... with XML signatures that each cryptographically include all of the non-signature ... should become (missing s) ... with XML signatures that each cryptographically includes all of the non-signature ... 2. Unify case sensitive phrase. There are now both case-sensitive and case sensitive present in the text. 3. Section 1.2: Maybe the common terms could be unified between DigSig and PC? Both specs will probably be always used together. A file entry is the compressed (or Stored) representation of a physical file or folder contained within a widget package, as defined in the [Widgets Packaging] specification. The root 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 b) Clarify file name in PC (the definition in DigSig says about deriving from file name field and it seems strange to me). 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. 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. 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. 6. Section 4, item 5: .. treat this as.. - what is this? I suggest to change the text to ... treat this widget package as ... 7. Section 4, item 6: Validate the signature files in the signatures list - signatures looks weird, the cause is var vs. code in HTML. 8. Section 5.3.1: A file entry whose file name that does not match the - that should be removed 9. Section 5.4: identify the X.509 version fully. The X.509 certificate format MUST could become The X.509v1 certificate format MUST 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 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 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. BTW: Comment to PC: 1. RFC 2119 terms are in lower-case in PC, whereas DigSig uses upper-case (that is more common). 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 Marcos Caceres Sent: Wednesday, March 25, 2009 4:42 PM To: WebApps WG; otsi-arch-...@omtplists.org Subject: [BONDI Architecture Security] [widgets] new digsig draft 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
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 t...@w3.org On 26 Mar 2009, at 19:00, Hillebrand, Rainer wrote: Dear Frederick, The intent is clear but the technical solution will only provide confidence if you trust the owner of the author certificate. If you trust the owner then it is very likely for you that a widget with this author signature really comes from this author. However, there is no technical relationship between the widget author and the owner of the author certificate that you can technically verify. Best Regards, Rainer --- Sent from my mobile device - Originalnachricht - Von: Frederick Hirsch frederick.hir...@nokia.com An: ext Priestley, Mark, VF-Group mark.priest...@vodafone.com Cc: Frederick Hirsch frederick.hir...@nokia.com; Hillebrand, Rainer; marc...@opera.com marc...@opera.com; pa...@aplix.co.jp pa...@aplix.co.jp ; public-webapps@w3.org public-webapps@w3.org; otsi-arch-...@omtplists.org otsi-arch-...@omtplists.org Gesendet: Thu Mar 26 18:34:57 2009 Betreff: Re: [BONDI Architecture Security] [widgets] new digsig draft I think I disagree, since the intent *is* to identify the author, that is the semantics, and this proposed change makes it less clear. Of course we can argue whether or not you achieve that if you cannot associate the signature with the author, but that is out of scope. regards, Frederick Frederick Hirsch Nokia On Mar 26, 2009, at 12:58 PM, ext Priestley, Mark, VF-Group wrote: Hi All, As the author signature was something I had a hand in creating let me add my 2 pence worth. Rainer is correct in that the author signature need not actually come from the author of the widget. It comes from someone who claims to be the widget's author. Whether you believe this claim depends on how much you trust the signer. In [1] the current text says: [ The author signature can be used to determine: * the author of a widget, * that the integrity of the widget is as the author intended, * and whether two widgets came from the same author. ] I would suggest changing this to: [ The author signature can be used to: * authenticate the identity of the entity that added the author signature to the widget package, * confirm that no widget files have been modified, deleted or added since the generation of the author signature. The author signature may be used to: * determine whether two widgets came from the same author. ] The reason the last point is a may is as follows: If two widgets contain author signatures that were created using the same private key then we can say that the widgets were both signed by
RE: AW: Re: [BONDI Architecture Security] [widgets] new digsig draft
Hi Thomas, Nice suggestion, but I am not sure whether it will survive in the real world and be abandoned or replaced by other interpretations. [I personally associate the author with the widget developer] Let's imagine I am a developer D of the widget W and I work for company C. Who is the actual author and what does it mean? Whose private key is used for author signature? Could e.g. the company C be the first distributor of the widget W and I remain the author and sign the widget with my private key? I am not sure whether it is feasible to map all the possible configurations of the relationships with 2-level signature architecture (author + distributors). Even then, the role names would not fit probably. Maybe this would be enough? The author signature binds the author's identity to the widget package. Then similarly: The distributor's signature binds the distributor's identity to the widget package. So it would be only about binding various entities with each other. 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 10:38 PM To: Hillebrand, Rainer Cc: 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 Suggestion: The author signature asserts that the signing party is an author of the widget, and binds the author's identity to the widget package. Regards, -- Thomas Roessler, W3C t...@w3.org On 26 Mar 2009, at 17:20, Hillebrand, Rainer wrote: Dear Marcos, We cannot technically guarantee that the author signature really comes from the widget's author. It is like having an envelop with an unsigned letter. The envelop and the letter can come from different sources even if the envelop has a signature. Best Regards, Rainer --- Sent from my mobile device - Originalnachricht - Von: Marcos Caceres marc...@opera.com An: Paddy Byers pa...@aplix.co.jp Cc: Hillebrand, Rainer; WebApps WG public-webapps@w3.org; otsi-arch-...@omtplists.org otsi-arch-...@omtplists.org Gesendet: Thu Mar 26 17:12:20 2009 Betreff: Re: [BONDI Architecture Security] [widgets] new digsig draft On Thu, Mar 26, 2009 at 4:29 PM, Paddy Byers pa...@aplix.co.jp wrote: Hi, Agreed. Can we say were signed with the same certificate instead? I understood that Webapps had agreed to add a signature profile that designates a particular signature as the author signature - and where this is present it is possible to come up with appropriate precise wording as to whether or not two packages originate from the same author. Well, that's basically what we have, but Rainer seems to imply that it is impossible to do this. I think we get as close as we technically can to achieving that goal. However, if that current solution is inadequate, then please send us suggestions. -- Marcos Caceres http://datadriven.com.au T-Mobile International AG Aufsichtsrat/ Supervisory Board: René Obermann (Vorsitzender/ Chairman) Vorstand/ Board of Management: Hamid Akhavan (Vorsitzender/ Chairman), Michael Günther, Lothar A. Harings, Katharina Hollender Handelsregister/Commercial Register Entry: Amtsgericht Bonn, HRB 12276 Steuer-Nr./Tax No.: 205 / 5777/ 0518 USt.-ID./VAT Reg.No.: DE189669124 Sitz der Gesellschaft/ Corporate Headquarters: Bonn 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] Author, was: RE: AW: Re: [BONDI Architecture Security] [widgets] new digsig draft
Hi, I have been trying to identify the term author in Widget specs. I think we're in danger of getting into details that are irrelevant for the PC specification. This spec should define what information is asserted by the presence of the author and distributor signatures. It is up to a consuming device, possibly defined by some other specification, to determine what actions are taken based on that asserted information. In BONDI we do have roles for the author and distributor signatures, and an implementation may perform specific actions based on the signatures that are provided. But, as Thomas says, the PC spec should confine itself to defining how a Widget Resource encodes the signature(s), and say something about what is being asserted, and by who. The author is simply some entity that has signed the Widget Resource, who is content to be identified as the creator or the originator of the content. Thanks - Paddy
RE: [BONDI Architecture Security] [widgets] Author
Hi Paddy, All, This seems to be the summary of the discussion and material that was specified till now: 1. PC says: An author signature is intended to be generated by the author of a widget (i.e., the person who authored the widget). i.e. author is a person. 2. DigSig says: An author element represents people or an organization attributed with the creation of the widget. i.e. author is a person, people or an organization. 3. The mail conversation pointed out that author is just some distinguished entity and its semantics may be irrelevant for DigSig and PC. So we just have to pick up one definition. Thanks. Kind regards, Marcin From: otsi-arch-sec-ow...@omtp.ieee-isto.org [otsi-arch-sec-ow...@omtp.ieee-isto.org] On Behalf Of Marcin Hanclik [marcin.hanc...@access-company.com] Sent: Friday, March 27, 2009 12:43 AM To: Paddy Byers Cc: Thomas Roessler; Hillebrand, Rainer; marc...@opera.com; public-webapps@w3.org; otsi-arch-...@omtplists.org Subject: RE: [BONDI Architecture Security] [widgets] Author, was: RE: AW: Re: [BONDI Architecture Security] [widgets] new digsig draft Hi Paddy, I agree with your summary, but I have comments to the sequence of conclusions. But, as Thomas says, the PC spec should confine itself to defining how a Widget Resource encodes the signature(s), and say something about what is being asserted, and by who. The author is simply some entity that has signed the Widget Resource, who is content to be identified as the creator or the originator of the content. Agreed. It is just about binding the entities. In BONDI we do have roles for the author and distributor signatures, and an implementation may perform specific actions based on the signatures that are provided. Agreed. The problem I have is that the term author is not defined in DigSig ( and PC defines just the author element). It would be ok to say in the DigSig spec that it is intentional. Author is just some distinguished entity. There may be readers of the W3C specs who do not know about BONDI. Maybe even association of the term author in DigSig with the author element in PC is wrong? Maybe these are 2 different entities? In general my comments are about spec quality. BONDI builds upon W3C Widgets, and not vice-versa. So if there are terms in W3C Widgets that are intentionally left underspecified, let's state that clearly in the spec. Thanks. Kind regards, Marcin From: paddy.by...@gmail.com [paddy.by...@gmail.com] On Behalf Of Paddy Byers [pa...@aplix.co.jp] Sent: Friday, March 27, 2009 12:13 AM To: Marcin Hanclik Cc: Thomas Roessler; Hillebrand, Rainer; marc...@opera.com; public-webapps@w3.org; otsi-arch-...@omtplists.org Subject: Re: [BONDI Architecture Security] [widgets] Author, was: RE: AW: Re: [BONDI Architecture Security] [widgets] new digsig draft Hi, I have been trying to identify the term author in Widget specs. I think we're in danger of getting into details that are irrelevant for the PC specification. This spec should define what information is asserted by the presence of the author and distributor signatures. It is up to a consuming device, possibly defined by some other specification, to determine what actions are taken based on that asserted information. In BONDI we do have roles for the author and distributor signatures, and an implementation may perform specific actions based on the signatures that are provided. But, as Thomas says, the PC spec should confine itself to defining how a Widget Resource encodes the signature(s), and say something about what is being asserted, and by who. The author is simply some entity that has signed the Widget Resource, who is content to be identified as the creator or the originator of the content. Thanks - Paddy 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. 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
