Utilizzo della chiave consigliato per un certificato client

6

Il mio programma ha il seguente flusso: un client invia un CSR al server, il server restituisce un certificato client e dopo che il client comunica con il server a un percorso che richiede un certificato firmato dal server (il certificato client)

Le mie domande sono:

  1. Ho impostato l'utilizzo della chiave estesa clientAuth nel certificato client generato. Devo aggiungere altri usi chiave? Forse KU "digitalSignature"?

  2. Che cosa significa l'uso del tasto "digitalSignature"? Ne ho letto il più possibile, ma non sono ancora sicuro se è applicabile a me (la migliore fonte di informazioni che ho trovato finora è stata questo ).

  3. Qual è il significato pratico dell'aggiunta di questo utilizzo chiave? (quali azioni verranno prevenute da client / server SSL ben educati?) Al contrario di non specificare alcun utilizzo chiave? (solo il clientAuth EKU)

posta yair 28.09.2014 - 15:12
fonte

2 risposte

7

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.

    
risposta data 28.09.2014 - 21:48
fonte
5

Ecco una risposta per libNSS:

Per libNSS usato da Mozilla Firefox answer è nascosto in ./certdb/certdb.c:

Durante il controllo effettivo dell'utilizzo:

  case certUsageSSLClient:
    /* 
     * RFC 5280 lists digitalSignature and keyAgreement for
     * id-kp-clientAuth.  NSS does not support the *_fixed_dh and
     * *_fixed_ecdh client certificate types.
     */
    requiredKeyUsage = KU_DIGITAL_SIGNATURE;
    requiredCertType = NS_CERT_TYPE_SSL_CLIENT;

se l'estensione KeyUsage non è impostata, si comporta come se fosse completamente impostata:

/* if the extension is not present, then we allow all uses */
cert->keyUsage = KU_ALL;

se impostato allora, beh, è impostato

    if (keyUsage & PKIX_DIGITAL_SIGNATURE){
            nssKeyUsage = nssKeyUsage | KU_DIGITAL_SIGNATURE;
    }

Il tipo di certificato NSS deve avere il set NS_CERT_TYPE_SSL_CLIENT. CertType è derivato da EKU:

se non è impostato nessun EKU allora NS_CERT_TYPE_SSL_CLIENT.

/* If no NS Cert Type extension and no EKU extension, then */
nsCertType = 0;
...
/* allow any ssl or email (no ca or object signing. */
nsCertType |= NS_CERT_TYPE_SSL_CLIENT | NS_CERT_TYPE_SSL_SERVER |
              NS_CERT_TYPE_EMAIL;

Se ci sono EKU, NS_CERT_TYPE_SSL_CLIENT è impostato SOLO se non è CA.

if (findOIDinOIDSeqByTagNum(extKeyUsage,
                SEC_OID_EXT_KEY_USAGE_CLIENT_AUTH) ==
    SECSuccess){
    if (basicConstraintPresent == PR_TRUE &&
    (basicConstraint.isCA)) {
    nsCertType |= NS_CERT_TYPE_SSL_CA;
    } else {
    nsCertType |= NS_CERT_TYPE_SSL_CLIENT;
    }
}

Quindi in pratica per libNSS (come ottenuto dal repository mercurial link il 25 ottobre 2015) come certificato client valido, dovrebbe corrispondere a una di quelle affermazioni:

  • EKU E KU NON sono impostati.
  • KU non è impostato AND EKU è impostato su clientAuth AND cert NON è una CA.
  • KU contiene la firma digitale E EKU NON è impostato
  • KU contiene digitalSignature AND EKU è impostato su clientAuth AND cert NON è una CA.
risposta data 21.10.2015 - 21:56
fonte

Leggi altre domande sui tag