* Kyle Hamilton wrote on Thu, Apr 10, 2008 at 02:34 -0700: > > (That means the CA remotely signs online submitted CSRs and sends > > back a Cert immediately? Maybe such a CA would not be that > > trustworthy...) > > First: it is as trustworthy as the application seems to > require. It's not as though these certificates are going to be > trusted by anything outside of that application realm, and thus > the CA key exposure risk is minimal.
Yes, of course, it depends. In a scenario where a closed group of entities, each able to securely (enough for this application) communicate something to a CA, this may work very well. Maybe it is not clear why a CA is even needed. > I'm sick of hearing "best practices" being parroted about without > regard for, y'know, actual security evaluation. Security is often > what makes systems unusable. On the other hand, I'm afraid, `a little bit of security' may work only as long as there are sufficiently other services easier to attack. I mean, why attacking some SSL protected web shop if users open phishing mails or alike. But situation may be different when everyone use `a little bit of security'. For instance, there are so many people using HTTPS servers with X.509 certificates that the presence of some key or lock symbol in a browser status line may not tell much. How many people read the subject information of a certificate before starting online banking? Your points are correct of course. If hyper-secure online banking is too unusable complicated and uncomfortable noone would use it :) > It's people who parrot these 'best practices' without regard for > reality that end up reducing the usage of cryptography, because they > ignore the fact that end-users don't care about security -- they care > about using the systems they have access to in the way that they need > to make use of the systems. They don't care about 'following policy', > they care about 'getting their jobs done'. Yes, but as soon as they are attacked they ask why their secure application was not automatically secure and may ask, if this and that can be done insecure why the application does not prohibit it etc. I mean, if someone gets internet order deliveries he never ordered because of some attack he probably don't want to pay. I think it is part of the job of secured systems to `educate' users a little. For instance, the online login page of the bank I use shows different security hints like `Do never open banking links in email', `Check the key/lock and the URL before logging in' or `We never ask for a TAN at login' etc. I think this is good. > > Yes, then it is know if the peer's identity is authentic. For > > instance, that it is really is `Malicious Hacker' from China that > > is connected (and noone else can decrypt data sent to them :)), > > as the certificate correctly states, protected by strong > > cryptography... > > Authentication and authorization can be dovetailed into the > same step. Not necessarily in all circumstances, and there are > many circumstances within which it makes no sense -- but there > are also situations that are so simplistic and low-risk as to > not need the increased complexity. (increased complexity leads > to orders of magnitude more cost, due to the number of parts > that have to be tested in all of their possible combinations.) Yes, sure. But for very simplistic and low-risk tasks maybe no 4096 bit RSA key protected PKI is needed but a shared 3DES key is sufficient or so (of course I see that using SSL may still be suited because it is standard, well-known and easy to use). > > Without authorisation this probably would be too weak. Often it > > might be needed to find out if the identity / entity that is > > connected (and authenticated) is authorised to use the particular > > service. > > This is where protocols like Kerberos and ADFS come into play -- but > if one is not trying to integrate into these service structures, these > protocols can also be ignored. (or simply check if the DN matches some whitelist) > Fortunately for the rest of us, we don't need that level of paranoia > to use cryptography in our day-to-day lives. We usually don't handle > transactions of that large of a scale, and quite often we don't handle > "transactions" at all. We just want to communicate, and sometimes we > don't want the rest of the world to see that we typed "I still love > you and sometimes still dream about you" to our ex-girlfriends or > ex-boyfriends... but if someone's current girlfriend gets a signed message from his ex-gf claiming he met her last night (which in real is from someone else who has interests for the current girlfriend) and the current girlfriend leaves because of that (or vice versa for boyfriend), people probably would blame the messaging tool for beeing insecure. In talk shows girls told that they left boyfriends because of messages in mobile phones or instant messager history, so I think this can happen for faked signed email as well. Or for security in general, if some cracker uses your workstation for sharing illegal content and you get into prision, because the judge gets told that 1024 bit RSA keys are unlikely to be attacked so it must have been you who put those files. Well, sorry for the bad example but I hope I could tell what I mean. If security is used people think it is secure (even if they use it wrongly) and others also do. oki, Steffen -- ps: sorry for the long signature. It is automatically appended. 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]
