Re: [Widgets requirements]

The problem I see with encrypting content is that you'll need to use  
a shared secret. That secret will be in the source code of the widget  
runner. This is something that I know our security peeps would have  
an issue with. This is actually the main reason we don't have any  
true encryption in our stuff to date. Does anyone know a good way to  
pull this off with no shared secrets?

-- Ed

On Dec 23, 2006, at 6:50 PM, Marcos Caceres wrote:

>
> Hi all,
> The Widgets requirements documents [1] has been updated. Highlights:
>
> New requirements
> ~~~~~~~~~~~~~
>
> R8 Digital Signature
> The packaging format should allow authors to digitally sign their
> packaged applications so that a user can verify the authenticity and
> the integrity of the package, as well as provide some means for
> non-repudiation.
>
> Motivation:
>    Security, current development practice or industry best-practices.
>
> R9. Encryption
> The packaging format may include one or more resources that describe
> encryption methods used to encrypt particular resources within the
> package.
>
> Motivation:
>    Security, current development practice or industry best-practices.
>
> New text in the introduction:
> ~~~~~~~~~~~~~~~~~~~~
>
> In some cases, authors may choose to digitally sign a package as a
> more secure means of distribution and deployment. A digitally signed
> package provides users with a means to verify the authenticity and the
> integrity of a package, as well as giving a user a degree of support
> for non-repudiation. Users can verify the authenticity of a package by
> decrypting an encrypted hash of the content (known as a digest) using
> an author's public key; theoretically, only an author's public key
> should be able to decrypt the digest. Users can then check the
> integrity of a package by checking the hash of the package against an
> encrypted digest for equality. If the values do not match, then it is
> likely that the file is either corrupt or someone has tampered with
> the contents of the package after the author signed it.
> Non-repudiation refers to the fact that a digital signature makes it
> difficult for an author to deny signing the contents of a package as
> only the author should have access to the private key used to create
> the digital signature. An author may also include in the package a
> digital certificate, which they obtain from a Certification Authority
> (CA), that a user can use to further verify the authenticity of the
> author and the package.
>
> An author may choose to encrypt particular resources within the
> package without affecting the ability for the application to run. For
> instance, the author may choose to encrypt source code or any
> resources they want to keep secure. It should be noted that encrypting
> resources is currently not a standard practice in the Widget
> development space, but may become an important requirement as the
> popularity of widgets continues to grow.
> ---
>
> Merry Xmas!
>
> [1] http://dev.w3.org/cvsweb/2006/waf/WAPF/WD-WAPF-REQ-20060726.html
>
>
>
> -- 
> Marcos Caceres
> http://datadriven.com.au
>

Received on Saturday, 30 December 2006 17:11:10 UTC