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"

This means that nearly every Web client on the planet will trust that 
the public key mentioned in that digital certificate really belongs to, so any communication encrypted with it can only be 
decrypted by the private key of

>> 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 will use's public 
key to encrypt the communication. Then, only 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 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 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.


PHP General Mailing List (
To unsubscribe, visit:

Reply via email to