* David Schwartz wrote on Sun, Sep 23, 2007 at 22:51 -0700: > > Here is my understanding about a real CA. > > A real CA would be an agency or like, which would have the infrastructure > > required to sign certificate requests (say openssl toolkit, its own key > > pair, its own root certificate etc). In addition to this, it would have > > capabilities / mechanism to verify the information provided by > > the requester > > (subject) in the certificate request. Once the CA verifies that the > > information provided in the certificate request is correct, it would sign > > the request, and provide the signed certificate to the requester > > (subject). > > > > If I am missing anything that is important to know, I will be really happy > > to learn about it. > > What you're missing is the policies they employ to protect > their private keys. If you don't employ anywhere near that > level of security, you should definitely not be asking people > to add your CA certificate to their browsers for Internet use.
I would like to extend this a little. I think, a CA is almost "only" paperwork in means of policies, auditable procedure descriptions and contracts. Whether X.509 or asymetric cryptography is used or not, for me goes a little bit into being an implementation detail. Whatever cryptoscheme is used, it must fulfill the security requirements of the policies. Trusting a CA means trusting those policies (and that them and only them are always applied correctly, usually verifyable/auditable, retroactively inspectable in means of unmodifyable log records / log books and so on). > Whether your level of security is sufficient for non-browser > programs or networks other than the Internet is a question only > you can answer. But the expert consensus for browsers on the > Internet is that this is not nearly sufficient security. Yes, I think this is important: to determine the needed security level for a certain purpose / application. The level of security is given by the policies (those policies need to fulfill the requirements specification of course, if any). Of course, there are common practices for policies of e.g. CAs that make sense, such as protecting secret signing keys effectively (dual control, not readable from hardware security module), but theoretically everything is possible. For instance, you could have a policy allowing certificates without personal authentication (for instance, as cacert.org offers) or you could protect the secrect key by nothing else that an linux crypto file system on a regular hard disk with a single passphrase (allowing the admin who knows this passphrase to take a backup of the system - another cacert example). If this would be documented in the policy and it would be applied letter by letter, you could trust the CA (in doing so. BTW, this is not the case for cacert, because they do not even have a policy, so everthing is possible - different topic). However, the security level of this trusted CA is in my personal option that low that I never what its root certificate in my browser (or elsewhere), because I'm afraid of accidently accepting a certificate issued (assured) by a 12 year chinese girl agent spy or so. You can verify as much fingerprints as you like, the security level won't increased because it is limited by the weakest part in the chain; this probably isn't the question whether a RSA key has 2048 or 4096 bit but if the officiers that work in security relevant topics (such as authentication) are well trainined etc. Since I wrote such a big text and already bored everyone to dead I want to add that beside authentication of course authorisation is important. It does not help much if you know 100% that your communication peer is authentic if this is an attacker (who is authenticated but not authorised to do the particular thing). This sounds cheap, but with a today standard webbrowser and HTTPS, a DNS name is used (referenced via some X.509 CN field) as name for verification and the human is supposed to verify the the displayed URL is autorised to receive the online banking account information (or whatever). Of course, you can inspect the field values of a certificate by clicking those key or lock symbols. I've read that newer versions of firefox and other browsers will improve here (or maybe even already did :)). > > Hmm ... So are you suggesting that my clients would store the > > certificate produced by the server, the first time they > > connect to the server, and thereafter each time they connect > > to the server, they check if the certificate has changed? > > It depends upon what the client needs to determine. If the > clients needs to know if it's talking to the same server it was > talking to before, then this is the perfect way to do that. Yes, I think this is how e.g. SSH works by default (allowing manual fingerprint verification or preinstalling authentic keys to the known_hosts files) and, as far as I understand, these Windows machine key account stuff is working. > > As I understand, a self signed certificate can be verified > > using the public key present in the certificate iteself. So > > how can my client detect the change in the certificate unless > > they store the public key (or the certificate itself) the > > first time they connect to the server, and then for every > > successive connection attempt, check the certificate > > presented with this stored public key / certificate ? Am I > > still missing something? > > If they don't care if it's the same server each time, then what > do they care about? What's the point of this entire exercise? Storing some fingerprint of a certificate or public key locally in some trusted place (such as a local file system) seems to be quite secure (should be the same level as having a CAs root certificate in a file), however, I'm not sure if this works with OpenSSL which seems to expect to be able to verifiy the whole certificate chain up to the root certificate even if intermediate certificates are locally avialable. As far as I know / understood - please correct me if I'm wrong! > > > The problem is that anyone who has access to your installer > > > can impersonate any server. > > > Absolutely true. Yes, if the security is bound to `the secret of the installer' (requiring the installer to be handled like a secret key :)) but not to cryptographic keys, why do you need certificates at all? > > Now the question was, how can I embed the root CA cert + > > associated private key in the installer, such that it can not > > be retrieved easily? Has anyone ever done anything like this > > before? Does anyone have any better approach to suggest? I think in general you cannot have `fully automatic and scalable' and `secure' in the same time. I think, `secure' usually means not fully automatic, but only after manual authentication / authorisation. If identities are important and a value, then of course you need to burn a CD (or smart card, ...) for each. Same as with passports or personal ID cards, right? :) > It's hard to know without knowing what the threat model is. But > I would say you could simply include several 100 certificates > on the CD, each encrypted with a different key. You can then > give a distinct certificate number and key to each customer and > they can use that to decrypt their certificate. Or maybe separating installation and personalisation (giving a secure ID by having an individual secret key) and installing certificate and/or key later by some user interface (config file). Transferring the data would be out of scope and a appropriate solution can be used: USB Stick, secure mail (SMIME/PGP), personal or phone authentication, ... oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
