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.

> 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?

> 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].
]]
-- 
Marcos Caceres
http://datadriven.com.au

Received on Sunday, 22 February 2009 16:59:58 UTC