Boost Legal Compliance with Digital Signature Legitimacy for Your Terms of Use Agreement

How to eSign a document: digital signature legitimacy for Terms of Use Agreement

The point of public key encryption is that the public key component is really public. That is, any user can send his or her public key to any other user or just broadcast it to the world. Although this approach is very convenient, it has a major weakness. That is, anyone can forge such a public announcement. Some user could pretend to be Bob, and send a public key to another user such as Alice, and tell Alice that this is Bob's public key. The result is that when Alice sends a private message to Bob saying she encrypts it using Bob's public key. But remember this Bob's public key is actually forged by the attacker. Then the message can be intercepted by the attacker, and can be read by the attacker. Now, at some point hopefully, Bob can discover that there's a forgery going on and a public key of his was being used. But then what can Bob do? Bob can send Alice another message saying that, hey, this is my real public key. But how could Alice tell? That is, how could Alice tell that the previous key was a forgery and this key, that Bob just sent, is real. The solution to this problem of public key forgery is to use a public key certificate. In essence, a certificate consists of Bob's public key and Bob's information such as the user ID, let's say his name and address and so on. The certificate authority's information. And the whole blog is signed using the certificate authority's private key. The certificate can also include other information, such as the period of validity of this certificate, that is, for how long this certificate is valid for this public key, say, one year. Now let's see how certificate is created, and how it is verified, and how it is being used to distribute public key. Suppose Bob wants the certificate authority CA to create a certificate for his public key. Bob would contact the CA and provide authentication information such keys driver's license and so on, and then he will send his public key to CA. The CA will then put his ID, his public key and other information such as the period of validity together and then hash it. And then the CA will use his private key to sign the hash. So that creates the certificate of Bob's public key. Now Bob can send this public key certificate to anybody such as Alice. When Alice receives this public key certificate, she can first extract the key types of information of Bob's idea, public key, and all the information. And then she will hash this data, and then Alice will also use the certificate authorities public key to decrypt the signature or verify the signature and compare these two hash values. If they match, that means this public key has been properly signed by the CA. In other words, this public key of Bob's has been validated by the CA. So this is how public key certificate works. Now of course, the underlying assumption is that. The CA is a trusted party by everybody involved. In practice, the CA is a well-known company such as Verisign, Microsoft, Google, or Apple, and the public keys are already stored in, for example your web browser. That is with these public keys already configured on your system, they can automatically validate public key certificates signed by these entities.