The key usage extension defines the object (for example. B the encryption, the signature, the signature of the certificate) of the key contained in the certificate. The use restriction can be used to limit a key that could be used for more than one process. If z.B. an RSA key should only be used to verify signatures for items other than certificates and crLs with public keys, the digitalSignature and/or non-Repududiation bits are confirmed. If an RSA key is only used for key management, the keyEncipherment bit is also confirmed. Is used when the sender and recipient of the public key must deduct the key without encryption. This key can then be used to encrypt messages between the sender and the recipient. The key agreement is usually used with the Diffie-Hellman codes. DataEncipherment does not apply because encrypted data is not directly significant, but a value that is most often randomly generated and used to unlock symmetrical keys. KeyAgreement does not apply either, as this applies to key algorithms in the agreement that are not cases of asymmetric encryption (z.B. Diffie-Hellman).
KeyAgreement`s use flag is displayed in a certificate containing a DH key and not an RSA key. Non-repudiation is not used because anything signed as part of an SSL/TLS key exchange cannot be used as evidence for a third party (there is nothing in an SSL/TLS tunnel that the client could register and use to convince a judge if he pursues the server himself; the data exchanged inside the tunnel is not signed by the server). I only touch RSA keys, so the exchange methods are RSA (generate a key, encrypt it and send it over) and [EC] DHE_RSA (generate a volatile DH key, sign it and use it for key agreements). When a certificate has several extensions limiting its use, all restrictions must generally be met for a specific use to be appropriate. RFC 5280 gives the specific example of a certificate containing both keyUsage and extendedKeyUsage: In this case, both must be processed and the certificate can only be used if the two extensions are consistent to indicate the use of a certificate. NSS uses z.B both extensions to indicate the use of the certificate. [11] If a certificate contains both a critical key use field and an advanced critical use field of the keys, both fields must be treated independently and the certificate can only be used for purposes consistent with both fields. If no purpose is in agreement with the two boxes, the certificate should not be used for purposes. The real process in RSA is “Key Encipent,” and in [EC]DHE_RSA, it`s digital signature, but they are both forms of the key chord. Which of “Key Encipentment,” “Digital Signature” and “Key Agreement” are therefore needed in the key usage extension for each method? I haven`t found it, and it probably varies depending on the implementation, so the answer could be an implementation table. A DHE or ECDHE encryption suite is used; In this case, the RSA key is used for a signature (see section 7.4.3 of RFC 5246: message “Server key exchange”); This allows the use of digitalignature keys; By default, the keyUsage value is set at 0, indicating that it is not set.
Use set to explicitly define the use value of the keys. Digital signature, key encryption or key agreement advanced use of keys refines key usage extensions. An extended key is either critical or non-critical. If the extension is critical, the certificate can only be used for specified purposes or purposes. If the certificate is used for other purposes, it is contrary to the certification body`s directive.