Re: Comments on Widgets 1.0 Security requirements

Hi Frederick, Mark,

On 1/7/09 6:36 PM, "Frederick Hirsch" <frederick.hirsch@nokia.com> wrote:

> 
> Mark
> 
> Some more discussion inline, thanks for taking the time to review.
> 
> Do you mind updating the draft with the items we agree?
> 
> regards, Frederick
> 
> Frederick Hirsch
> Nokia
> 
> 
> 
> On Jan 7, 2009, at 11:03 AM, ext Priestley, Mark, VF-Group wrote:
> 
>> Hi Frederick,
>> 
>> Thanks for your comments. As someone who had a hand in some of the
>> requirements that you've commented on, please see some responses
>> inline.
>> 
>> Regards,
>> 
>> Mark
>> 
>> -----Original Message-----
>> From: public-webapps-request@w3.org
>> [mailto:public-webapps-request@w3.org] On Behalf Of Frederick Hirsch
>> Sent: 05 January 2009 22:22
>> To: public-webapps
>> Cc: Frederick Hirsch; Thomas Roessler
>> Subject: Comments on Widgets 1.0 Security requirements
>> 
>> 
>> 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.
>> 
>> [MP] Re-reading the requirement I agree we could have been clearer in
>> what we were requiring, which is:
>> 
>> 1. It MUST be possible to extract a _copy_ of the digital signature
>> document(s) from the widget package.
>> 2. It SHOULD (MUST?) be possible for the widget user agent to complete
>> the signature validation processing for a digital signature document
>> that is provided independently of a widget package (noting that the
>> signature is not validated until the reference validation processing
>> has
>> also been successfully completed)
>> 
>> When we write the specification text to meet this requirement we will
>> need to ensure that the error cases are covered, e.g. when the
>> independently supplied and packaged digital signature do not match.
>> 
>> With these clarifications hopefully the requirement and rationale make
>> more sense?
>> 
> 
> Although one can extract a signature XML element from a widget
> package, I'm not sure how meaningful that is if one cannot
> subsequently locate the content that is signed - for example if a
> ds:Reference refers to an item in the widget package, how can an
> extracted signature be validated if that item is no longer available?
> 
> Along similar lines, I might expect the URI for a resource to be
> relative if the signature is always enveloped (the signature is within
> the widget package containing the signature and other items) but
> perhaps a full URL for detached, when the signature is stored
> separately from the signed items.
> 
> I do not think this requirement is met by the Widgets Signature
> document as it states
> "The URI attribute must be a relative path to the root of the widget."
> 
> how will this work with detached signatures where the widget content
> is not in the same context as the signature?
> 
> 
>> 
>> (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".
>> 
>> 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.
>> 
>> [MP] I support your suggested changes.
>> 
> 
> I strongly suggest we require XML Signature 1.1 which should include
> new algorithms and address some practices around their use.

I support this move.

>> (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.
>> 
>> [MP] Well spotted, this is indeed an error - I support your suggested
>> changes
>> 
>> (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.
>> 
>> 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."
>> 
>> [MP] I support your suggested changes; more accurate and clearer
>> 
>> (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."
>> 
>> [MP] I don't object to this requirement but I would be interested in
>> the
>> use case given that we have the author element?
> 
> where is the author element?
> 
>> 
>> 
>> (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.
>> 
>> [MP] I agree with the intent of this requirement but think we need
>> to be
>> clear what we want to specify. What we are really trying to say is
>> that
>> the signature may be processed differently depending on the usage
>> associated to the signature. However, before we specify this text I
>> think we need some further discussion on what the usage properties
>> should be and how they should be specified. For example, is it
>> expected
>> that for each usage property there will be a section in Widgets 1.0:
>> Digital Signatures that defines the processing for that usage property
>> on top of the core processing?
>> 
> 
> I meant something different than what you read, so we may need to be
> clearer.
> 
> I suggest we have a URI that indicates signature conformance to the
> Widgets 1.0 Digital Signature specification.
> 
> I believe you are suggesting additional policy that can vary? If so
> that is a different requirement.

Fwiw, I would not like to go down this path. This would add a lot of
complexity. I would like to see how we go with 1.0 and standardize these
more advanced features if they are really needed in 2.0 or beyond.
 
>> (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."
>> 
>> (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.
>> 
>> [MP] Just so that I am clear, the requirement you are proposing here
>> is
>> that the signature format must support the inclusion of signature
>> expiration data? This expiration data is associated to the signature
>> and
>> not the end-entity certificate used to generate the signature? If this
>> is the proposal I am in full agreement. However, in this case I think
>> that we re-word the proposed text as it currently implies that we are
>> recommending the use of short lived signatures, which is really a
>> security policy decision for the signer.
>> 
>> 
> 
> I was trying to capture the use case and associated requirements -
> that signatures are only verified upon widget installation and can be
> short lived (changed between installations). This is different than
> long term signatures used for legal purposes and more a code signing
> application.
> 
> Yes, I believe an Expires property could satisfy the requirement but
> the requirement is about verification upon install and not allowing
> inappropriate reuse of widget packages.
> 

Again, fwiw, this all sounds good to me.

Received on Monday, 19 January 2009 20:50:31 UTC