- From: Marcos Caceres <marcosscaceres@gmail.com>
- Date: Wed, 3 Sep 2008 15:13:12 +0100
- To: "Priestley, Mark, VF-Group" <Mark.Priestley@vodafone.com>
- Cc: "Arthur Barstow" <art.barstow@nokia.com>, public-webapps <public-webapps@w3.org>
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