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."
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.hanc...@access-company.com
-----Original Message-----
From: Frederick Hirsch [mailto:frederick.hir...@nokia.com]
Sent: Friday, March 27, 2009 2:09 PM
To: Marcin Hanclik
Cc: Frederick Hirsch; marc...@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.hanc...@access-company.com
-----Original Message-----
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org
] On Behalf Of Marcin Hanclik
Sent: Thursday, March 26, 2009 8:42 PM
To: marc...@opera.com; WebApps WG; otsi-arch-...@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.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 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.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 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.
