Alberto Serra wrote: >> However, it is adequate to know that one key is used to do the >> encrypting, while the other is used for the decrypting. These are >> generally referred to as public and private keys, because one is made >> available to the public while the other is kept safely stored (in the >> case of Web browsers, it is stored in the certificate repository of >> the browser). > > > Yes, glad that I did use PGP sometimes :) this part is clear :) So > Verisign is actually just "signing" the key as I did on PGP and that > means anyone trusting me can trust you if they receive a message > signed with your key, because when evaluating the message they will > now it';s been signed by a key that I would trust myself. Right?
I have very little experience with PGP, so I can't confirm the similarities here. However, I think you may be still misunderstanding the role of VeriSign (I could easily be wrong). I'll explain it again briefly, just to be certain. The asymmetric cryptography that guarantees your HTTP communication cannot be decrypted except by the final recipient is only half (or less than half) of the battle. You need to also have some sort of assurance that the final recipient is who they claim to be and not an imposter. When you apply for a digital certificate from VeriSign, you must present a request in a specific format. Part of this process of purchase involves you proving that you are the holder of the public key (verified by the generation of the request by your Web server software) and the legitimate owner of the specific domain name the certificate is being used for. With this information, VeriSign will use the fact that pretty much every Web client on the planet trusts VeriSign to issue you a certificate that says: "We, VeriSign, assure you that the following public key belongs to www.niceguy.org." This means that nearly every Web client on the planet will trust that the public key mentioned in that digital certificate really belongs to www.niceguy.org, so any communication encrypted with it can only be decrypted by the private key of www.niceguy.org. >> Digital certificates solve this problem. A digital certificate, as >> RSA describes it, is a document that says: >> >> "I guarantee that this particular public key is associated with this >> particular user; Trust me!" > > > So actually, when you spend your $200 what happens is: > 1) Verisign (or whoever) starts a process to control they really wanna > play with you (and this has nothing to do with IT or SSL, they will > have their own policies) > 2) Verisign (or whoever) starts a process to control your public key > and possibly something else in your system > 3) If the above has a positive answer they just sign your kay and hand > it over to you. So there is no need for a central db. Trust is *in* > the key and need not be searched for. The only thing to do is to > verify that the trusting key has not been revoked. VeriSign doesn't do extensive checks on your use of the digital certificate, because that is all outside of the scope of SSL. Their methods are to ensure that the claim they are making in the digital certificate (mentioned above) is true. Since that's all they're guaranteeing, that's all they need to ensure. Also, VeriSign does keep a central repository of all digital certificates it has issued. Next time you are on an SSL site, go into the security configuration menus specific to your browser and see if you can find a way to verify the certificate. This will manually kick off the process to verify the certificate with the CA. You can revoke a certificate to make it fail this check and pretty much render it useless, except that people can still use it to encrypt email. >> So, assuming for the moment that we trust the certificate, we can >> assume that a particular public key belongs to a particular user. For >> example, you can be guaranteed that a public key belongs to me (Chris >> Shiflett) and thus, only Chris Shiflett will be able to decrypt the >> communication. If someone is trying to pose as me, you may send them >> encrypted communication, but they won't be able to decrypt it. > > > Yes, because they have stolen the public key and could crypt the > question but since they have not the private key they cannot open the > answer. Actually, what I meant here is not that they will even use the public key, but that other people whose browsers are tricked into thinking they're really talking to www.niceguy.org will use niceguy.org's public key to encrypt the communication. Then, only niceguy.org will be able to decrypt the communication, regardless of who receives it. The digital certificate is quite public itself. If you go to an SSL-enabled site, you can view theirs (since they have to present it to your browser). The statement it makes doesn't change, so it doesn't matter if the criminal has possession of it; it's public anyway (just like the key). The private key is the important part, and "stealing" this isn't nearly as trivial as it has been made to sound. It would take far too much time to explain why this is so difficult, and I would probably do a poor job anyway. > What we *do not* believe (correct me Richard if I misunderstood you) > is that Verisign (or whoever in their place) will actually do more > than verifying that www.goodguys.org is really existing and it's > there. And this is just a protection against hackers but has nothing > to with consumer's privacy or security. People at goodguys.org will > not be checked anyway as far as they behaviour as a company is > concerbed (that would cost *much* more than $200 and it would be way > to easy for the crooks to buy themselves a virginity by doubling the > money). This is mostly accurate. Like I said, VeriSign is only making a statement that you are the legitimate and sole owner of a particular public key. The job of the digital certificate is to remove the dangers of online commerce. It does not add protections that are unavailable in the "real" world. Thinking of using a credit card online as analogous to mailing your credit card to a company using physical mail. SSL provides a way to guarantee that your credit card is safe and secure until it reaches its final destination. If you have to do business with a shady company because you depend on their service, no technology is going to help you, and no one has tried to claim that it can. SSL just removes the additional dangers that would be present doing business online. > Which is why I still like better to transfer all credit card > processing to banks and have my sites saying that "WE DO NOT PROCESS > CREDIT CARDS AT ALL". When they want to pay they see a bank logo and > domain, not mine. And if anything goes wrong it will be a bank > problem, not mine. I think this is a wise approach, personally. Some would argue that it is slightly less convenient, but if you are concerned with people trusting you, this might ease their worries and coerce them into doing business with you. >> This would be a scary thought. Luckily it's not possible. A key pair >> is unique per Web server, right? Well, recall that the digital >> certificate only guarantees that a certain public key belong to a >> certain entity (in this case, a Web server). > > > There is a post saying the just transfered the keys. How? Maybe they > just signed the new keys with the old ones? This is even *more* scary. > But it can't be. The planet would be full of replicant keys. So what? You can actually export a Web server's keys. I didn't want to bring this up before, because it adds unnecessary doubt to the security of the whole operation without adequate explanation, and I don't have the time nor the background to adequately explain this particular point. Perhaps someone else can. Suffice it to say that exporting/importing a key is analogous to the "mv" command in UNIX, not the "cp" command. There will only be one copy of the key. I think I'm going to compile all of my SSL explanations into a more clear and informative explanation and post it on the Web somewhere. I've ended up explaining a great deal about the technical details, because I somehow felt as if I were having to defend the legitimacy of the whole technology. :) Happy hacking. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
