it-swarm.com.de

Empfohlene Schlüsselverwendung für ein Client-Zertifikat

Mein Programm hat den folgenden Ablauf: Ein Client sendet eine CSR an den Server, der Server sendet ein Client-Zertifikat zurück und danach kommuniziert der Client mit dem Server über einen Pfad, für den ein vom Server signiertes Zertifikat erforderlich ist (das Client-Zertifikat).

Meine Fragen sind:

  1. Ich habe die erweiterte Schlüsselverwendung clientAuth im generierten Clientzertifikat festgelegt. Sollte ich zusätzliche Schlüsselverwendungen hinzufügen? Vielleicht "digitalSignature" KU?

  2. Was bedeutet die Verwendung von "digitalSignature" -Schlüsseln? Ich habe so viel wie möglich darüber gelesen, bin mir aber immer noch nicht sicher, ob es auf mich zutrifft (die beste Informationsquelle, die ich bisher finden konnte, war this ).

  3. Was ist die praktische Bedeutung des Hinzufügens dieser Schlüsselverwendung? (Welche Aktionen werden von gut erzogenen SSL-Clients/Servern verhindert?) Im Gegensatz zur Angabe keiner Schlüsselverwendung? (nur die clientAuth EKU)

12
yair

TL-DR SSL-Client-Zertifikat benötigt keine KeyUsage, aber falls vorhanden, sollte es digitalSignature sein, mit Ausnahme von sehr seltenen, wenn überhaupt festen * DH.

Vorsichtsmaßnahme: Sie haben SSL markiert, daher gehe ich davon aus, dass Sie mit "Pfad, für den ein Zertifikat erforderlich ist" SSL/TLS oder etwas über SSL/TLS (nicht unbedingt HTTP/S) meinen. Wenn Sie eher CMS oder S/MIME oder XML-Sig oder sogar PGP meinen, kann die Antwort anders sein.

Ich bin überrascht, dass Sie keine anderen Referenzen finden, da X.509-Zertifikate so weit verbreitet sind. Meine erste Seite der Google X.509-Schlüsselverwendungserweiterung enthält PKIX rfc528 , die derzeit wirksame Internetspezifikation, und (die Textform von) sein Vorgänger rfc328 ; der nicht besonders gute Wikipedia-Artikel; und https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.0/html/Admin_Guide/Standard_X.509_v3_Certificate_Extensions.html mit (möglicherweise über-) spezifischen Anweisungen für mehrere Fälle, einschließlich SSL-Client. Zitieren des relevanten Teils von 5280 (den Ihre IBM Site mehr oder weniger kopiert):

   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.

Dies ist notwendigerweise etwas allgemein gehalten, da X.509 nd PKIX-) Zertifikate für eine Reihe von Dingen entwickelt wurden, nicht nur für SSL/TLS, obwohl dies die einzige Verwendung ist, die die meisten Menschen kennen. Es werden verschiedene Arten von Signaturen, Verschlüsselungen und Schlüsselvereinbarungen unterschieden (die in der Praxis zur Verschlüsselung verwendet werden).

5280/3280 schreibt KeyUsage nur für CA-Zertifikate vor und lässt es implizit für EE-Zertifikate optional. Ich habe kein aktuelles X.509, aber AFAIU sagt, wenn KeyUsage nicht vorhanden ist, wird es als alle gesetzten Bits behandelt, da dies mit v1 und v2 kompatibel ist, bevor es Erweiterungen gab. --- (CABforum-Basislinie gibt es explizit an, wie es für CA-Zertifikate erforderlich ist, aber optional für "Abonnenten" -Zertifikate (dh EE-Zertifikate).

TLSv1.2 (oder seine Vorgänger) erfordert ein Client-Zertifikat "Erlaube ... Signieren", mit Ausnahme des Fest-DH- und Fest-ECDH-Schlüsselaustauschs, den niemand zumindest in der Öffentlichkeit zu verwenden scheint net und verwandte Abschnitte erläutern, wie der Client-Schlüssel mit Ausnahme von Fest- * DH tatsächlich nur zum Signieren von Handshake-Daten verwendet wird, um den Besitz des Clients nachzuweisen und ihn somit zu authentifizieren. Das heißt, wenn KeyUsage für den SSL-Client vorhanden ist, muss es digitalSignature enthalten. Da ein Kryptoschlüssel im Allgemeinen nicht ohne starke Begründung für mehrere Zwecke verwendet werden sollte, sollte KeyUsage für den SSL-Client nichts anderes enthalten. Wenn das Clientzertifikat nicht über KeyUsage oder eine nicht einschränkende KeyUsage verfügt, verwendet eine konforme SSL/TLS-Implementierung diesen Schlüssel und dieses Zertifikat weiterhin nur auf die im Protokoll angegebene Weise, die außer festem * DH, wie angegeben, nur Signieren/Überprüfen von Daten, die kein Zertifikat oder keine CRL sind.

12

Hier eine Antwort für libNSS:

Für libNSS, das von Mozilla Firefox verwendet wird, ist die Antwort in ./certdb/certdb.c versteckt:

Bei der tatsächlichen Überprüfung der Nutzung:

  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;

wenn die KeyUsage-Erweiterung nicht festgelegt ist, verhält sie sich wie vollständig festgelegt:

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

wenn es dann gesetzt ist, ist es gesetzt

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

Für den NSS-Zertifikatstyp sollte NS_CERT_TYPE_SSL_CLIENT festgelegt sein. CertType ist von der EKU abgeleitet:

wenn keine EKU vorhanden ist, wird NS_CERT_TYPE_SSL_CLIENT festgelegt.

/* 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;

Wenn EKU vorhanden sind, wird NS_CERT_TYPE_SSL_CLIENT NUR festgelegt, wenn keine Zertifizierungsstelle vorhanden ist.

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;
    }
}

In der Praxis sollte libNSS (wie aus dem Mercurial-Reposoritory https://hg.mozilla.org/projects/nss am 25. Oktober 2015) als gültiges Client-Zertifikat mit einer dieser Aussagen übereinstimmen:

  • EKU UND KU sind NICHT eingestellt.
  • KU ist nicht gesetzt UND EKU ist auf clientAuth gesetzt UND cert ist KEINE Zertifizierungsstelle.
  • KU enthält digitalSignature UND EKU ist NICHT eingestellt
  • KU enthält digitalSignature UND EKU ist auf clientAuth gesetzt UND cert ist KEINE Zertifizierungsstelle.
7
philippe lhardy