[widgets] Dig Sig Spec ready for pub

2011-05-23 Thread Marcos Caceres

Hi,
I would like to republish the Widgets Dig Sig specification as LC (in 
preparation for moving it to PR):


http://dev.w3.org/2006/waf/widgets-digsig/

I have also recreated the test suite to match the new specification:

http://dev.w3.org/2006/waf/widgets-digsig/test-suite/

Kind regards,
Marcos



Re: [widgets] Dig Sig Spec ready for pub

2011-05-23 Thread Frederick.Hirsch
Editorial comments, section 9 #4 typo Optionaly, also  formatting in  section 
9 item 3 number 7.

You might want dates for the SIgnature 1.1 and Signature Properties References?

Relying on XML Signature 1.1 for normative algorithm requirements is sensible 
in my personal opinion.

regards, Frederick

Frederick Hirsch
Nokia



On May 23, 2011, at 6:46 AM, ext Marcos Caceres wrote:

 Hi,
 I would like to republish the Widgets Dig Sig specification as LC (in 
 preparation for moving it to PR):
 
 http://dev.w3.org/2006/waf/widgets-digsig/
 
 I have also recreated the test suite to match the new specification:
 
 http://dev.w3.org/2006/waf/widgets-digsig/test-suite/
 
 Kind regards,
 Marcos
 




Re: [widgets] Dig Sig spec

2011-05-11 Thread Marcos Caceres
On Mon, May 2, 2011 at 5:25 PM, Marcos Caceres marcosscace...@gmail.com wrote:

 On Friday, April 29, 2011 at 8:19 PM, frederick.hir...@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



Re: [widgets] Dig Sig spec

2011-05-04 Thread Marcos Caceres

On Tuesday, May 3, 2011 at 12:00 AM, timeless wrote: 
 It's pretty much impossible for me to figure out which things are new
 or which i've missed in previous rounds. (It's also possible that I
 didn't review this spec, in which case, I'm sorry.) I don't believe
 these comments significantly affect the document, i.e. they're mostly
 editorial, although some are technically errors which should
 definitely be fixed.
 
 http://dev.w3.org/2006/waf/widgets-digsig/
 
  A widget package can be digitally signed by an author to produce a 
  signature file
  that cryptographically includes all of the files of a widget package that 
  are not
 
 i don't think includes is right, perhaps covers or attests.
 
Covers it is. 


  A user agent or other entity can use author signature to determine:
 
 use _an_ author

fixed. 
 
  As the following terms are used throughout this specification, they are 
  gathered here for the readers convenience.
 
 reader's

fixed 
 
  A file name is the name of a file contained in a widget package (excludes 
  path information), as defined in the [Widgets Packaging] specification.
 
 probably s/excludes/excluding/
fixed 
 
  Set the a URI attribute for each ds:Reference to be the zip relative path 
  that identifies a file inside the widget package.
 
 drop a
I changed it the fie... just saying file 
   Generate a identifier property in the manner specified in [Signature 
  Properties].
 
 an
fixed 
 
   Serialized the signature as a [UTF-8] encoded [XML] document using the 
  appropriate naming convention depending on its role:
 
 Serialize ? (present tense, action/command v. past tense)
 
Fixed. 
  To validate the siganture files of a widget package, a validator MUST run 
  the algorithm to validate digital signatures.
 
 signature is misspelled
fixed 
 
  terminate this algorithm and treat as an unsigned widget package:
 
 treat _it_ as...

fixed 
 
   Check that signature has a ds:Reference for every file that is not a 
  signature file. If every non-signature file is not included, then signature 
  is in error.
 
 s/every/any/
 s/not included/not listed/
fixed and fixed 
 
   If the role property is missing or or invalid, then signature is in error.
 
 s/or or/or/
fixed 
 
   If all signatures validated successfully, treat this as a signed widget 
  package.
 
 s/validated/validate/

fixed 
 
   Search the root of the widget package for any file name that 
  case-sesitively
 
 sensitively is misspelled
 

Fixed. 
  This implies that, in order to verify a signature file, a user agent need
 
 needs
 

fixed 
  A signature .. does not limit .. decompression and unpacking code used 
  during signature extraction and verification.
 
 This doesn't seem to be a complete thought.

