(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 <marc...@opera.com>
An: Hillebrand, Rainer
Cc: WebApps WG <public-webapps@w3.org>; otsi-arch-...@omtplists.org <otsi-arch-...@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.hillebr...@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