W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: [widgets] Dig Sig review in prep for LC

From: Marcos Caceres <marcosc@opera.com>
Date: Wed, 29 Apr 2009 15:06:14 +0200
Message-ID: <b21a10670904290606k2a351faeq392160818577ccde@mail.gmail.com>
To: Frederick Hirsch <frederick.hirsch@nokia.com>
Cc: public-webapps <public-webapps@w3.org>
Hi,
I support all the recommendations/rejections below.

Kind regards,
Marcos

On Wed, Apr 29, 2009 at 2:42 PM, Frederick Hirsch
<frederick.hirsch@nokia.com> wrote:
> comments inline, including proposals. thanks for the review
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
>
> On Apr 29, 2009, at 4:01 AM, ext Marcos Caceres wrote:
>
>> Hi Frederick,
>> Some tiny editorial changes....
>>
>> I think we should add the following sub-section to the Status of This
>> Document:
>>
>> [[
>> <h3 class="no-num no-toc">Note to Last Call Reviewers</h3>
>> <p><em>This section is non-normative.</em></p>
>> <p>The editors of this specification respond rapidly to all feedback
>> and continuously make corrections to this document. Unless you are
>> reading this document on the date of publication, <strong
>> class="redNote">it is extremely  likely that this document has been
>> superseded</strong>. Instead of reviewing this published draft, please
>> review the <a href="http://dev.w3.org/2006/waf/widgets-digsig/">latest
>> editor's draft</a> and make sure to cite the date of that draft in the
>> feedback sent to the Web Apps Working Group's public mailing list <a
>> href=
>> "mailto:public-webapps@w3.org">public-Webapps@w3.org</a>. </p>
>> <p>Please also be sure to check the mailing list <a href=
>> "http://lists.w3.org/Archives/Public/public-webapps/">archive</a> to
>> see if any issues uncovered have already been addressed. To help with
>> cataloging issues, prefix emails to the mailing list with the string
>> <samp>[widgets]</samp>. Any and all feedback is welcomed.</p>
>> ]]
>>
> I think we should use standard last call boilerplate. If it isn't ready for
> last call then maybe we should wait.
>
>>
>> Section 1.1
>> Namespace prefix "wsig:" > "wsig"
>>
>
> I think wsig: is clearer to the reader so would not like to do this one.
>
>> Section 1.3
>> "to the term definition" > "to where the term is defined".
>>
> ok
>
>> 2.0
>> "are addressed in the Widgets 1.0 Requirements [Widgets Requirements]
>> document."
>> ->
>> are addressed in the Widgets 1.0 Requirements document [Widgets
>> Requirements].
>>
> ok
>
>> 3.0
>> "security critical mechanism"
>> Can we include a concrete example of such a thing? I'm not sure what a
>> security critical mechanism is.
>>
>
> I suggest we remove "Trust in a certificate is established through a
> security critical mechanism implemented by the user agent, which is out of
> scope for this specification."
>
> Mark, do you have a better suggestion?
>
>> 4.0
>> Step 6
>> "Numerical order is" -> "<dfn>Numerical order</dfn> is"
>>
>> The numerical order is really relevant to processing. I think we
>> should move this paragraph and proceeding paragraph to the top of
>> section 4.0. Their importance is kind of lost where they are right
>> now.
>>
> there are only 7 steps, less than a page. I doubt it will get lost. I
> suggest leaving this alone. ok with dfn.
>
>> 5.1
>> "profile of XML Signature [XMLDSIG11] defined by this specification."
>> ->
>> "profile of  [XMLDSIG11] defined by this specification."
>>
>>
>
> I think  the english "XML Signature" which I though makes it more readable.
> I guess we have different styles in mind, I prefer english + Reference,
> alternative is reference only. I can make this change for consistency.
>
>
>> "contain a dsp:Profile signature properties element compliant with XML
>> Signature Properties [XMLDSIG-Properties] and this specification."
>> ->
>> "contain a dsp:Profile element compliant with the [XMLDSIG-Properties]
>> specification and this specification."
>
> ok, highlighting term
>
>>
>>
>> 5.5
>> "The dsp:Identifier signature property is intended to be used to
>> uniquely identify the signature to enable signature management. "
>>
>> Who is the subject in this sentence? I.e., used by who? publishers?
>> the UA? users? I think that needs to be made clear.
>>
>
> how about
>
> The signer uses the dsp:Identifier signature property to
> uniquely identify the signature to enable signature management.
>
> (you don't like passive voice? :)
>
>
>
>> "value is unique for the widgets that they sign."
>>>
>> "value is unique for the widget packages that they sign."
>>
>>
>
>
> ok
>
>> 6.1
>> "Signatures generated using key lengths of less than 2048 bits SHOULD
>> NOT be used unless the life time of the signature is less than one
>> year."
>>
>> Again, it is not clear to me who "SHOULD NOT be used" is directed at?
>> should not be used by the UA?
>>
>
> The signer  SHOULD NOT generate signatures using key lengths of less than
> 2048 bits unless the life time of the signature is less than one year.
>
> By the way, shouldn't this be a MUST NOT?
>
>
>> Kind regards,
>> Marcos
>
> thanks
>
>>
>> --
>> Marcos Caceres
>> http://datadriven.com.au
>>
>
>
>



-- 
Marcos Caceres
http://datadriven.com.au
Received on Wednesday, 29 April 2009 13:07:11 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:31 GMT