1
$\begingroup$

Certificates are used very often in crypto. From the search, I am a bit confused what exactly is the "public key" inside a certificate essentially? Is it always a signature verification key, or could it also be the encryption key?

In my understanding, for root and intermediate CA certificates, the public key is always meant to be the signature verification key. But is it also true for the leaf certificate (end-entity)?

Please add links to authentic resources to support your answers and for further readings.

$\endgroup$

3 Answers 3

3
$\begingroup$

Is it always a signature verification key, or could it also be the encryption key?

The leaf public key (that is, the one owned by the end entity) most certainly can be an encryption key (or, for that matter, a key exchange public value, such as a DH keyshare). Such usages aren't even all that exotic.

$\endgroup$
5
  • $\begingroup$ If it is most certainly an encryption key, then how can a chain of trust proceed with this? For example, the Wikipedia page (en.wikipedia.org/wiki/Root_certificate#/media/…) is then completely wrong, as in there the "Root CA Public Key" in the "Root Certificate" is the signature verification key (vs. encryption key) as clearly shown by the arrow with the text "Verify Signature". Same holds Intermediate certificate. $\endgroup$
    – Curious
    May 13 at 9:01
  • $\begingroup$ @Curious: do my edits make my meaning more obvious? $\endgroup$
    – poncho
    May 13 at 12:58
  • $\begingroup$ yes, to state in simpler words: you are agreeing that the public key in root and intermediate certificates is always signature verification key, while the one in end-entity certificate is most certainly an encryption key (or DH keyshare G^X). Can you possibly refer me to some authentic resource which states that in a clear way? Might you also clarify "exotic"? $\endgroup$
    – Curious
    May 13 at 14:29
  • 1
    $\begingroup$ @Curious: actually, the end-entity public key could be a signature key as well (and that is actually pretty common). $\endgroup$
    – poncho
    May 13 at 14:39
  • $\begingroup$ a bit confused now, but to re-state my conclusion: the "public key" in all (meaning root, intermediate as well as end-entity) certificates is mostly signature verification key, and in some cases, the public key in end-entity certificate can be encryption key (or DH keyshare), right? Again, can you possibly refer me to some authentic resource which states that in a clear way? $\endgroup$
    – Curious
    May 13 at 14:58
2
$\begingroup$

The public key given in a leaf certificate may be suitable for signature verification, encryption, both, or neither (there are other possible roles for a key). Generally, certificates will include a key usage extension and probably also an extended key usage extension, which specify how the key may be used.

The key usage extension can specify any or all of: digitalSignature, contentCommitment (similar to digitalSignature, but different implications), keyEncipherment, dataEncipherment, keyAgreement, keyCertSign (a CA cert would have this one & probably some others), and cRLSign. One with the keyAgreement usage can also have encipherOnly or decipherOnly to modify that.

For example, I have an email (S/MIME) certificate that has the digitalSignature, keyEncipherment, and dataEncipherment bits set in its key usage extension. This means someone could use it to verify the signature on an email message I sent them, and also to encrypt a message to me (generally by encrypting a random symmetric key that'd be used to encrypt the actual message).

For another example, suppose you had a cert that only had the keyAgreement bit set in its key usage extension. That would mean that it could not be used for either signature verification or encryption, but only to negotiate keys via something like the Diffie-Hellman algorithm.

BTW, the usage of a key can be restricted in other ways too. For example, an elliptic curve key's "algorithm" field is usually given as id-ecPublicKey (which places no additional restrictions on it), but might be given as id-ecDH (meaning it can only be used for EC Diffie-Hellman key agreement) or id-ecMQV (meaning it can only be used for EC Menezes-Qu-Vanstone key agreement).

$\endgroup$
1
$\begingroup$

I think you are understanding correctly by now, but I think I can sum it up concisely.

The certification authorities, be it the root certification authority or any sub-CA's are used to sign other certificates. So to verify a trust path to a trusted certificate - usually the root - they are required to have a public key in them that can be used for verification of the certificates that they have issued. This corresponds to a key usage extension that indicates such usage:

The keyCertSign bit is asserted when the subject public key is used for verifying signatures on public key certificates. If the keyCertSign bit is asserted, then the cA bit in the basic constraints extension (Section 4.2.1.9) MUST also be asserted.

The cRLSign bit is asserted when the subject public key is used for verifying signatures on certificate revocation lists (e.g., CRLs, delta CRLs, or ARLs).

Usually both these key usages are enabled at the same time, as the certification authority is usually responsible for issuing certificates but also for revoking them. This corresponds to using the public key for signature verification of the certificates that have been issued by the certification authority.


Leaf certificates can be used for anything except signing certificates (by definition) and CRL's (by common practice). That means that the key usage may indicate anything else. Of course, the type of the key pair and the public key should be such that the key usage can be met:

Key usage Bit Public key must be able to perform
digitalSignature 0 Signature verification
nonRepudiation 1 Signature verification
keyEncipherment 2 Encryption (key encapsulation or wrapping)
dataEncipherment 3 Encryption (commonly still key encapsulation for hybrid cryptosystems)
keyAgreement 4 Key agreement (e.g. Diffie-Hellman)
keyCertSign 5 Signature verification
cRLSign 6 Signature verification
encipherOnly 7 Encryption (key encapsulation or wrapping)
decipherOnly 8 Encryption (key encapsulation or wrapping)

Note:

  • In TLS 1.3 the leaf key is exclusively used for entity authentication, which corresponds to digitalSignature.

Here is a table that indicates how specific key types can be used.

Key type Signature Encapsulation Key agreement
RSA keys Yes Yes No
DH keys No No Yes
DSA keys Yes No No
EC keys (Koblitz & Prime curves) Yes No Yes
Ed25519 & Ed448 Yes No No
X25519 & X448 No No Yes

In the case of public keys, the actions would be signature verification and encryption for the first two usages.

Both key agreement and key encapsulation can be used for key establishment. However, if the keys are part of a persistent certificate then they cannot be used for forward secrecy, which is why key agreement in e.g. TLS 1.3 is performed using ephemeral keys, and the signing keys are used for the required entity authentication.

Key agreement algorithms can be used to implement the integrated encryption scheme or IES. So any key agreement key pair can also be indirectly used for encryption.


These tables are original content; the X.509 RFC doesn't explicitly mention that the public key should be compatible with the intent indicated in the key usage - it seems to be implied that they should be compatible.

$\endgroup$
1
  • $\begingroup$ This is indeed concise. Can you add the links to the table, quotes etc. for further reading? $\endgroup$
    – Curious
    May 14 at 10:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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