- From: Marcos Caceres <marcosc@opera.com>
- Date: Mon, 23 Feb 2009 23:54:38 +0100
- To: "Priestley, Mark, VF-Group" <Mark.Priestley@vodafone.com>
- Cc: public-webapps <public-webapps@w3.org>
Hi Mark, On Mon, Feb 23, 2009 at 11:43 AM, Priestley, Mark, VF-Group <Mark.Priestley@vodafone.com> wrote: > 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. > sounds like a plan. >> >>> 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. Ok. I'm not saying it's a bad idea (I think in principle, identifying the author is good... I just don't like the current model of using file names as an extensibility mechanism) >> >>> 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. Ok, great. Looking forward to it. -- Marcos Caceres http://datadriven.com.au
Received on Monday, 23 February 2009 22:55:15 UTC