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

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

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Wed, 29 Apr 2009 08:42:15 -0400
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, public-webapps <public-webapps@w3.org>
Message-Id: <F1CF645F-5532-47CE-964C-2C7322CB509F@nokia.com>
To: "marcosc@opera.com" <marcosc@opera.com>
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
>
Received on Wednesday, 29 April 2009 12:43:38 GMT

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