Skip to main content
Cryptography

Return to Answer

added 963 characters in body
Source Link
Maarten Bodewes ♦
Maarten Bodewes ♦
  • 94.5k
  • 13
  • 165
  • 319

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 extensionkey 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).

Leaf certificates can be used for anything except signing certificates or(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:

Note:

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

Here is a table that in TLS 1.3 the leafindicates how specific key is exclusivelytypes can be used for entity authentication, which corresponds to digitalSignature.

Key typeSignatureEncapsulationKey agreement
RSA keysYesYesNo
DH keysNoNoYes
DSA keysYesNoNo
EC keys (Koblitz & Prime curves)YesNoYes
Ed25519 & Ed448YesNoNo
X25519 & X448NoNoYes

Note that RSAIn the case of public keys can, the actions would be used for both signature verification andverification and encryption, but not for the first two usages.

Both key agreement. Diffie-Hellman (DH) keys and key encapsulation can just be used for key agreementestablishment. Most Elliptic CurveHowever, if the keys canare part of a persistent certificate then they cannot be used for signature verification andforward secrecy, which is why key agreement in e.g. TLS 1.3 is performed using (although the modern Ed25519ephemeral keys, and Ed448 safe-curves differ ever so slightly from their cousinsthe 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. That said, usually it is best to use a

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 / certificate for one and only one particular use case- it seems to be implied that they should be compatible.

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).

Leaf certificates can be used for anything except signing certificates or CRL's. 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:

Note that in TLS 1.3 the leaf key is exclusively used for entity authentication, which corresponds to digitalSignature.

Note that RSA public keys can be used for both signature verification and encryption, but not key agreement. Diffie-Hellman (DH) keys can just be used for key agreement. Most Elliptic Curve keys can be used for signature verification and key agreement (although the modern Ed25519 and Ed448 safe-curves differ ever so slightly from their cousins used for key agreement). That said, usually it is best to use a key / certificate for one and only one particular use case.

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).

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:

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 typeSignatureEncapsulationKey agreement
RSA keysYesYesNo
DH keysNoNoYes
DSA keysYesNoNo
EC keys (Koblitz & Prime curves)YesNoYes
Ed25519 & Ed448YesNoNo
X25519 & X448NoNoYes

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.

Source Link
Maarten Bodewes ♦
Maarten Bodewes ♦
  • 94.5k
  • 13
  • 165
  • 319

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 or CRL's. 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 that in TLS 1.3 the leaf key is exclusively used for entity authentication, which corresponds to digitalSignature.

Note that RSA public keys can be used for both signature verification and encryption, but not key agreement. Diffie-Hellman (DH) keys can just be used for key agreement. Most Elliptic Curve keys can be used for signature verification and key agreement (although the modern Ed25519 and Ed448 safe-curves differ ever so slightly from their cousins used for key agreement). That said, usually it is best to use a key / certificate for one and only one particular use case.