TL-DR CERT client SSL non ha bisogno di KeyUsage ma se presente dovrebbe essere digitalSignature tranne che per rarissimo-if-ever fixed- * DH.
Attenzione: hai taggato SSL quindi presumo per "percorso che richiede un certificato" intendi SSL / TLS o qualcosa su SSL / TLS (non necessariamente HTTP / S). Se intendi qualcosa di più come CMS o S / MIME, o XML-sig, o anche PGP, la risposta potrebbe essere diversa.
Sono sorpreso che non trovi altri riferimenti poiché i certificati X.509 sono così diffusi. La mia prima pagina dell'estensione di utilizzo della chiave X.509 di Google fornisce PKIX rfc5280 che è l'Internet attualmente efficace spec e (la forma del testo di) il suo predecessore rfc3280 ; l'articolo wikipedia non terribilmente buono; e link che ha (possibilmente oltre) specifiche istruzioni per diversi casi incluso il client SSL. Citando la parte rilevante di 5280 (che il tuo sito IBM ha più o meno copie):
Bits in the KeyUsage type are used as follows:
The digitalSignature bit is asserted when the subject public key
is used for verifying digital signatures, other than signatures on
certificates (bit 5) and CRLs (bit 6), such as those used in an
entity authentication service, a data origin authentication
service, and/or an integrity service.
The nonRepudiation bit is asserted when the subject public key is
used to verify digital signatures, other than signatures on
certificates (bit 5) and CRLs (bit 6), used to provide a non-
repudiation service that protects against the signing entity
falsely denying some action. In the case of later conflict, a
reliable third party may determine the authenticity of the signed
data. (Note that recent editions of X.509 have renamed the
nonRepudiation bit to contentCommitment.)
The keyEncipherment bit is asserted when the subject public key is
used for enciphering private or secret keys, i.e., for key
transport. For example, this bit shall be set when an RSA public
key is to be used for encrypting a symmetric content-decryption
key or an asymmetric private key.
The dataEncipherment bit is asserted when the subject public key
is used for directly enciphering raw user data without the use of
an intermediate symmetric cipher. Note that the use of this bit
is extremely uncommon; almost all applications use key transport
or key agreement to establish a symmetric key.
The keyAgreement bit is asserted when the subject public key is
used for key agreement. For example, when a Diffie-Hellman key is
to be used for key management, then this bit is set.
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).
The meaning of the encipherOnly bit is undefined in the absence of
the keyAgreement bit. When the encipherOnly bit is asserted and
the keyAgreement bit is also set, the subject public key may be
used only for enciphering data while performing key agreement.
The meaning of the decipherOnly bit is undefined in the absence of
the keyAgreement bit. When the decipherOnly bit is asserted and
the keyAgreement bit is also set, the subject public key may be
used only for deciphering data while performing key agreement.
Questo è necessariamente un po 'generale perché i certificati X.509 (e PKIX) sono stati progettati per essere utilizzati per una serie di cose, non solo per SSL / TLS, anche se questo è l'unico uso che la maggior parte delle persone conosce. Distingue vari tipi di firma, crittografia e keyagreement (che in pratica viene utilizzato per la crittografia).
5280/3280 impone solo KeyUsage per i certificati CA, lasciandolo implicitamente facoltativo per i certificati EE. Non ho X.509 effettivo ma AFAIU dice che se KeyUsage non è presente viene trattato come tutti i bit impostati, perché è compatibile con v1 e v2 prima che esistessero estensioni. CABforum baseline lo specifica esplicitamente come richiesto per i certificati CA ma facoltativo per i certificati "subscriber" (cioè EE).
TLSv1.2 (oi suoi predecessori) richiede un certificato cliente "consenti ... firmando "eccetto per gli scambi di chiavi fixed-DH e fixed-ECDH che nessuno sembra utilizzare almeno sulla rete pubblica, e le sezioni correlate spiegano come, ad eccezione del DH fisso-*, la chiave del client viene effettivamente utilizzata solo per la firma dei dati di handshake per dimostrare il possesso e quindi autenticare il cliente.
Ciò significa che se KeyUsage è presente per il client SSL, deve includere la firma digitale e, poiché in generale una chiave di crittografia non deve essere utilizzata per più scopi senza una valida giustificazione, KeyUsage per il client SSL non deve includere altro. Se il certificato del cliente non ha KeyUsage o ha KeyUsage non restrittivo, un'implementazione SSL / TLS conforme continuerà a utilizzare quella chiave e il certificato solo nel modo specificato dal protocollo, che tranne la funzione fixed- * DH, come indicato, sta firmando / verificare i dati che non sono certificati o CRL.