Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is there an accepted naming convention for referring to PKI artifacts?

There seems to be a lot of confusion with naming of artifacts. For example, it seems that some people refer to:

  • public keys as certificates
  • public keys as public keys
  • certificates as public keys
  • certificates as certificates
  • private keys as key pairs
  • private keys as private keys
  • etc ..

Is there an authoritative reference or glossary that I can refer to?

share|improve this question
Just a quick note - you may have accepted my answer, but please read Tom Leek's answer too. It's much more comprehensive and he's an actual cryptographer, so this kind of question is right in his ballpark. – Polynomial Sep 23 '13 at 15:57
up vote 10 down vote accepted

The following are the "accepted naming", i.e. the terms that I would accept:

A public key is a mathematical object; it is half of the cryptographic key pair. For RSA, a public key is a pair of big integers (modulus and exponent), nothing more.

A private key is a mathematical object; it is the other half of the key pair. For RSA, a private key is a bunch of big integers (namely n, e, d, p, q, d mod p-1, d mod q-1 and q-1 mod p, where n and e are copies of the two corresponding values from the public key).

A key pair is a public key with the corresponding private key.

A certificate is a signed object which some elements and binds them together. That's what X.509 is about. Most certificates contain a public key (not the private key) and an identity (a "name") designating the owner of that key (i.e. the entity who controls the corresponding private key).

That being said, a lot of people use sloppy terminology and you can encounter a lot of jargon abuse. E.g.:

  • For usual algorithms (everybody uses RSA), the public key is easily recomputed from the private key (with RSA, the public key is a subset of the private key, so this recomputing is trivial). This leads some people to talk about "key pair" when they mean "private key" or vice versa.

  • Some people (in particular a substantial fraction of Microsoft's documentation) talk about "certificate" when they mean "the certificate and the private key corresponding to the public key which is in the certificate". PKCS#12 archive files (also known as "PFX") are usual containers for a certificate and its private key.

  • Many people don't grasp the difference between a certificate and a public key, and use the two terms in a seemingly random way.

  • Confusion is further enhanced when people being to talk about "public certificates" or "private certificates". Part of the problem is that games with key pairs and RSA-like algorithms are called public-key cryptography as opposed to "normal" cryptography, i.e. symmetric algorithms like AES. In symmetric cryptography, keys are secret and no key can be made public. So there is an expression: secret key. This term normally designates a key for a symmetric algorithm, which is a bunch of bits. But some people say "secret key" when they mean "private key", or vice versa.

  • I have also encountered "digital identity", "private identity", or "digital credentials", meaning a certificate, a private key, both, or something else. Depending on who does the talking.

  • There is also a notion of secret-key certificate which is either someone who considers "secret" and "private" to be interchangeable, or the specific case of a certificate used in some advanced "blind signature" schemes. This is research-level work, nothing standardized.

Bottom-line is that if you want to be reliably understood, then you must take care to define your terminology properly. Similarly, be prepared, when reading documents from other people, to encounter just about anything. Decent standards begin with a glossary which unambiguously defines the meaning of terms within the standard.

share|improve this answer
Great answer. I would add that in my experience as an engineer, it's a critical skill to listen to everyone in a meeting, identify the misuse of any technical term, and getting people to agree on the proper definition. That one skill fixes more problems than you could possibly imagine! – John Deters Sep 23 '13 at 19:30
I like that "Confusion is further enhanced..." -- If your confusion is insufficient, you can enhance it by using terms like "private certificate". – tylerl Sep 24 '13 at 4:55

All three are totally distinct concepts.

A public key, in reference to any asymmetric cryptosystem, is the key which can be made available to parties that wish to be involved with you. A private key, conversely, is the corresponding private part of the asymmetric key pair that you keep secret.

A certificate is a standardised format for representing identity. The identity may contain key material, or it may just be a statement of identity signed by a secondary key. In traditional HTTPS, the certificate contains the public key of the web server, and the certificate is usually signed by a trusted 3rd party.

share|improve this answer

The examples that you gave look quite right except when you referred private keys as key pair.

When asymmetric keys are generated they are generated as a key pair I.e. Public and Private keys. Private key should not be referred as key pair.

About certificates: if I have your x.509 certificate I can always say that I have your public key as the public key is a part of the x.509 certificate.

The one thing that I have noticed is that some people get confused between the terms 'private' and 'secret'. The private key is supposed to be kept as a secret but generally secret key is used to refer to the shared secret in symmetric key algorithms.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.