Re: [widgets] Minutes from 7 August 2008 Voice Conference

Hi Mark,

On Wed, Aug 13, 2008 at 1:18 PM, Priestley, Mark, VF-Group
<Mark.Priestley@vodafone.com> wrote:
>
> Hi Art, All,
>
> Unfortunately I won't be able to attend today's call but would like to
> provide feedback on some of the discussions from last week's call.
>
> On the addition to R11, specifically:
>
> "A conforming specification SHALL specify that if none of the signatures
> and certificate chains can be verified, e.g. because of missing root
> certificates or where any certificates in the chain have expired or are
> not yet valid, then the widget resource SHALL be treated as unsigned. A
> conforming specification SHALL specify that the widget environment SHALL
> not install or load a widget resource when it can determine that any
> certificate in the chain has been revoked."
>
> There was a desire to clarify what was and wasn't allowed and to check
> that this didn't lead to any inconsistent behaviour.
>
> To re-cap this addition was a result of a desire to treat widgets that
> are known to be bad (e.g. that have been revoked) differently from
> widgets for which the widget platform cannot verify the signature
> because of missing or out of date information. In the former case we're
> suggesting that the correct action would be to not install the widget,
> in the latter the widget should be treated as if it hasn't been signed.
> The issue was identified on the call that in some cases revoked
> certificates are removed from CRLs once they have expired. In this case
> the above rules could lead to revoked widgets being treated as unsigned
> widgets, which would not be satisfactory. To address this case we
> suggest the addition of the following sentence:
>
> "CRLs for certificates used in certificate chains associated to signed
> widgets SHALL include expired certificates"

I've added both the reworded requirement and the sentence above.

> I think a similar proposal was made by Thomas on the call and to us it
> is the best way to resolve the issue.
>
> On the comments to R38 there was a desire to re-word our proposal on the
> ability to add new root certificates. The proposal was:
>
> "A conforming specification SHOULD define mechanisms to enable end-users
> to install additional root certificates, provided this is compatible
> with the security policy of the widget processing environment."
>
> The suggested re-wording would look something like:
>
> "Implementations MAY provide mechanisms to enable end-users to install
> additional root certificates. Trust in a root certificate is established
> through a security critical mechanism implemented by the widget platform
> that is out of scope for this specification."

I added the above text to the DigSig spec, but as an informative note.
It was decided at the last f2f that this would be an implementation
detail, but I see no harm in encouraging implementers to provide this
capability.

> There was also a discussion on the new requirement titled "Signing
> procedure agnostic". The request was to re-formulate this requirement so
> that it was specific to the widget specifications. However, having
> looked in detail at the PKCS#11 specification we are inclined to suggest
> that the requirement is possibly out of scope. The PKCS#11 specification
> details how applications can use the interface and what this means in
> terms of their processing logic but it should be possible to meet the
> requirements it makes with whatever scheme is defined in W3C. We still
> believe that PCKS#11 support will be vital for widespread adoption of
> the specification but perhaps on closer inspection this specification is
> not the right place to make this a requirement.
>
> We of course welcome any feedback on the above.

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

Received on Wednesday, 3 September 2008 14:13:59 UTC