Agreed. This is redundant anyway so I killed it. I just said in the first 
paragraph: the security considerations of [Widget Packaging] also apply to 
this specification. 
 
  A signature file can also be renamed, which can affect the order in which 
  distributor signatures are processed.
 
 This could have been addressed by embedding the signature file name
 into the file, oh well :)
True... oh well. Something for v2, I guess. 
 
  Mechanisms to install new root certificates in a user agent need to be 
  subject to security critical mechanisms.
 
 'security critical mechanisms' doesn't sound right
Agreed. Removed that sentence. Changed the paragraph to: 

 If the user agent supports installing a new root certificate, an end-user 
should be made aware of what they are doing, and why. 

Thanks for the review, Josh! 



Re: [widgets] Dig Sig spec

2011-05-02 Thread Marcos Caceres

On Friday, April 29, 2011 at 8:19 PM, frederick.hir...@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). 

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]. 

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 think everyone will now find this new specification much easier to read, 
implement, and conform to without having in real impact on existing 
implementations. 

Kind regards,
Marcos 





Re: [widgets] Dig Sig spec

2011-05-02 Thread timeless
It's pretty much impossible for me to figure out which things are new
or which i've missed in previous rounds. (It's also possible that I
didn't review this spec, in which case, I'm sorry.) I don't believe
these comments significantly affect the document, i.e. they're mostly
editorial, although some are technically errors which should
definitely be fixed.

http://dev.w3.org/2006/waf/widgets-digsig/

 A widget package can be digitally signed by an author to produce a signature 
 file
 that cryptographically includes all of the files of a widget package that are 
 not

i don't think includes is right, perhaps covers or attests.

 signature files (e.g., HTML files, CSS files, and JavaScript files).


 A user agent or other entity can use author signature to determine:

use _an_ author

 As the following terms are used throughout this specification, they are 
 gathered here for the readers convenience.

reader's

 A file name is the name of a file contained in a widget package (excludes 
 path information), as defined in the [Widgets Packaging] specification.

probably s/excludes/excluding/

 Set the a URI attribute for each ds:Reference to be the zip relative path 
 that identifies a file inside the widget package.

drop a
Generate a identifier property in the manner specified in [Signature 
 Properties].

an

Serialized the signature as a [UTF-8] encoded [XML] document using the 
 appropriate naming convention depending on its role:

Serialize ? (present tense, action/command v. past tense)

 To validate the siganture files of a widget package, a validator MUST run the 
 algorithm to validate digital signatures.

signature is misspelled

 terminate this algorithm and treat as an unsigned widget package:

treat _it_ as...

Check that signature has a ds:Reference for every file that is not a 
 signature file. If every non-signature file is not included, then signature 
 is in error.

s/every/any/
s/not included/not listed/

If the role property is missing or or invalid, then signature is 
 in error.

s/or or/or/

If all signatures validated successfully, treat this as a signed widget 
 package.

s/validated/validate/

Search the root of the widget package for any file name that 
 case-sesitively

sensitively is misspelled

 This implies that, in order to verify a signature file, a user agent need

needs

 A signature .. does not limit .. decompression and unpacking code used during 
 signature extraction and verification.

This doesn't seem to be a complete thought.

 A signature file can also be renamed, which can affect the order in which 
 distributor signatures are processed.

This could have been addressed by embedding the signature file name
into the file, oh well :)

 Mechanisms to install new root certificates in a user agent need to be 
 subject to security critical mechanisms.

'security critical mechanisms' doesn't sound right



Re: [widgets] Dig Sig spec

2011-04-29 Thread Frederick.Hirsch
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.

thanks

regards, Frederick

Frederick Hirsch
Nokia



