Hi Frederick,
I support the changes below. They are all editorial in nature.

Kind regards,
Marcos

On Fri, Mar 27, 2009 at 6:26 PM, Hillebrand, Rainer
<[email protected]> wrote:
> Dear Marcos,
>
> I hope to have less critical comments than in my last feedback email.
>
> 1. Section 7.1: change "The ds:SignatureMethod algorithm used in the 
> ds:SignatureValue element MUST one of the signature algorithms." to "The 
> ds:SignatureMethod algorithm used in the ds:SignatureValue element MUST be 
> one of the signature algorithms."
>
> 2. Section 7.1: "The ds:KeyInfo element MAY be included and MAY include 
> certificate, CRL and/or OCSP information.": CRL and OCSP are not defined 
> before. Do you have a reference for these abbreviations?
>
> 3. Section 7.3: "The set of acceptable trust anchors, and policy decisions 
> based on the signer's identity are established through a security-critical 
> out-of-band mechanism." I do not really understand this sentence. This is not 
> subject for the processing rules, isn't it? What is an acceptable trust 
> anchor? Are they really established or may they be established?
>
> 4. Section 8: change "Care should be taken to avoid resource exhaustion 
> attacks through maliciously crafted Widget archives during signature 
> verification." to "Care should be taken to avoid resource exhaustion attacks 
> through maliciously crafted [widget package]s during signature validation."
>
> 5. Section 8: change "Implementations should be careful about trusting path 
> components found in the zip archive" to "Implementations should be careful 
> about trusting path components found in the [widget package]"
>
> 6. Section 8: change "and naive unpacking of widget archives into" to "and 
> naive unpacking of [widget package]s into"
>
> 7. Section 8: change "e.g., overwriting of startup or system files" to "e.g. 
> overwriting of startup or system files"
>
> 8. Section 8: change "There is no single signature file that includes all 
> contents of a widget, including all of the signatures." to "There is no 
> single signature file that includes all files of a [widget package], 
> including all of the signature files."
>
> 9. Section 8: change "This leaves a widget package subject to an attack where 
> distributor signatures can be removed (and an author signature if any 
> corresponding distributor signature is also removed), or added." to "This 
> leaves a widget package subject to an attack where distributor signatures can 
> be removed or added. An author signature could also be attacked by removing 
> it and any distributor signatures if they are present."
>
> Best Regards,
>
> Rainer
>
> *************************************
> T-Mobile International
> Terminal Technology
> Rainer Hillebrand
> Head of Terminal Security
> Landgrabenweg 151, D-53227 Bonn
> Germany
>
> +49 171 5211056 (My T-Mobile)
> +49 228 936 13916 (Tel.)
> +49 228 936 18406 (Fax)
> E-Mail: [email protected]
>
> http://www.t-mobile.net
>
> This e-mail and any attachment are confidential and may be privileged. If you 
> are not the intended recipient, notify the sender immediately, destroy all 
> copies from your system and do not disclose or use the information for any 
> purpose.
>
> Diese E-Mail inklusive aller Anhänge ist vertraulich und könnte 
> bevorrechtigtem Schutz unterliegen. Wenn Sie nicht der beabsichtigte Adressat 
> sind, informieren Sie bitte den Absender unverzüglich, löschen Sie alle 
> Kopien von Ihrem System und veröffentlichen Sie oder nutzen Sie die 
> Information keinesfalls, gleich zu welchem Zweck.
>
>
> 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
>
>



-- 
Marcos Caceres
http://datadriven.com.au

Reply via email to