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

Re: [widgets] Dig Sig spec

From: Marcos Caceres <marcosscaceres@gmail.com>
Date: Wed, 11 May 2011 13:40:12 +0200
Message-ID: <BANLkTimKuz6-vTFPSv2BU13xp_GFVfXOMg@mail.gmail.com>
To: Frederick.Hirsch@nokia.com
Cc: Art.Barstow@nokia.com, public-webapps@w3.org
On Mon, May 2, 2011 at 5:25 PM, Marcos Caceres <marcosscaceres@gmail.com> wrote:
>
> On Friday, April 29, 2011 at 8:19 PM, Frederick.Hirsch@nokia.com wrote:
>> Marcos
>>
>> I'd suggest you first send an email with the top 10 substantive changes to the list, e.g. which algorithms change from mandatory to optional or optional to mandatory etc, which processing rules you are relaxing, etc
>>
>> this would take less time for you and be much clearer to all.
>
> I could only come up with 5... as I previously mentioned, the spec just contained a ton of redundancies (4 pages worth), but the conformance requirements are all pretty much the same.
>
> The draft is up at:
> http://dev.w3.org/2006/waf/widgets-digsig/
>
> As I previously stated, the purpose of this fix up was to make concessions for WAC 1.0 runtimes, which use the default canonicalization algorithm of XML Dig Sig 1.1. Additional changes are based on working with various vendors who implemented the WAC 1 or are working on the WAC 2 specs (including the implementation that was done at Opera).
>

I've made C14N11 the recommended canonicalization method throughout.
However, user agents are free to use whatever they want so long as it
complies to XML Dig Sig 1.1.

> 1. Validator and signers are now true [XMLDSIG11] implementations. No exceptions. This means that the test suite can be greatly reduced because everything is palmed off to [XMLDSIG11]. There is now a clear separation between a signer and validator, meaning that the "implementation" product is no longer needed.
>
> 2. Validators and signers now rely on [Signature Properties] for generation and validation of signature properties (as it should have been from the start). This removes a bunch of redundant text in the spec. The validation process is now written as an algorithm, as is the signing process. It makes it easy now to generate or validate a signature by simply following the steps. In the old spec, one had to jump all over the spec to check all sorts of things (e..g, Common Constraints for Signature Generation and Validation and the Requirements on Widget Signatures, both which are now folded into the appropriate algorithms). The spec now also links to the right places in [XMLDSIG11] and [Signature Properties].
>

I've added the ability for user agents to optionally support all
signature properties (i.e., a signer can include them, and a validator
can validate them, if they want).

> 3. The specification now only RECOMMENDs algorithms, key lengths, and certificate formats. Validators are no longer forced fail on certain certificate formats or algorithm. The only exception is the minimum key lengths, which are still enforced during verification (impossible to test during signing, without verifying, so the requirement is kinda useless).
>
> 4. The specification strengthens the recommended key lengths to be a little bit stronger (buy a few more years).
>
> 5. The spec now only contains 3 conformance criteria.
>
> [
> To digitally sign the contents of a widget package with an author signature, a signer MUST run the algorithm to generate a digital signature.
>
> To digitally sign the contents of a widget package with a distributor signature, a signer MUST run the algorithm to generate a digital signature.
>
> To validate the siganture files of a widget package, a validator MUST run the algorithm to validate digital signatures.
> ]

I've condensed it down to just two conformance requirements by merging
the two signing requirements into 1:

"To digitally sign the contents of a widget package with an author
signature or with a distributor signature, a signer MUST run the
algorithm to generate a digital signature."


-- 
Marcos Caceres
http://datadriven.com.au
Received on Wednesday, 11 May 2011 11:41:01 GMT

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