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: Marcos Caceres <marcosc@opera.com>
Date: Mon, 23 Feb 2009 23:54:38 +0100
Message-ID: <b21a10670902231454y75740124j6f75b97fba3e81a8@mail.gmail.com>
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 GMT

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