recap so far

In the intro we have seen, how a digital signature works: a - (cryptographically secure) hash value of the data-to-be-signed gets - encrypted with the signers private half of the signers key pair

This nails down the content of the signed data, it can no longer be changed.
A typical Internet-forum smartass will now demonstrate, how the data can still be changed, garbled, disfigured and then call me an idiot.

But the fact of the matter is: if the data would be changed - because of a transmission error, a failed bit in a flash storage or intentionally - the signature would no longer match:
the changed data has a different hash value, so the hash from the signature no longer matches.

There is a reason, I use the IOU example in the motivation/intro: this is a typical example where on the receiving end of the communication (the signer is the transmitting end of the comms channel) someone might be tempted to try to change the data of the signed document.

But we use strong encryption here. "Strong" meaningin this context: not crackable.
So no one but the signer - who has access to their PrivKey - could have made the encrypted hash.
This is how the signature traces back to the signer.

Or rather: traces back to one specific keypair.
This is the keypair whose private half was used to encrypt the hash and whose public half therefore decrypts the hash.
But how do we tie a keypair to a person or a machine or other suchlike.
that is where the intro left off.

"Entity" in X.509 context

Lets first go on a little tangent to get some terminology straight.
The rest of terminology has to wait for another article.

In X.509 context, three terms pop up all the time - subject - entity (especially end-entity) - subscriber

For out purposes here, they are pretty much synonyms.
There are subtle differences, esepcially if a PKI does not allow a machine to be a subscriber, so a natural person must be a subscriber sponsoring an end-entity of the machine type, but such detail would cloud the big picture at this point.

"Entity" is chosen as a term that can encompass machines and people at the same time, without degrading people to mere machines or antropomorphising machines to semi-human state.
So Entity it is.
When you read that somewhere, in your head translate it to "machine or person or group of people" and you're 70% there to be an X.509 expert.

And an entity can be named.
A lot of things and non-things can be named, like people, organizations, machines, even cats.
An entity in our context always has a name.

tying a PrivKey to a PubKey

Actually, the headline is misleading (on purpose :-)

A keypair is always created as a pair. The math that creates it comes out with the pair.
For engineers, physicists, mathematicians and some other professionals, this is nothing special.
The math calculating an electrical force for example always comes out with 3 values, because the electric field is 3D, so the force has 3 components (like [x,y,z] or [value, theta, phi]).
And the square root of -1 comes out as (0 + i), a complex number that as 2 components.
And these are no calculated one-after-the-other, but at the same time: both together are one object.
For people with only highschool math under their belt, this is sometimes puzzling, so that is why I mention it here.

The keypair is 'one object that is created in one step.
It then gets split up into its halves, the private key or PrivKey and the public key or PubKey.

But the two halves are working together. Always.
What one key encrypts, the other key decrypts.

So there is no "tying them together", they are tied together by math, the very math that was used to create the pair.

tying a PubKey to a name

It is rather simple to tie a PubKey to a name.
Just put the PubKey and the name in a file and sign it.

As we have seen above: signing data nails it down, prevents it from being changed.

And if this data - lets call it a certificate already, because that is what this leads to - is signed by an entity that can be trusted to - diligently check the identity of the entity in question - check that the entity has control of the PrivKey half of the keypair

then we can trust the relation (name, PubKey).

And that is the one job a Certificate Authority (CA) has: - make the checks above - sign the data

in a trustworthy manner.

A big part of this "trutworthy manner" boils down to the CA keeping their private key actually private, ideally that is "not-copied-ever".
Which is kinda tricky, because shift happens and hardware fails, but there are ways to get close that I may elaborate on later.

So the one job of a CA is to sign certificates - that is, tie names to PubKeys - and be trustworthy about it.
And we will look into this "trustworty" thing later on, promised.

of course it is more complicated

When you take a certificate and decode it, there is much more stuff in it that just a PubKey and a name and a signature.
Like with the signatures from the intro, there needs to be more information of a more technical nature.
But the heart and core of a certificate is the (name, PubKey) relation.

So why call this a certificate then? What is "being certified" here?
Well, the relation (name, PubKey) gets certified.
With their signature, the CA certifies that this PubKey belongs to this named entity.

Many people assume the certificate to say something about the entity, like a birth certificate saying something about the person born or a TÜV certificate saying something about the safety or reliability of a machine.
But I find it most helpful tho think of it like this: - the certificate certifies the PubKey -- more specificall, it certifies the PubKey belonging to the entity named in the certificate.

Once you thing of a certificate being about the PubKey rather than the entity, a couple of things become easier.
For example the fact that people like to use multiple certificates, all bound to the same name (theirs), yet binding a different KeyPair.

Especially buerocrats seem to struggle with this.
The concept of "this is the persons certificate" rather than "this is one of the persons certificates" seems stuck in some heads and the fact that a person can and should have and use multiple certificates in their daily digital life gets blocked by stupid buerocracy.

The Certificate Authority

A CA is simply an entity in this structure so far.
An entity that issues certificates.

Before the CA signs the certificate, any data that might/will go into the certificate could still be changed.
Once the CA signs it, the content is nailed down.

This makes the CA the authoritative source of the information in the certificate.
And that is why it is called the Certificate Authority.

Now, the word "authority" describes a completely different type of organization in day-to-day dealing with - well - the authorities.
And that leads to confusion and mixups when we talk X.509.

So your next 10% of the way to X.509/TLS/Cryptostuff expert are right there: do not confuse a CA with a government authority.

Yes, the terminology could have been better.
Like so many other standards, the X.400 and X.500 series prove it all again: the hardest problem in Computer Science is "naming things".

the term "public"

The difference between the concepts of a Certificate Authority and a govenrment authority is pretty big.

The difference in the meaning of the word "public" in colloquial and X.509 contexts is much more subtle.
All the content of an X.509 certificate is considered "public".

But wait, the certificate has my name in it, does it not?
Indeed: there is the entities name in the certificate and that could be a persons name and that is very privacy-sensitive data.
So privacy-sensitive you might correctly classify it as private.

But X.509 is a standard that mainly deals with Key Pair Cryptography and its use (for both, encryption and signatures and authentication).
And in this Public Key Cryptography context, the entities name getting compromised (=published) does not compromise the cryptography.
Neither does publishing the PubKey - hence the designation "public key".

Please make sure, not to confuse the term "public information" in context of "privacy in the digital age" with the term "public information" in context of "cryptography"!

recap

So by leveraging the power of the digital signature we can tie keypairs to names.
We do so by issuing certificates containing the PubKey half of the keypair and the name of the entity the keypair belongs to.

We have also cought a glimpse at some terminology such as "Certificate Authority", "Certificate", "public information".
And I glossed over the term "trust" or "trustworthyness" a lot; this is to be corrected in another article.