On Aug 28, 10:08 am, Nelson Bolyard <nonelsons...@nobolyardspam.me> wrote: > On 2010-08-27 16:48 PDT, Michael Smith wrote: > > > We're not really looking for a "couldn't be compromised" solutions - > > this is a requirement from a company we're partnering with, not our > > idea, and they basically just want it to not be "simple" (for some > > value of that) to compromise. So: serialising it to disk without some > > sort of encryption isn't ok, and exposing it in exportable form in the > > browser UI isn't ok. > > What is the real underlying objective of this? > > Is it to authenticate the individual user of the product to the servers? > > Is it to ensure that the client applications of the network service are > genuinely those made by your "partner", and not some other client that > has been made by some third party who reverse engineered your protocol? > (e.g. as AOL used to try to ensure that only genuine AOL clients > accessed the AOL Instant Messenger servers?)
Sorry for not being clearer. Yes, the intent is to ensure that the client application is a "legitimate" application, and to prevent others (even if the _user_ is appropriately authenticated with username/password) from accessing the servers. i.e. Standard HTTP authentication is used to authenticate the user, and an SSL client certificate is used to authenticate the application binary. This is why I want to keep the certificate "secret" from the user; it logically belongs to the application, rather than the more typical use of client authentication, where the private key logically belongs to the _user_. > > Is it something else? > > The use of public key certificates may not be the best way to accomplish > your objective, or even an appropriate way at all, but we cannot determine > that until we know what that objective is. I'm pretty unconvinced that this is a sensible way to accomplish the real objective, but unfortunately I've been given no choice - the partner insists on this being the only acceptable way to access their servers. Any advice you can give would be greatly appreciated! Mike -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
