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 <marcosc@opera.com>
> An: Hillebrand, Rainer
> Cc: WebApps WG <public-webapps@w3.org>; otsi-arch-sec@omtplists.org <otsi-arch-sec@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.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
>
>
> 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 19:21:48 UTC