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

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

From: Marcos Caceres <marcosc@opera.com>
Date: Thu, 26 Mar 2009 16:24:22 +0100
Message-ID: <b21a10670903260824n2e4cfe81y272f1c468e83d3e2@mail.gmail.com>
To: "Hillebrand, Rainer" <Rainer.Hillebrand@t-mobile.net>
Cc: WebApps WG <public-webapps@w3.org>, otsi-arch-sec@omtplists.org
Hi Rainer,

On Thu, Mar 26, 2009 at 1:57 PM, Hillebrand, Rainer
<Rainer.Hillebrand@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 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.
>

Agreed. Can we say "were signed with the same certificate" instead?

> 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."
>

fixed.

> More change proposals may come tomorrow (if identified tomorrow).

Thanks for taking the time to do the review!!!

Kind regards,
Marcos
-- 
Marcos Caceres
http://datadriven.com.au
Received on Thursday, 26 March 2009 15:25:22 GMT

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