Hi Frederick,
I've updated the requirements document wrt the suggestions you have
made.
However, I have not yet included the new requirements as I need to
consider
them a bit more before I do so. Naturally, if we find that things like
expiration and policy association are applicable beyond widgets, I'm
wondering if they should become requirements for XML Dig Sig 2.0?
Inline comments below...
On 1/5/09 10:21 PM, "Frederick Hirsch" <[email protected]>
wrote:
I have some comments on requirements section 4.6, Security and
DIgital
Signatures, editors draft [1], and some concrete suggestions for
changes:
(1) R44 http://dev.w3.org/2006/waf/widgets-reqs/#r44.-
This requirement is unclear. Is the intent to say that a signature
associated with a widget package might be extracted and served to a
client independently of the package, allowing the package to be
delivered without the signature inside of it?
Or is it saying that the certificate chain and/or revocation
information should be able to be accessed independently of the
package?
In general it might not make sense to validate a signature without
access the widget content, since that is not meaningful unless it is
possible to validate the content hashes used to generate and validate
the signature.
Simplified the requirement (see my response to Art).
(2) R45 http://dev.w3.org/2006/waf/widgets-reqs/#r45.-
It would be useful to add a sentence as to why SHA-1 is still
required, e.g. "Continued SHA-1 support is recommended to enable
backward compatibility and interoperability".
I've added the text above to the rationale.
On the other hand if the widget specification has not yet been
adopted, is there a reason not to require SHA-256 (and make SHA-1
optional), given the known potential weaknesses with SHA-1?
Suggestion: replace "MUST strongly recommend the use of SHA-256" to
"MUST recommend SHA-256 for new signature generation and must
recommend SHA-1 and SHA-256 for signature verification" (or
explicitly
note that SHA-1 is optional)
"strongly recommend" is not a normative phrase according to RFC 2119.
I reworded the requirement using your recommended text.
(3) R46 http://dev.w3.org/2006/waf/widgets-reqs/#r46.-
Change "and" to "or" in the first sentence and "or" to "and" in the
second to obtain the intended meaning.
Fixed.
(4) R49 http://dev.w3.org/2006/waf/widgets-reqs/#r49.-
The phrase "To provide up-to-date" is misleading, since cached
information may be less up to date than the result of an online
query,
especially with OCSP.
Agreed.
Suggest changing rationale paragraph to
"To enable a widget to obtain revocation information without having
to
query an online CRL or OSCP server from each device. This is a lot
more efficient and eases the load on CRL or OCSP servers. Note,
however, that the revocation information may not be as up to date as
an online query. However, if this information is updated at the
server
in a timely manner before widget installations, then an online query
would not be necessary at the client."
New rationale seems good. Added your text, but with some minor
editorial
changes.
(5) Missing requirement: "A signature should indicate the role of the
signer."
Suggested text "A signature may be signed by a widget author as well
as a widget distributor. The role of the signer should be indicated
to
enable the verifier to understand the role of the signer and
associated implications."
We have been bouncing the idea around of having an "author.sig"
resource
inside the package to overcome this issue. However, this is a more
elegant
solution. Again, would this be something useful for XML Dig Sig 2.0?
(6) Missing requirement: "A signature should indicate a policy
associated with it, independent of information associated with key or
certificate information"
For example, a signature should have a usage (or policy) property
indicating that it is associated with the W3C Widget Signature
specification and processing rules. The use of a URL is recommended
to
allow different policies and to enable updated versions.
I support this requirement. Can you give me an (XML) example of what
this
might look like?
(7) Missing requirement: "Widget packages only require signature
validation and certificate and revocation verification upon first
installation on a device"
Proposed text:
"A widget package signature is validated and associated certificates
and revocation information verified, only when the widget is first
installed on the device. Signatures and certificate and revocation
information may be updated over time at the server for subsequent
installation on other devices, effectively creating a new widget
package."
This seems reasonable, tough a little like an implementation detail.
However, I'm happy to include this requirement.
(8) Missing requirement - "Widget signatures must include counter-
measures against use of out of date widget packages"
Since a signature is validated upon widget installation, and this
signature (and associated certificate and revocation information) can
be updated before subsequent widget installations, it is important
that an old signature cannot be re-used (replayed), since that would
cause updated certificate and revocation information to be ignored.
Thus a signature should have material to avoid later inappropriate
reuse - such as a short-lived expiration of the signature.
Note that a nonce and timestamp, as used for replay attack
mitigation,
may not be suitable since the client may never have installed the
widget previously and not have access to earlier nonce information.
This also sounds worth while. However, this again sounds like a
general
problem. I'm OK for Widgets Dig Sig to be the guinea pig of
solutions to
thwart such replay attacks, but would eventually like to see such
things
become part of XML Dig Sig 2.0.
Kind regards,
Marcos