On Apr 26, 2011, at 8:19 AM, ext Marcos Caceres wrote:

 On Tuesday, April 26, 2011 at 2:02 PM, Arthur Barstow wrote:
 Well, you started with a relatively ambiguous characterization of a need 
 to eliminate redundancies and inconsistencies and now I see you think 
 the spec as written has resulted in willful violations of the spec and 
 of course those are quite different.
 Correct. But one really led to the other. The reality is that very few people 
 who implemented the spec really read the spec in detail. Most people seemed 
 to have been working from the examples. This is normal and to be expected. 
 Cleaning it up a bit should make it easier to follow. 
 
 Since this spec is in the Candidate state (and as such, perhaps already 
 deployed), I think it would be helpful if you would please flesh out all 
 the changes and bug(s) you propose must be fixed ^1. Then we should be 
 able to have a more informed discussion re if it's OK to have a go at 
 rewriting.
 I'm ok with that, but would prefer to do it like this: 
 
 1. make a mirror copy of the spec. 
 
 2. make all the edits I think need to be made. It's not many, as the spec is 
 relatively small (~14 pages). 
 
 3. make a diff of the two documents to build the list of changes.
 
 4. propose the complete list of changes to the group. 
 
 5. let the group decide which changes they accept or reject or need further 
 discussion. If the new spec is take wholesale, then great. Otherwise, it's 
 easy to backtrack on proposed changes. 
 
 This is how I've done this kinds of changes in the past and it's always 
 worked out ok. 
 
 
 
 




Re: [widgets] Dig Sig spec

2011-04-26 Thread Arthur Barstow

Hi Marcos,

On Apr/25/2011 11:53 AM, ext Marcos Caceres wrote:

I've been reviewing and trying to implement the widgets dig sig spec and I'm 
finding that there is a lot of redundancies and inconsistencies with the way it 
is written. Although the conformance requirements are fairly clear, the main 
problem is that the spec is a bit confused when it comes to algorithms and 
processing. It also states things that really should just be deferred to XML 
Dig Sig 1.1. If it's ok with everyone, I want to have a go at rewriting it with 
the goal of making it simpler to implement.


Unless there are some relatively major bugs in the spec that are 
affecting interoperability, then I wouldn't recommend doing that. There 
are real costs for this proposal: for implementors and developers to 
review new WDs, external groups to consider (e.g. XML Security WG, WAC) 
as well as the WG's overhead of processing new publication requests.


If folks have resources to spare on the Widgets specs, it seems like the 
higher priority would be to complete work already started.


-Art Barstow




Re: [widgets] Dig Sig spec

2011-04-26 Thread Marcos Caceres
On Tuesday, April 26, 2011 at 1:13 PM, Arthur Barstow wrote:
Hi Marcos,
 
 On Apr/25/2011 11:53 AM, ext Marcos Caceres wrote:
  I've been reviewing and trying to implement the widgets dig sig spec and 
  I'm finding that there is a lot of redundancies and inconsistencies with 
  the way it is written. Although the conformance requirements are fairly 
  clear, the main problem is that the spec is a bit confused when it comes to 
  algorithms and processing. It also states things that really should just be 
  deferred to XML Dig Sig 1.1. If it's ok with everyone, I want to have a go 
  at rewriting it with the goal of making it simpler to implement.
 
 Unless there are some relatively major bugs in the spec that are 
 affecting interoperability, then I wouldn't recommend doing that. There 
 are real costs for this proposal: for implementors and developers to 
 review new WDs, external groups to consider (e.g. XML Security WG, WAC) 
 as well as the WG's overhead of processing new publication requests.
I understand the costs to implementers, but I'm not proposing to radically 
change the conformance requirements of the specification (which will remain the 
same except were things are clearly broken). The major bugs in the spec are to 
do with the unnecessary restrictions that the spec imposes wrt canonicalization 
and other algorithms and signature formats. WAC already willfully violated the 
canonicalization requirement in WAC 1, which shows the spec is broken. 

I propose to fix this by increasing the reliance on XMLDigSig 1.1 for 
validation and generation and making the spec only recommend certain formats, 
algorithms, and key lengths. This will make the specification a proper 
profile of XML DigSig 1.1, which currently it is not. It will also allow WAC 
1.0 runtimes to conform to the spec without impacting future WAC versions. 
 
 If folks have resources to spare on the Widgets specs, it seems like the 
 higher priority would be to complete work already started.
My opinion is that this spec is too important to leave it in its current state. 






Re: [widgets] Dig Sig spec

2011-04-26 Thread Arthur Barstow

On Apr/26/2011 7:40 AM, ext Marcos Caceres wrote:

On Tuesday, April 26, 2011 at 1:13 PM, Arthur Barstow wrote:
Hi Marcos,

