Rethinking SSL for Mobile Apps

The OCSP (certificate revocation check) doesn't have to be done on every SSL setup - the results can be cached for a while.<p>What is most strange about this article is the assumption that the backend connectivity is coupled to UI interactivity. That is the single worst thing you can do in a mobile app. They should be decoupled as much as possible. In general the user shouldn't even be able to figure out or care that there is latency in the underlying networking.<p>Of course the one time is when they search for something, but local caching and prediction plus heuristics should help a lot of the time for that. (Of the billions of items on the server, the user is only going to access a tiny subset.)<p>For the developer types this is a nice presentation (with a nervous presenter?) showing best practises for writing a REST Android app. Pretty much all of the principles apply to iOS and other mobile platforms too where you decouple the user interface from the underlying networking.<p>Google I/O 2010 - Android REST client applications <a href="http://www.youtube.com/watch?v=xHXn3Kg2IQE" rel="nofollow">http://www.youtube.com/watch?v=xHXn3Kg2IQE</a>

The OCSP is used to ensure that in case of security breach the certificate can be revoked dynamically. If you don't care about the "dynamic" part then you can skip the whole OCSP process all together. Now you are in the same state as you will be with embedding your server cert in the app without the need to "hack" the system.<p>BTW, nothing prevents you from using your own certs. Just make yourself a CA, add root cert to the app, and implement OCSP on your server (if you care about OCSP). Again, no need to hack it and invent new security protocol. Everything you need is already there.

Would baking your own SSL stuff into the app instead of just running with the system URL stuff cause more paperwork regarding Apple and the crypto export control stuff?