Re: [Execution and Security Model] Proposal from Samsung Electronics

On 15/01/13 08:39, Janusz Majnert wrote:
> Hi John, Ryan, all,
>
> First, please note that using https for delivery of an app is not the 
> only way of ensuring its integrity. I don't think https has any added 
> value if an application package is for example signed or doesn't 
> access any security or privacy relevant APIs.

Yes, I agree.  As I mentioned in my last email, packaging and signing an 
application (or at least some part of it) is an alternative to serving 
over a secure channel that can still guarantee integrity.

With regards to the APIs being used - as per your proposal, I have no 
problem with some being restricted just to applications with higher 
integrity and a known provenance, and others being more widely 
available.  Going back to the original point - if a CSP header is 
required to constrain the application for security reasons, then it 
seems reasonable to require the header to be served securely.  Perhaps 
some applications need neither and some need both.

>
> Second, requiring https doesn't really mean anything. If we insist on 
> having it in the standard, shouldn't we also require that the source 
> of the package is trusted (by the user, device owner?) or mandate OCSP 
> and CRL checks for the certificates?

Mandating certain OCSP and CRL checks, where appropriate, might well be 
within the scope of the security model, in my opinion.  Alternatively it 
could be considered a "security policy" like in the Widget DigSig spec, 
and be left to user agents with a recommendation.  I don't know quite 
where the line should be drawn - but it seems reasonable to have a 
specification (for security-sensitive apps) that at least *allows* for 
trust decisions to be made, rather than allowing for scenarios where a 
trust decision is inherently impossible because there's no integrity 
guarantee at all.

Best wishes,

John

Received on Tuesday, 15 January 2013 09:50:57 UTC