Re: [widgets] OMTP input to W3C Widget Requirements (2 of 2)

Hi,

Thomas, to help me with the editorial process, it would be really
helpful if you could please check the whole security section in the
Req doc and raise any further concerns you might have with the text as
is [1]. Below are some changes I've made to the Req doc based on the
discussion below. Please let me know if you agree with the changes.

On Thu, Aug 7, 2008 at 10:51 AM, Priestley, Mark, VF-Group
<Mark.Priestley@vodafone.com> wrote:
> -----Original Message-----
> From: Thomas Roessler [mailto:tlr@w3.org]
> Sent: 07 August 2008 01:30
> To: David Rogers
> Cc: public-webapps@w3.org; marcosscaceres@gmail.com; art.barstow@nokia.com; Nick Allott
> Subject: Re: [widgets] OMTP input to W3C Widget Requirements (2 of 2)
>
> David,
>
> thanks a lot for your comments.  Some quick reactions to the changes that you propose...
>
>>A conforming specification SHALL specify the expected behaviour when
>>multiple signatures and certificate chains are provided. 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.
>
> Note that PKIX CRLs are only required to cover *un*expired certificates.  Therefore, a client may not be able to distinguish an expired and a revoked certificate.
>
> [MP] This requirement is meant to define what happens when a client can tell that a certificate has expired or has been revoked. Is your comment that clients can't always tell the difference?
>

> I'm therefore wary of the proposal to require at least one valid signature chain unless there is at least one revoked chain -- it seems a bit inconsistent.  I'd rather that we say very clearly that either all certificate chains must validate and lead up to a trusted root, or that this must be true for at least one.
>
> [MP] This was not how the requirement was supposed to read. What we were trying to say was that if no certificate chains can be verified then the widget should be treated as unsigned but if the certificate chain can be verified but the client can tell that one of the certificates has been revoked, then the widget will not be treated as unsigned and will be treated as revoked. Does this make more sense?
>
> You suggest referencing RFC 3280.  I'd suggest we reference RFC 5280 instead. ;-)
>
> [MP] Our mistake, agree with your suggestion :-)

I've fixed this in the spec.

> In the "Signing Procedure Agnostic" requirement, you write:
>
>> A conforming specification SHALL specify a mechanism for signing a
>> widget resource that does not explicitly or implicitly impose any
>> restrictions on the procedure for generating the signature.
>
> That makes a lot of sense, although there is a question whether a certain set of algorithms should be fixed for interoperability.
> (SHA-256 and RSA, for example).  You get to that point in a proposed later requirement; I actually wonder whether it's still worth calling out SHA-1 as a requirement there.
>
> [MP] This was not quite what was meant but I think you make a valid point anyway ;-) What we were trying to say in a round about way was that any procedure for signing a widget (i.e. the end to end process, not just the algorithm used) should not restrict how you are able to use that process. For example, the process shouldn't assume that the signing entity is the same as the widget author.
>
> Back to the "Signing Procedure Agnostic" requirement:
>
>> More specifically, a conforming specification SHALL allow the use of
>> end entity keys stored in a secure module in a hosted environment. A
>> conforming specification SHALL specify that implementations SHOULD be
>> able to use end entity keys via a
>> PKCS#11 interface.
>
> I'm not sure how this fits together with the rest of the requirements, and with the specification overall.  Could you clarify?
>
> [MP] See above comment for explanation. Also, it is worth mentioning that we were not sure whether such a requirement fell under the scope of this specification but included them so that they could at least be considered. Most signing tools that use secure hardware, such as the tools used to sign many mobile applications today, use the PKCS#11 interface. Our feeling is that to gain widespread support for the mechanism defined in W3C it would be beneficial if tools implementing the specification could just be plugged into existing systems. In light of that desire, we wanted to ensure that whatever mechanism is defined by this specification makes use of PKCS#11 possible. This is highly likely to be the case but we haven't looked at PKCS#11 in detail to be able to make this requirement more specific. Happy to discuss further.
>

I've removed all mention of PKCS from the requirement. It's support is
implied by not mandated. Do we really need to support it? and if we
do, lets just add support in the DigSig spec and not mention it here.
Please let me know if you agree or disagree.

> The "Key Usage Extension" requirement is a good catch.
>
>
> I'd like to understand the motivation for the "inclusion of revocation information" requirement better.  I think that it's a good idea to mandate widget engines to consult CRLs. However, I wonder if packaging these into the widget itself won't cause a significant likelihood of stale information, at least in Web-based deployments.
>
> [MP] In a lot of cases stale information could be avoided by implementing the necessary server side logic and processing, however, you are right, including revocation information in the package will lead to cases where the information is stale and the widget client will need to fetch new information. The motivation behind this requirement is to be able to reduce load on revocation information servers based on experience with mobile applications.
>

Strain on servers seems like an "implementation detail". Seems to me
that if widget publishers are having problems with their servers, and
they are serious about their business, then they should upgrade their
servers to handle the verification load. Though I can understand that
taking some load off servers would be a good thing but it seems to add
more complexity to the digsig model... Is that a fair call?

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

Received on Wednesday, 3 September 2008 15:05:38 UTC