Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
Example from http://en.wikipedia.org/wiki/X.509#Extensions_informing_a_specific_usage_of_a_certificate
1st certficate - freesoft
2nd - CA thawte
Don't we use the RSA public key from the 2nd certificate to verify the MD5 of the first certificate?
If so, then what is the use of a RSA public in the 1st?
The public key contained in a certificate can be used in two ways:
There is a great number of certificates on the Web, so in order to trust them, we use third party "Certificate Authorities". You have a list of trusted CA certificates built-in your browser. The main goal of this certificates is to sign other certificates, to prove that they are valid (If someone you trust tells you that another person is trustworthy, you just trust that other person - that is the logic anyway).
That is why we use the public key of the second certificate in your example to verify the signature of the first certificate. But you will then use this certificate for something (encryption, signature, etc.), and that is when you will need the certificate's public key.
In asymmetric cryptography:
See the glossary of the TLS specification:
public key cryptography: A class of cryptographic techniques employing two-key ciphers. Messages encrypted with the public key can only be decrypted with the associated private key. Conversely, messages signed with the private key can be verified with the public key.
In your example, you do indeed use the public key of the second certificate (a CA certificate) to verify the signature of the first certificate (an End Entity Certificate).
However, this step only establishes trust in the certificate itself. How you're going to use the public key of that EEC will depend on what it's used for.
When the certificate is presented by the server in SSL/TLS, the public key will be used as part of the handshake, to prove that the remote server has indeed the private key for the certificate it's using. Whether it's used for encrypting or verifying a signature depends on the details of the cipher suite used during this connection, more specifically, it depends on whether RSA or Diffie-Hellman (authenticated) key exchange is used.
A key point of the TLS handshake is to establish a shared pre-master secret between client and server. When using RSA key exchange, the client encrypts the pre-master-secret and sends it to the server (who is the only one able to decrypt it). When using DH, the client verifies the signature of the temporary parameters sent by the server during the DH exchange: the end result is also a shared pre-master-secret. The end-result is the same, though. If you really want to understand the difference between these two approaches, you'll probably have to read the TLS specification in details.
Other protocols and applications can make use of X.509 certificate (for example, e-mail signing/encryption with S/MIME). The public key in the certificate will always be used for one of:
The details of what that piece of data is and how it is used will vary depending on the protocol and application.
In this particular example, the usage of the FreeSoft certificate and key pair is unknown. It will, presumably, be used for something, but the example and the certificate do not make it clear what that "something" might be.
The FreeSoft certificate is an end-entity certificate, as the key usage does NOT include the extension that would mark it as a certificate authority. So, it's key pair will, in some way, help the key holder (FreeSoft) to do some sort of task, generally either:
signature - proof that it came from the key holder and has not been tampered with
encryption - protection that ensures that data sent to key holder will not be tampered with or viewed in transit
authentication - proof that the key holder is who he says he is because he holds a private key that isn't shared anywhere
Or a wide variety of subtler permutations of this.
But - in this example, it's impossible to say what, exactly.
In all practicality, I'd have a hard time figuring out what to do with this certificate, I'd have to have it re-made to make it useful, as most standard applications require some sort of key usage to be described within the certificate. As shown, this certificate has NO key usage, so it's fairly useless.
I believe in this case, it fits into the flaw of being an example for a specific point (certificate hiearchy) with little thought given to completeness.
