web-dev-qa-db-ja.com

クライアント証明書の推奨されるキーの使用法

私のプログラムのフローは次のとおりです。クライアントがサーバーにCSRを送信し、サーバーがクライアント証明書を送り返します。その後、クライアントはサーバーとの通信に、サーバーが署名した証明書（クライアント証明書）を必要とするパスを使用します。

私の質問は：

  1. 生成されたクライアント証明書にclientAuth拡張キーの使用法を設定しました。追加のキー使用法を追加する必要がありますか？多分「digitalSignature」KU？

  2. 「digitalSignature」のキーの使用法はどういう意味ですか？私はできる限りそれについて読みましたが、それが自分に当てはまるかどうかはまだわかりません（これまでに見つけられた最良の情報源は this でした）。

  3. この主要な使用法を追加することの実際的な意味は何ですか？ （適切に動作するSSLクライアント/サーバーによって防止されるアクションはどれですか？）キーの使用法を指定しないのとは対照的に？ （clientAuth EKUのみ）

tlscertificatespublic-key-infrastructurex.509
12
yair

TL-DRSSLクライアント証明書はKeyUsageを必要としませんが、存在する場合、very-rare-if-ever fixed- * DHを除いてdigitalSignatureでなければなりません。

警告：SSLにタグを付けたので、「証明書が必要なパス」とは、SSL/TLSまたはSSL/TLS上の何か（必ずしもHTTP/Sである必要はない）を意味していると思います。 CMSやS/MIME、XML-sig、さらにはPGPのようなものを意味する場合、答えは異なる場合があります。

X.509証明書が非常に広く使用されているため、他の参照が見つからないことに驚いています。 google X.509キー使用拡張機能の最初のページには、現在有効なインターネット仕様である PKIX rfc528 と（テキスト形式） その前身のrfc328 が表示されます。あまり良くないウィキペディアの記事;および https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.0/html/Admin_Guide/Standard_X.509_v3_Certificate_Extensions.html これには、次のようないくつかのケースについて特定の指示が（おそらくオーバー-）ありますSSLクライアント。 5280の関連部分（IBMサイトが多かれ少なかれコピーしている）を引用します。

   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.

X.509（およびPKIX）証明書はSSL/TLSだけでなく、さまざまな目的で使用されるように設計されているため、これは必然的にある程度一般的ですが、これはほとんどの人が知っている唯一の使用方法です。これは、いくつかのタイプの署名、暗号化、および鍵の一致（実際には暗号化に使用されます）を区別します。

5280/3280はCA証明書のKeyUsageのみを要求し、EE証明書の場合は暗黙的にオプションとします。私は実際のX.509を持っていませんが、AFAIUはKeyUsageが存在しない場合、すべてのビットセットとして扱われます。これは、拡張が存在する前はv1およびv2と互換性があるためです。 CABforumベースライン CA証明書には必須であるが、「サブスクライバー」（EEを意味する）証明書ではオプションとして明示的に指定します。

TLSv1.2 （またはその前任者）は、少なくとも公的には誰も使用していないと思われるfixed-DHおよびfixed-ECDH鍵交換を除いて、クライアント証明書の「許可...署名」を必要としますnetおよび関連するセクションでは、fixed- * DHを除いて、クライアントキーが実際にハンドシェイクデータの署名にのみ使用され、クライアントが所有権を証明して認証する方法について説明します。これは、SSLクライアントにKeyUsageが存在する場合、digitalSignatureを含める必要があることを意味します。一般に、強力な正当化なしに暗号鍵を複数の目的に使用することはできないため、SSLクライアントのKeyUsageには他に何も含めないでください。クライアント証明書にKeyUsageがないか、制限のないKeyUsageがある場合、準拠するSSL/TLS実装は、プロトコルで指定された方法でのみそのキーと証明書を使用します。ただし、fixed- * DHは署名/証明書またはCRLではないデータの検証。

12
dave_thompson_085

ここにlibNSSの答えがあります：

Mozilla Firefoxで使用されるlibNSSの場合、回答は./certdb/certdb.c内に隠されています。

実際に使用状況を確認する場合：

  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;

keyUsage拡張機能が設定されていない場合、完全に設定されているかのように動作します。

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

それが設定されている場合、まあ、それは設定されています

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

NSS証明書タイプにはNS_CERT_TYPE_SSL_CLIENTセットが必要です。 CertTypeはEKUから派生しています：

eKUがない場合は、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;

EKUがある場合、NS_CERT_TYPE_SSL_CLIENTは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;
    }
}

したがって、実際にはlibNSS（Mercurial reposoritory https://hg.mozilla.org/projects/nss 2015年10月25日）が有効なクライアント証明書であるためには、これらのアサーションのいずれかと一致する必要があります。

  • EKUとKUは設定されていません。
  • KUが設定されておらず、EKUがclientAuthに設定されており、証明書がCAではない。
  • KUにdigitalSignatureが含まれていて、EKUが設定されていない
  • KUにdigitalSignatureが含まれており、EKUがclientAuthに設定されており、証明書がCAではない。
7
philippe lhardy