W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

RE: [widgets] Action #224 - Work with Marcos to flesh out the details of the processing model for multiple signatures

From: Priestley, Mark, VF-Group <Mark.Priestley@vodafone.com>
Date: Mon, 23 Feb 2009 11:43:50 +0100
Message-ID: <0BE18111593D8A419BE79891F6C4690902971BC2@EITO-MBX01.internal.vodafone.com>
To: <marcosc@opera.com>
Cc: "public-webapps" <public-webapps@w3.org>
Comments inline.

Thanks,

Mark 

>-----Original Message-----
>From: marcosscaceres@gmail.com 
>[mailto:marcosscaceres@gmail.com] On Behalf Of Marcos Caceres
>Sent: 22 February 2009 16:59
>To: Priestley, Mark, VF-Group
>Cc: public-webapps
>Subject: Re: [widgets] Action #224 - Work with Marcos to flesh 
>out the details of the processing model for multiple signatures
>
>2009/2/19 Priestley, Mark, VF-Group <Mark.Priestley@vodafone.com>:
>> Hi All,
>>
>> In response to:
>>
>> Action #224 - Work with Marcos to flesh out the details of the 
>> processing model for multiple signatures; Mark and Marcos - 
>> http://www.w3.org/2008/webapps/track/actions/224
>>
>> I have outlined two alternative approaches to address the 
>issues that currently exist with the processing of multiple 
>digital signatures (see below). Both approaches need some 
>word-smithing but hopefully they provide a decent starting 
>point for us to agree an approach. FWIW I think I prefer Approach 2.
>>
>
>Ok, I like approach 2 too. I'll just make it explicit to pass 
>the signatures list across to the user agent that process the  
>digital signatures. However, something resembling approach 1 
>will need to go into the Widgets Dig Sig spec.

I'm not sure this is true. IMHO it should be enough for the Widgets
Digital Signature spec to describe the processing of a single digital
signature but let's discuss further at the WebApps face-to-face.
 
>
>> Some things to note.
>>
>> 1. The "signed" variable of the configuration document is no 
>longer set (and should be deleted). I can't think of anyway to 
>make this variable useful, especially with multiple signatures 
>and the definition of different "types" of signature.
>>
>
>Ok. Gone.
>
>> 2. The dependency on the Digital Signature spec is nearly 
>completely removed. There is actually one thing that I think 
>needs to be added - how to find the "author signature", but 
>otherwise I think we the specifications can be decoupled.
>>
>
>Whoa, hold up there! :) Did we reach a resolution that we were 
>going to include a separate author signature?

You're right - I have jumped the gun on this in two ways: 1) The use of
an "author signature" is still for further discussion in the context of
the Digital Signture spec. 2) Even if it's agreed we would need to
discuss whether it needed to be reflected in the Packaging and
Configuration spec. As such, please defer this comment until these other
discussions have been concluded, when it may or may not still be
relevant.  

>
>> 3. The more I've been thinking about it recently, the more 
>I've come to the conclusion that we should avoid specify 
>anything that equates to a security policy. This is what I 
>have tried to do below, although this does make it necessary 
>to rather obliquely refer to security policies.
>>
>
>Agreed.
>
>> Thoughts and comments welcomed.
>>
>> Thanks,
>>
>> Mark
>>
>> ------------------------------------------
>> Approach 1
>> ------------------------------------------
>>
>> Step 5 - Process the Digital Signatures
>>
>> Note: The way in which both the author digital signature and 
>distributor digital signature(s) are used is dependent on the 
>security policy implemented by the widget user agent. As such, 
>it is expected that a widget user agent implementing 
>[Widgets-DigSig] will process any digital signatures according 
>to the following algorithm.  It is however recognised that a 
>security policy might not require the processing of all of the 
>digital signatures included in the widget package. A widget 
>user agent is therefore able to exit the processing of 
>distributor digital signatures once it has established the 
>information necessary to inform the security decision making 
>process represented by its security policy, eg a signature 
>from a particular end entity has been verified or confirmed as revoked.
>>
>> Exit criteria - A result or set of results from the 
>application of the Procedure for Verifying a Digital Signature 
>Document in the [Widgets-DigSig] to one or more digital 
>signatures that satisfies, positively or negatively, the 
>widget user agents security policy.
>>
>> 1.      If present, the widget user agent should apply the 
>Procedure for Verifying a Digital Signature Document, as 
>defined in the [Widgets-DigSig] specification, to the author signature.
>>
>> 2.      If the widget user agent determines that an exit 
>criteria has been met:
>>
>>                 a.      If the widget user agent determines 
>that the widget is a valid widget, terminate this algorithm 
>and go to step 6.
>>
>>                  b.      If the widget user agent determines 
>that the widget is an invalid widget, apply the rules for 
>dealing with invalid widgets
>>
>> .
>>
>> 3.      Starting with the first file entry in the signatures list;
>>
>> a.       Apply the Procedure for Verifying a Digital 
>Signature Document, as defined in the [Widgets-DigSig] 
>specification, to the file entry;
>>
>> b.      If the widget user agent determines that an exit 
>criteria has been met:
>>
>>           i.      If the widget user agent determines that 
>the widget is a valid widget, terminate this algorithm and go 
>to step 6.
>>
>>            ii.      If the widget user agent determines that 
>the widget is an invalid widget, apply the rules for dealing 
>with invalid widgets,
>>
>> c.       Otherwise, select the next file entry in the 
>signatures list and go to 3a in this algorithm.
>>
>> 4.      If all of the file entries in signatures have been 
>processed and no exit criteria has been met, go to step 6.
>>
>> ------------------------------------------
>> Approach 2
>> ------------------------------------------
>>
>> Step 5 - Process the Digital Signatures
>>
>> It is expected that the widget user agent will process the 
>digital signatures in accordance with its security policy. 
>This will involve the widget user agent processing zero or 
>more of the identified digital signatures.
>>
>
>I think we should stick to your suggestion and not mention 
>security policies at all in this spec. For this reason, I am 
>excluding the above text. I think we should start mentioning 
>this kind of stuff in the Dig Sig spec.
>
>>
>>
>> The widget user agent must process digital signatures by 
>applying the Procedure for Verifying a Digital Signature 
>Document, as defined in [Widgets-DigSig].
>>
>>
>>
>> Unless the processing of the digital signatures results in 
>an invalid 
>> widget, go to step 6
>>
>>
>
>Ok, added the following:
>[[
>Step 5 - Process the Digital Signatures
>
>This step only applied to user agents that implement the 
>[Widgets-DigSig] specification. If the user agent does not 
>support [Widgets-DigSig], go to Step 6.
>
>A user agent must process the file entries in the signatures 
>list, in the order established in Step 4, by applying the 
>Procedure for Verifying a Digital Signature Document as 
>defined in [Widgets-DigSig].
>]]

I still think the suggested text might need some modifications as it
suggests that the user agent must process all of the signatures and this
was one of the things that I was trying to avoid. That said I agree with
trying to exclude even oblique references to security policy so I will
try provide a slightly reformulated version of your proposal before it
is discussed at the WebApps face-to-face meeting later this week. 


>--
>Marcos Caceres
>http://datadriven.com.au
>
Received on Monday, 23 February 2009 10:44:56 GMT

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