Keys vs Certificate & x509 vs GPG

Question

I understand a fair bit about keys in regards to what the private key does, and the public key for technologies such as PIV and GPG.

Where I get lost is how the certificate comes into play and what you're supposed to do with it.

For example, the private key is obviously yours and you use it to decrypt messages or files related to GPG that are sent to you. Your public key is what you give other people or upload to a public keyserver so that people can send you encrypted messages.

But aside from the public and private keypairs, there's also an option in software such as Kleopatra to generate a CSR for my GPG Keys.

• What is the purpose of generating that CSR if I have the private / public keys already.
• What do I do with that CSR if I do generate one? Do I hold on to it and keep it private like I would my private keys?
• What's the different between an x509 certificate that can be generated for PIV, and a certificate I can generate for GPG. Are they the same thing? x 509 certificate? Just different technologies use to generate them?

If you're confused about PIV, I'm referring to Yubikeys. They contain two interfaces that appear to do similar things: PIV and GPG.

And to clarify, I don't have a CA, I am generating a self-signed certificate.

And I guess the bonus question I have because I seem to be finding no clear answer, what's the difference between exporting a CRT, CSR, and say a PEM.

I found an explanation here: https://crypto.stackexchange.com/questions/43697/what-are-the-differences-between-pem-csr-key-crt-and-other-such-file-exte

But some of the definitions don't register with me. Maybe over-complicated for my limited knowledge?

Thanks!

Answer 1

What is the purpose of generating that CSR if I have the private / public keys already.

The problem with a raw public key is that it says nothing about who owns the private key. I can use it to send and receive encrypted communications from you, but I need a separate trusted channel by which to verify you are who you say you are.

That's where certificates come in. A certificate is a combination of a public key and metadata about that key such as who owns the private key and what it's supposed to be used for. This metadata can then be signed by a trusted third party who has verified that you do in fact own the private key and that the metadata is correct.

This way, you can send me a certificate and I can both read your encrypted messages and verify, via a trusted third party, that you are who you say you are.

What do I do with that CSR if I do generate one? Do I hold on to it and keep it private like I would my private keys?

A CSR, or Certificate Signing Request, is the same public key and metadata that would be in a certificate, but without a signature. This is what you generate and send to a certification authority to have signed and turned into a certificate.

If you don't use a CA and self-sign your certificate then you're giving up most of the benefits that a certificate provides in the first place. The CA is the trusted third party who verifies that you are who you say you are. Without one there's no way to verify that the metadata in the certificate is accurate.

---

Regarding your bonus question:

• PEM is just a text-based wrapper for transferring binary data over channels that don't like non-text data. This is useful for, for instance, embedding a PGP signature into an email. It's formatted like this:

-----BEGIN <thing>-----
<bunch of data>
-----END <thing>-----

Pretty much anything can be wrapped in PEM, but it's used primarily for cryptography-related data such as keys and certificates.

• CSR is, as mentioned above, short for Certificate Signing Request. These may or may not be wrapped in a PEM text encoding. Different software will support different formats.
• CRT is a certificate. Again, this may or may not be wrapped in PEM text encoding. As for CSRs, different software will support different formats.

Answer 2

What is the purpose of generating that CSR if I have the private / public keys already.

If you send your public key to somebody, how will one know that this is really your key? There can be a man-in-the-middle sitting between you and another party who intercepts you traffic and send own public key instead of yours and vice versa. A certificate proves that particular public key really belongs to you.

Certificates are issues by certification authorities, CAs. Before issuing a certificate, a CA checks the claims that you requested, e.g. if the email address belongs to you (for S/MIME certificates), if domain name belongs to you (for TLS certificates), postal address and others (for extended validation certificates).

To obtain a certificate, you send a request to CA. Such request is named CSR, Certificate Signing Request. You request that the CA issues and signs a certificate that confirms that the given public key belongs to you. This request contains fields that you want to have in your certificate, like the name, validity period. To prevent that anyone requests certificate for given public key, this request must be signed by a private key that matches the public key.