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

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

From: Frederick Hirsch <Frederick.Hirsch@nokia.com>
Date: Fri, 27 Mar 2009 09:48:06 -0400
Cc: Frederick Hirsch <Frederick.Hirsch@nokia.com>, "marcosc@opera.com Caceres" <marcosc@opera.com>, WebApps WG <public-webapps@w3.org>
Message-Id: <2E5A7475-7660-4169-A309-D16362AFB68F@nokia.com>
To: ext Marcin Hanclik <Marcin.Hanclik@access-company.com>
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.hanclik@access-company.com
>
> -----Original Message-----
> From: Frederick Hirsch [mailto:frederick.hirsch@nokia.com]
> Sent: Friday, March 27, 2009 2:09 PM
> To: Marcin Hanclik
> Cc: Frederick Hirsch; marcosc@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 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.hanclik@access-company.com
>>
>> -----Original Message-----
>> From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org
>> ] On Behalf Of Marcin Hanclik
>> Sent: Thursday, March 26, 2009 8:42 PM
>> To: marcosc@opera.com; WebApps WG; otsi-arch-sec@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.hanclik@access-company.com
>>
>> -----Original Message-----
>> From: OTSI-Arch-Sec-owner@omtp.ieee-isto.org [mailto:OTSI-Arch-Sec-owner@omtp.ieee-isto.org
>> ] On Behalf Of Marcin Hanclik
>> Sent: Thursday, March 26, 2009 7:05 PM
>> To: marcosc@opera.com; WebApps WG; otsi-arch-sec@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 unified between
>> DigSig and P&C? 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 P&C (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 P&C:
>> 1. RFC 2119 terms are in lower-case in P&C, 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.hanclik@access-company.com
>>
>> -----Original Message-----
>> From: OTSI-Arch-Sec-owner@omtp.ieee-isto.org [mailto:OTSI-Arch-Sec-owner@omtp.ieee-isto.org
>> ] On Behalf Of Marcos Caceres
>> Sent: Wednesday, March 25, 2009 4:42 PM
>> To: WebApps WG; otsi-arch-sec@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 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 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 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 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.
Received on Friday, 27 March 2009 13:49:12 GMT

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