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.
