W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

RE: [BONDI Architecture & Security] [widgets] new digsig draft

From: Hillebrand, Rainer <Rainer.Hillebrand@t-mobile.net>
Date: Thu, 26 Mar 2009 13:57:29 +0100
Message-ID: <41C7C0F2BC2713438D933052463E9259024A896E@DEMSWBMXSC0104.sv.ad.tmo>
To: <marcosc@opera.com>
Cc: "WebApps WG" <public-webapps@w3.org>, <otsi-arch-sec@omtplists.org>
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.hillebrand@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
Received on Thursday, 26 March 2009 12:58:12 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:30 GMT