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

Hi Marcos, All,

>>Agreed. Can we say "were signed with the same certificate" instead?
If there is a conclusion on the other aspects of this point (discussed in other mails) I would suggest writing:
"were signed with the private key of the key pair whose public key is certified by the same certificate" or similar text,
since "signing with certificate" seems to be a shortcut for experts.

Thanks.

Kind regards,
Marcin
________________________________________
From: OTSI-Arch-Sec-owner@omtp.ieee-isto.org [OTSI-Arch-Sec-owner@omtp.ieee-isto.org] On Behalf Of Marcos Caceres [marcosc@opera.com]
Sent: Thursday, March 26, 2009 4:24 PM
To: Hillebrand, Rainer
Cc: WebApps WG; otsi-arch-sec@omtplists.org
Subject: 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

________________________________________

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 Thursday, 26 March 2009 21:30:50 UTC