On Thu, Apr 10, 2008 at 2:00 AM, Steffen DETTMER <[EMAIL PROTECTED]> wrote: > * Kyle Hamilton wrote on Wed, Apr 09, 2008 at 14:22 -0700: > > Each peer goes through this process: > > 1) peer creates a keypair > > 2) peer generates a CSR (certificate signing request) for its public key. > > 3) peer connects to server, submits CSR along with whatever > > information necessary to determine that the certificate should be > > issued. > > 4) Server signs the certificate with its private key, and sends signed > > certificate back to peer. peer and server disconnect. > > (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. 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. The proper balance of security is 'that which raises the barrier enough that undesirable outcomes are reduced to a manageable level versus that which lowers the barrier enough that the people using the application aren't inconvenienced enough that they do everything they can to bypass it and make it useless'. 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'. Cryptography can dovetail with that -- as long as the people who implement it aren't so stiff-necked that they're regarded as unuseful hinderances to be avoided. > > > > Each peer has a copy of the CA certificate in its trusted root > > authorities store. When they receive a peer certificate, they verify > > the signature on that certificate as being from that CA, and then > > verify that the peer that it's talking with actually has the private > > key associated with that certificate. Then they look at the > > information in that certificate (expiration date, etc). > > > > This is what TLS with client authentication does. > > 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.) > 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. Examine the intent of the protocol, and apply the simplest means of meeting that intent. You can always build complexity in later -- especially if you use, in this case, a custom extension that specifies which version of credential marshalling you're using. If the server itself mediates which client can talk to which client, then the authentication and authorization steps can be merged -- a low-lifetime certificate with proof of permission from the mediator creates what's called an "authorization certificate", which provides evidence of authorization to use a particular service. (This is in contrast to an "attribute certificate" which describes attributes of the identity bound to the key.) > > oki, > > Steffen Ah, your signature explains why you're so all-fired holy about your "trustworthy" concept of a CA. In your line of work, the benefits of misappropriating a CA key are massive. Transactions could be allowed by policy, causing millions of Euros or Dollars or Pounds or other currency units to be mischanneled. Of course, in the event of such a policy breach, you would immediately have your local country's police and Interpol working to find the misappropriated funds, have them frozen and returned at the earliest possible convenient moment, and the perpetrators found and indicted and put on trial and convicted. The cost to you of such a breach would be immense -- every business that you have a relationship with would be forced to reevaluate your trustworthiness. You secure millions of dollars of transactions, and the sheer amount of fiduciary duty there is staggering -- thus, you need to make sure that your trust is well-placed, so that others can believe that they would be placing their trust well in your hands. 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... and we want to know that we're talking to them, not to a private investigator that's trying to find ways to make our lives miserable. Not everyone needs to be so paranoid, Mr. Dettmer. Not everyone needs to follow the "best practices" that are associated with huge amounts of fiduciary trust. Not everyone needs an offline CA with four layers of paperwork to get a certificate signed, and a root CA that's kept in a vault and taken out once every year to sign a new year's issuance CA. > > 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. -Kyle H ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