On Apr/25/2011 11:53 AM, ext Marcos Caceres wrote:

I've been reviewing and trying to implement the widgets dig sig spec and I'm 
finding that there is a lot of redundancies and inconsistencies with the way it 
is written. Although the conformance requirements are fairly clear, the main 
problem is that the spec is a bit confused when it comes to algorithms and 
processing. It also states things that really should just be deferred to XML 
Dig Sig 1.1. If it's ok with everyone, I want to have a go at rewriting it with 
the goal of making it simpler to implement.

Unless there are some relatively major bugs in the spec that are
affecting interoperability, then I wouldn't recommend doing that. There
are real costs for this proposal: for implementors and developers to
review new WDs, external groups to consider (e.g. XML Security WG, WAC)
as well as the WG's overhead of processing new publication requests.

I understand the costs to implementers, but I'm not proposing to radically 
change the conformance requirements of the specification (which will remain the 
same except were things are clearly broken). The major bugs in the spec are to 
do with the unnecessary restrictions that the spec imposes wrt canonicalization 
and other algorithms and signature formats. WAC already willfully violated the 
canonicalization requirement in WAC 1, which shows the spec is broken.

I propose to fix this by increasing the reliance on XMLDigSig 1.1 for validation and generation and 
making the spec only recommend certain formats, algorithms, and key lengths. This will 
make the specification a proper profile of XML DigSig 1.1, which currently it is not. 
It will also allow WAC 1.0 runtimes to conform to the spec without impacting future WAC versions.

If folks have resources to spare on the Widgets specs, it seems like the
higher priority would be to complete work already started.

My opinion is that this spec is too important to leave it in its current state.


Well, you started with a relatively ambiguous characterization of a need 
to eliminate redundancies and inconsistencies and now I see you think 
the spec as written has resulted in willful violations of the spec and 
of course those are quite different.


Since this spec is in the Candidate state (and as such, perhaps already 
deployed), I think it would be helpful if you would please flesh out all 
the changes and bug(s) you propose must be fixed ^1. Then we should be 
able to have a more informed discussion re if it's OK to have a go at 
rewriting.


-AB

^1 presumably you should use Tracker since it is already being used for 
the widget specs







Re: [widgets] Dig Sig spec

2011-04-26 Thread Marcos Caceres
On Tuesday, April 26, 2011 at 2:02 PM, Arthur Barstow wrote:
 Well, you started with a relatively ambiguous characterization of a need 
 to eliminate redundancies and inconsistencies and now I see you think 
 the spec as written has resulted in willful violations of the spec and 
 of course those are quite different.
Correct. But one really led to the other. The reality is that very few people 
who implemented the spec really read the spec in detail. Most people seemed to 
have been working from the examples. This is normal and to be expected. 
Cleaning it up a bit should make it easier to follow. 
 
 Since this spec is in the Candidate state (and as such, perhaps already 
 deployed), I think it would be helpful if you would please flesh out all 
 the changes and bug(s) you propose must be fixed ^1. Then we should be 
 able to have a more informed discussion re if it's OK to have a go at 
 rewriting.
I'm ok with that, but would prefer to do it like this: 

1. make a mirror copy of the spec. 

2. make all the edits I think need to be made. It's not many, as the spec is 
relatively small (~14 pages). 

3. make a diff of the two documents to build the list of changes.

4. propose the complete list of changes to the group. 

5. let the group decide which changes they accept or reject or need further 
discussion. If the new spec is take wholesale, then great. Otherwise, it's easy 
to backtrack on proposed changes. 

This is how I've done this kinds of changes in the past and it's always worked 
out ok. 






[widgets] Dig Sig spec

2011-04-25 Thread Marcos Caceres
I've been reviewing and trying to implement the widgets dig sig spec and I'm 
finding that there is a lot of redundancies and inconsistencies with the way it 
is written. Although the conformance requirements are fairly clear, the main 
problem is that the spec is a bit confused when it comes to algorithms and 
processing. It also states things that really should just be deferred to XML 
Dig Sig 1.1. If it's ok with everyone, I want to have a go at rewriting it with 
the goal of making it simpler to implement. 

-- 
Marcos Caceres
http://datadriven.com.au