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

Hi Frederick,

Thanks for your review again.

Thanks for all the corrections.
These are my further comments for dispute.

>>> b) Clarify "file name" in P&C (the definition in DigSig says about
>>> deriving from file name field and it seems strange to me).
>>why? it is the string file name?
P&C defines (or just uses) "file name field" (P&C Section 5.3):
"A Zip relative path is the variable-length string derived from a file name field of a local file header of a file entry."

DigSig refers to P&C and says about "file name" being defined in P&C (and it is not there as above):
"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."

I simply think it could be specified in a better way. I can live with the current definitions, though.

>>> 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."
>>
>>I think I disagree, I think it is helpful to be able to read the
>>widgets spec without constantly referring to P & C (even though they
>>are closely related)
There is no problem to keep the definitions in both specs if the definitions are consistent (or simply the same). But IMHO e.g. "file name" (as above) is not well specified in P&C, thus can be misinterpreted when reading DigSig.

>>numerical order is not implied by ascii sorting, see "02" vs "12" as
>>opposed to "2" and "12", they sort differently if you treat as strings
>>or as numbers because of the leading 0.
Yes, I think we agreed on this already. This was my mistake.

>>No, it should be v3 but other versions are allowed, as noted. I think
>>we should leave this alone.
Agreed.

>>RFC 5280 covers enough doesn't it, PKIX.
Ok, so let's remove reference to X.509 spec and keep only RFC5280. Just for clarity and spec-chaining. I.e.:
"The RECOMMENDED version of the certificate format is X.509 version 3 [X509v3]. Implementations MUST be prepared to accept X.509 v3 certificates [X509v3], [RFC5280]. "
could become
"The RECOMMENDED version of the certificate format is X.509 version 3 as specified in [RFC5280]. Implementations MUST be prepared to accept X.509 v3 certificates [RFC5280]."

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:26 PM
To: Marcin Hanclik
Cc: Frederick Hirsch; marcosc@opera.com Caceres; WebApps WG
Subject: Re: [BONDI Architecture & Security] [widgets] new digsig draft

Marcin


Thanks, for the careful review. some comment inline

[removed cross post, fails anyway]


regards, Frederick

Frederick Hirsch
Nokia



On Mar 26, 2009, at 2:04 PM, ext Marcin Hanclik wrote:

> 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 ..."
>
this is already fixed in the latest draft

> 2. Unify "case sensitive" phrase. There are now both "case-
> sensitive" and "case sensitive" present in the text.
>
ok, lets go with "case-sensitive" since Websters has that.


> 3. Section 1.2: Maybe the common terms could be unified between
> DigSig and P&C? Both specs will probably be always used together.

the goal was to be as clear as possible in widgets signature, and
omitting detail not needed.

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

"root of the widget package", as you corrected in later email
ok

> b) Clarify "file name" in P&C (the definition in DigSig says about
> deriving from file name field and it seems strange to me).
why? it is the string file name?

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

I think I disagree, I think it is helpful to be able to read the
widgets spec without constantly referring to P & C (even though they
are closely related)

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

I see no harm in making it clear

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

numerical order is not implied by ascii sorting, see "02" vs "12" as
opposed to "2" and "12", they sort differently if you treat as strings
or as numbers because of the leading 0.

>
>
> 6. Section 4, item 5: ".. treat this as.." -> what is "this"? I
> suggest to change the text to "... treat this widget package as ..."

ok

>
>
> 7. Section 4, item 6: "Validate the signature files in the
> signatures list" -> "signatures" looks weird, the cause is <var> vs.
> <code> in HTML.

agree.

>
>
> 8. Section 5.3.1: "A file entry whose file name that does not match
> the" -> "that" should be removed

yes, thanks

>
> 9. Section 5.4: identify the X.509 version fully. "The X.509
> certificate format MUST" could become "The X.509v1 certificate
> format MUST"
>
No, it should be v3 but other versions are allowed, as noted. I think
we should leave this alone.

> 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
>
RFC 5280 covers enough doesn't it, PKIX.

> 10. Section 7.2: The time SHOULD reflect the time that signature
> generation completes. -> The time SHOULD reflect the time when
> signature generation completed.
>

ok

> 11. Section 7.3: If present then user agents MUST perform Basic ->
> If present, the user agents MUST perform Basic

ok

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

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

should be upper case.

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

Received on Friday, 27 March 2009 14:28:55 UTC