Thanks Frederick!
-----Original Message-----
From: Frederick Hirsch [mailto:[email protected]]
Sent: 22 April 2009 23:20
To: Priestley, Mark, VF-Group
Cc: Frederick Hirsch; [email protected]; Barstow Art (Nokia-CIC/
Boston);
public-webapps
Subject: Re: [widgets] New WD of Widgets 1.0: Digital Signatures spec
published on March 31
I think the following items are fine and will add them to the spec:
Signing parties are expected to ensure that the dsp:Identifier
signature
property value is unique for the widgets that they sign" 5.5 and 7.2
I don't think there is anything else, though we need to check the
blogs
and also to see if any new mistakes have been introduced.
regards, Frederick
Frederick Hirsch
Nokia
On Apr 22, 2009, at 5:53 PM, ext Priestley, Mark, VF-Group wrote:
Thanks Frederick and Marcos - responses inline.
Only a couple of questions left :)
Regards,
Mark
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Marcos Caceres
Sent: 22 April 2009 11:46
To: Frederick Hirsch; Priestley, Mark, VF-Group
Cc: Barstow Art (Nokia-CIC/Boston); public-webapps
Subject: Re: [widgets] New WD of Widgets 1.0: Digital Signatures spec
published on March 31
On Tue, Apr 21, 2009 at 11:14 PM, Frederick Hirsch
<[email protected]
wrote:
Mark
Please find responses inline. Thanks for the review.
regards, Frederick
Frederick Hirsch
Nokia
On Apr 7, 2009, at 2:27 AM, ext Priestley, Mark, VF-Group wrote:
Hi Art, All,
Please find below my editorial comments and requests for
clarifications based on the new WD [1]. While it is a long list the
comments are all minor and so hopefully easily addressed. Overall I
think the spec is looking good, for which a lot of thanks must go
to
Frederick and Marcos!
That said, I have a couple of more substantive comments that I will
send in the next couple of days.
Many thanks,
Mark
[1] http://www.w3.org/TR/2009/WD-widgets-digsig-20090331/
-----
COMMENTS
-----
1.0
"A widget package can be signed by the author of the widget
producing an [XMLDSIG11] signature that cryptographically includes
all of the file entries other than signature files. A widget
package
can also be signed by one or more distributors, with XML signatures
that each cryptographically includes all of the non-signature file
entries as well as any author signature."
Change the last sentence for consistency between definitions, ie:
"... A widget package can also be signed by one or more
distributors
<change> of the widget, producing [XMLDSIG11] </change> signatures
that each cryptographically includes all of the non-signature file
entries as well as any author signature."
ok
[mp] Thanks
-----
Can we remove the following sentence? This is a general property of
signatures which I'm not sure we need to include.
"Digitally signing implies use of private key material only known
by
the signer, thus enabling verification of integrity and signature
source."
ok
[mp] Thanks
-----
1.1
We don't actually define any XML elements in the
"http://www.w3.org/ns/widgets-digsig"; namespace... is this worth
noting this and/or removing the "wsig" prefix?
We define URIs using this namespace so we should keep the URI
definition.
ok with removing prefix since it is not used now but would prefer to
keep to avoid errors later. Not a big issue to remove though.
[mp] I'm OK either way.
-----
The terms "XML elements" and "resources" seem to be used
interchangeably? Is there a difference?
yes, one is xml elements others are resources as referenced by URI
Mark, I'm worried you asked this question? Is there confusion
somewhere wrt to the use resource and xml elements?
[mp] No, it's mostly a case of me needing to read the text more
carefully! My confusion was caused by the fact we only define the
namespace prefixes that we use in throughout the spec in the context
of resources.
-----
"Algorithms used by XML Security are defined in a number of
places..." - could we tighten up this sentence, eg something like
"This specification references algorithms defined in [XMLSecAlgs]
and [XMLDSIG11]" ?
No, XMLSecAlgs does not define the algs. There are defined in a
number of places :)
OK - my concern was just that [XMLSecAlgs] cross references lots of
algorithms that we don't need but happy to leave as it is.
-----
1.2
"compressed (or Stored)" - either remove capitalisation of Stored
or
add it to compressed
I suggest "stored". Marcos?
Stored should probably be [Stored], with a reference to the RFC for
the algorithm.
[mp] OK for me
-----
"physical file" -> file ?
Marcos? ok with file personally
Agree.
[mp] Thanks
-----
"top-most path level" - is there a better way of saying this?
don't think so unless you have a proposal without using the word
"root"
I know it's nasty, but people understand it. Lets play wordsmith only
once we have all the tech stuff solved.
[mp] As I can't think of anything better, happy to leave as is.
-----
"which MAY logically contain" - if the configuration file is made
mandatory then the MAY should be a MUST
I think it is a MAY, others?
Technically, Mark is correct. But leave it as a MAY (or maybe drop
MAY
altogether) because this spec does not put conformance criteria on
packaging.
[mp] proposal "of the widget package, which logically contain one or
more file entries, as defined"
Note that reading this again - if a file entry is a file or a folder,
then there must be at least one file entry unless the widget is an
empty package (and if it's signed it can't be empty because at a
minimum there would be a signature file entry!) so I think one one or
more is correct.
-----
Question: is a file entry the same as a file? If so then we should
always use "file entry" in place of "file". If not then perhaps we
should define file?
I don't think they are the same. This is a P&C question. Marcos?
Depends. A file entry is the representation of file data in a zip
archive. A file is a physical uncompressed file as would appear on
disk. If we assume that signatures will act on physical files, it
will
be correct to talk about "files".
[mp] OK, makes sense.
-----
"(i.e., a third party that is distributing the widget on behalf of
the author)." - in some cases the author may also be (one of) the
distributor(s). suggest changing "i.e." to "e.g."
I think i.e. is correct. In the case you suggest they just happen to
be the same entity fulfilling two roles.
[mp] OK
-----
3
"As well as sections marked as non-normative, examples and notes in
this specification are non-normative. Everything else in this
specification is normative. The security considerations section is
non-normative."
Suggest change to the following for readability:
"As well as sections marked as non-normative, the examples and
notes, and security considerations in this specification are
non-normative.
Everything else in this specification is normative."
yes, better.
[mp] thanks
-----
4
"This section defines how to locate digital signatures in a widget
package for processing. An implementation MUST achieve the same
result as the following algorithm used to locate digital signatures
in a widget package:"
In the sentence above, change "digital signatures" to "signature
files"
(in both cases)
ok
[mp] Thanks
-----
"This MAY be determined by the security policy used by the user
agent."
Can we say will or, better yet, SHOULD or MUST? Otherwise, what do
we mean when we say MAY? Who (what) else may enforce security
policy?
we mean may since security policy is out of scope. How can we
mandate
what is not defined?
[mp] Well if we think of security policy in the broadest sense, any
decision of which signatures to process is part of the security
policy. The UA has to do something! Changing "used" to "enforced"
could make it clearer. Alternatively simply deleting the sentence
would work.
-----
"Thus the highest numbered distributor signature would be validated
first."
Change to:
"Thus in the case that one or more distributor signatures were
validated, the highest numbered distributor signature would be
validated first."
ok
[mp] Thanks
-----
5.1
"A widget package MAY be digitally signed using XML Signature
[XMLDSIG11]."
don't we mean:
"A widget package MAY be digitally signed using the profile of XML
Signature [XMLDSIG11] defined by this specification." ?
ok
[mp] Thanks
-----
As this section is talking about generating a signature, I suggest
that we remove "and validated" in the following sentence:
"Each signature file MUST be generated and validated in"
No - 6.1 applies to both generation and validation, common to both.
[mp] You're right - my mistake
-----
5.2
As per previous email exchange we need to re-work author signature
definition
-----
"zero or one author signatures." - remove final "s"
No, I think that the current is correct grammatical usage and clear
in meaning.
[mp] OK
-----
"This represents the digital signature of the author of the widget
package."
add "signature file" ie "This signature file represents the digital
signature of the author of the widget package."
ok
[mp] Thanks
-----
5.3
"This represents the digital signature of a distributor of the
widget package."
add "signature file" ie "This signature file represents the digital
signature of a distributor of the widget package."
ok
[mp] Thanks
-----
5.3.1
"Within a widget package these signature files MUST be ordered
based
on the numeric portion of the signature file name.
Thus, for example, signature2.xml precedes signature11.xml."
Question: what does this mean? What is it requiring from a widget
package?
-----
5.4
"Implementations MUST be prepared to accept X.509 v3 certificates
[RFC5280]."
Can we say "User agents" rather than implementations
we mean implementations
[mp] OK - but we earlier say "A user agent is an implementation that
attempts to support this specification." Therefore isn't a UA also an
implementation?
-----
5.5
"It MUST be unique for a given signer."
Do we need to make it clear that we are not expecting the UA to
check this? I take it we're not asking the UA to check this, right?
What do you suggest we say?
[mp] Proposal: "Signing parties are expected to ensure that the
dsp:Identifier signature property value is unique for the widgets
that
they sign"
-----
7.1
"Each ds:Signature property" -> "Each ds:SignatureProperty" ?
meant as written since wanted to be clear about properties as
opposed
to XML representation.
[mp] OK
-----
In step 5 there is no bullet for digest algorithms, which there
probably should be.
I believe digest algorithms are mentioned for ds:References for the
digesting of content, but not needed in step 5 since the signature
method includes the digest method (eg RSAwithSHA256)
[mp] OK - digest algorithms are covered in 3.b.
-----
7.2
"This MUST be a unique signing string for all signature files
created by the signer." - same comment as 5.5. ie - Do we need to
make it clear that we are not expecting the UA to check this?
What do you suggest we say?
[mp] Proposal (as above): "Signing parties are expected to ensure
that
the dsp:Identifier signature property value is unique for the widgets
that they sign"
-----
7.3
"If signature file validation fails for any reason, any external
entities (e.g., a user agent that implements [Widgets Packaging])
relying on the validation of the signature file MUST be notified of
the failure..."
Maybe we should say that notification of successful validation must
also be provided?
Add before the last paragraph?:
If signature validation is successful any external entities (e.g., a
user agent that implements [Widgets Packaging]) relying on the
validation of the signature file MUST be notified of the success.
[mp] Perfect - thanks
-----
8
"A signature file may also be renamed, which can affect
processing."
suggest modification to "...which can affect the order in which
distributor signatures are processed"
ok
[mp] Thanks
-----
9.1.1
"Upon signature generation, if this property is used, the value is
set to ..."
Is inconsistent with the sentence from 5.1 which states:
"Each signature file MUST contain a dsp:Identifier signature
properties element compliant with XML Signature Properties
[XMLDSIG-Properties] and this specification."
this is not inconsistent. Section 9 says if used, section 5.1 says
it
is used in the profile...
Suggest deletion of ", if this property is used," from the first
sentence
I do not think I understand the rationale for this change.
[mp] It was meant to remove the inconsistency, however, re-reading
the
intro to section 9 (which I managed to skip even though it's in bold,
red text) I realise that this section is to be removed from the
Widget
1.0: Digital Signatures specification, so there is no inconsistency.
My mistake.
-----
9.1.2
"Profiles MUST specify details of the identifier property value
creation and interpretation." What does "Profiles" mean in this
sentence
the widgets signature specification is a profile...
[mp] See above comment - my mistake
-----
"If multiple instances of this property are found on a single
signature, then applications MUST NOT deem any of these properties
valid." - which would in turn mean that the signature was invalid,
right? We may want to state this?
the properties are not valid though the signature still might be
valid.
Interpretation of properties is profile dependent.
[mp] and again, based on a misunderstanding of why this text was
included.
-----
9.2
Note that the same comments may apply to 9.2.1 and 9.2.2 dependent
on the discussions on the mandatory/optional status of this
property.
same answers as for 9.1.2
[mp] and same response - my error
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Arthur Barstow
Sent: 02 April 2009 17:21
To: public-webapps
Subject: [widgets] New WD of Widgets 1.0: Digital Signatures spec
published on March 31
On March 31 a new WD of the Widgets 1.0 Digital Signature spec was
published and announced on the W3C's home page:
[[
2009-03-31: The Web Applications Working Group has published a
Working Draft of Widgets 1.0: Digital Signatures. This document
defines a profile of the XML Signature Syntax and Processing 1.1
specification to allow a widget package to be digitally signed.
Widget authors and distributors can digitally sign widgets as a
trust and quality assurance mechanism. Prior to instantiation, a
user agent can use the digital signature to verify the integrity
of
the widget package and perform source authentication. This
document
specifies conformance requirements on both widget packages and
user
agents.
]]
Please review this new WD as soon as possible, preferably within
the next two weeks:
<http://www.w3.org/TR/2009/WD-widgets-digsig-20090331/>
-Regards, Art Barstow
--
Marcos Caceres
http://datadriven.com.au
