Innovations in OSGi How to prevent patent applications

RFC 73 Introduces new IP RFC 73 Signing and Permission Admin New security mechanisms for the Framework Stumbled on a very innovative idea to handle permissions on a Service Platform that could have wide implications

Traditional Model Key Certificate Signature code Certificate Signature code Policy DeveloperSignerDeployer I have a good bundle! I trust the guy who wrote this bundle I will limit the permissions trust Implicitly trusts the signer-developer relation

Traditional Model The Developer designs the code that requires a set of permissions to run Very hard to impossible to calculate these permissions from the code alone The signer vouches for the security of the bundle The signer can only sign the bundle. Meaning it can only say: trust it completely The signer is relatively powerless because it cannot say: trust it within this scope The operator can only assign a single set of permissions to a signer in Java 2. –Implies that the permission associated with a signer must be the superset of all required permissions! –Means that privileged applications and non privileged applications require different signatures, complicating PKI administration

Traditional Model DeveloperSignerDeployer Security scope Size is proportional to permissions

Java 2 Permissions not good with Zones/Groups Windows Permission model is based on zones Most important decision is to run an app or not. A running app usually gets all permissions. Zones are not useful for Java because permissions are too fine grained. Detaile security configuration information is necessary Internet Intranet Trusted sites local

RFC 73 Solution The developer creates a file with permissions that are needed to run the application The signer inspects the file and signs it The deployer –Sets the maximum permissions for the signer –It deploys the file with the minimum permissions in the permission file The Framework checks that the bundle will only perform actions that are both: –Permitted by its permission file (vouched for by the signer) –Permitted by the operator, based on its signer (max trust the deployer has in the signer)

Advantages The signer can limit its liability (e.g. it can even sign an untrusted bundle in a very small security scope) The signer can use the same certificate for different trust levels, simplifying administration The deployer can inspect the permissions file beforehand to see what permissions are needed The deployer still limits the maximum security scope an application from a signer can get.

Issues This solution is a potential patent, it elegantly solves a very real problem in J2EE, and J2SE applications, maybe even in J2ME From an OSGi point of view we should not attempt to obtain patents, but we also do not want to get confronted with patents Suggestion is to write an article in the press to establish prior art.