Once Bob has a copy of Sally’s public key, he can then send her encrypted messages, but the reverse is not true. Until Sally also has Bob’s public key, she cannot send encrypted messages to him. The only way that the system works at all is if Bob and Sally both trust the CA to prove their identities.
An important consideration when looking at public key cryptography is that the whole deal has a great deal of overhead (computationally) associated with it. For this reason, public key cryptography is often used not to encrypt all data, but instead to encrypt something referred to as a session key. In non-email applications (such as visiting a secure website), instead of encrypting all data back and forth using public and private keys, the client machine creates a session key that is used for the purpose of encrypting data by both the client and the server. This session key is passed from the client to the server using public key encryption, but from that point all data is encrypted with the session key – this is both faster and more efficient that encrypting everything using the associated public keys. Once the session is over, the session key is destroyed, and a new one will be used when another session is created.
Now that you have an overview of what the keys do, it is important to understand that certificates also expire. When they are created by a CA, certificates are also given an expiry date, again similar to a license. If the license is expired, it may still be in your pocket, but is not considered valid. The same holds true for a certificate – including the fact that the issuer may revoke the certificate. In certificate-speak, revoked certificates are published to something called the Certificate Revocation List (CRL), a list available to client systems that choose to check it. Reasons for revoking a certificate include the associated private key having been compromised, misuse, and so forth. The situations under which certificates are revoked are at the discretion of the CA.