Re: Digital Signature for MIDlet?

Christophe Planty <[email protected]>
Newsgroups gmane.comp.java.sun.kvm
Message-ID <B0D36A13C7B6CA4BBF71DC60519E89900189C577@par-exch-prd1.myopwv.com>
Unfortunately the Java Verified initiative is not complete solution :

- signature goes trough certification test, have a cost (150$ to 700$ per device) , can not be used for development & testing.

- the level of signature is 'only' 3rd party, where some APIs can only be accessed trough.

- limited number of devices. Even if some efforts are done to increase the device & manufacturers list, it's less than 10% of existing devices. 
(old devices can't be added in the list as it have to embed the jverified root certificate).

- lack of prototypes. devices not yet on the market are not covered. 
(in the case of pre-embedding an application in a handset before it's on the market)
Some testing house do have prototypes so there's sometime some tricky ways to perform test no those devices. But then there's no choice between testing houses for application developer.


As application provider, I only use Java Verified for certification purpose, not for signing. 
(I only focus on the test report as our apps are already signed with operator certificate level).


to get application signed for development purpose, I think that the J2ME standards should mandate the ability to download a self made root certificate - to be able to self-sign MIDlets and simulate a 3rd party level signature.

(other option would be to force all manufacturers to embed verisign root cert, which will please verisign but not their competitors :) 



/Chris 


-----Message d'origine-----
De : A mailing list for KVM discussion [mailto:[email protected]] De la part de [email protected]
Envoyé : jeudi 26 juillet 2007 16:19
À : [email protected]
Objet : Re: Digital Signature for MIDlet?

Sorry for the slow reply.

As for accessing protected APIs the problem is very simple: Many device manufacturers and/or carriers grant permissions to sensitive APIs only for very few and specific protection domains (and thus, to applications signed with specific certificates).

Unfortunately, there is no standard policy or agreement which APIs are covered by which protection domains. Some OEMs for example will only allow access to JSR-75 when for applications in the manufacturer domain which means an app developer has to get the attention of the OEM and enter a business arrangement with them.

As a result it is frustrating and nearly impossible for an application developer to get the right signature(s) that allow their app to function correctly on a wide range of devices. To be blunt, some OEMs and operators are using application signing as a way to enforce their business models onto the app developer.
See also my blog on the topic: http://weblogs.java.net/blog/terrencebarr/archive/2007/07/open_technologi.html

What can be done? A unified and industry-wide testing and certification program such as Java Verified (http://www.javaverified.com) should be able to address this and bring some sanity to the system. The problem has been recognized and there are efforts underway to start addressing this. I am currently engaging with some of the Java Verified folks on the topic and will report back to the community soon, I hope.

-- Terrence
[Message sent by forum member 'terrencebarr' (terrencebarr)]

http://forums.java.net/jive/thread.jspa?messageID=228358

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff KVM-INTEREST".  For general help, send email to
[email protected] and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff KVM-INTEREST".  For general help, send email to
[email protected] and include in the body of the message "help".
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.