On Wed, May 11, 2011 at 1:16 PM, Gustavo Medeiros <[email protected]>wrote:
> Hi Brian, > - Do you now why AID_SYSTEM is not given the permission to read > certificates (~GET)? > My guess is just that there was a desire to have the minimum permissions possible. System had no use case for read, so it was disallowed. A similar decision led to the CertInstaller being a separate app so that it could have permission to read the sdcard, which the system user can't do either apparently. > - And also why are the public certificates stored encrypted? This > prevents the system from displaying the contents of the certificates > to the user, other platforms only encrypt the private key. > I assume its because it was just designed as an opaque store that tried not to have any semantics about what it was storing, which I agree was a mistake, but something that didn't matter for the VPN and WiFi uses cases. > - Browser and Email get the certificates from cacerts.bks to use in > SSL, Wi-Fi and VPN cannot use these CA certs in their authentication > process, the reverse case happens with Browser and Email, they cannot > use user-installed CA certs. Is there some reason for the keystores > not being unified? > the keystore was written by the VPN guys and then expanded for use in WiFi, all a huge pile of C code. The browser and email and in Java and the default TrustManager implementation used a keystore for its CA certs. There are many public issues about this, I've tried to bring them together into one feature request here: http://code.google.com/p/android/issues/detail?id=11231 -bri -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
