web-dev-qa-db-ja.com

CAは、署名している証明書と同じタイプの鍵を持っている必要がありますか？ RSA /楕円曲線（EC / ECDH / ECDSA）

RSAおよび楕円曲線対応（EC）鍵に署名できるCAを作成しています。私は最善のアプローチが以下であるかどうか疑問に思いました：

  1. RSAおよびEC CSRに署名できるRSAキーを備えたCA
  2. RSAおよびEC CSRに署名できるECキーを備えたCA
  3. 2つのCA鍵セット（1つのRSA、1つのEC）それぞれがそれぞれのタイプのCSRに署名
  4. 2つの個別のCA

これを行うにはopensslを使用しています。

アイデアや提案は大歓迎です、ありがとう！

cryptographytlscertificatescertificate-authority
15
aspergillusOryzae

X.509では、署名された証明書の鍵のタイプに関係なく、CAは任意の署名アルゴリズムを使用できます。 理論的には、CAと署名付き証明書の両方がDSAキーまたはECキーを使用し、2つのキーが同じグループパラメーターを共有する場合（ECキーの場合、同じ曲線上で機能する）、次に、署名された証明書で曲線の指定が省略される場合があります。 ECキーの場合、これはおそらく数十バイトを節約する可能性があり、PKIX（ インターネットX.509プロファイル を担当するグループ）はこの「最適化」を明示的に禁止します。したがって、私は自信を持って、CA証明書のキーのタイプとCAが発行する証明書の間にリンクがないと述べています。

既存の展開済みソフトウェアベースのECサポートは、「不安定」と表現できます。 X9.62 は、非常に任意の曲線でECキーのパラメーターをエンコードする方法を指定しますが、ほとんどすべての人が、主に FIPS 186- 。実際、これらの15の曲線のうち、そのうち2つ（P-256とP-384）のみが既存のブラウザーで非麻酔サポートを持っています。これらの2つの曲線は、NSA "suite B"（NSAからの非NSAの人々への推奨- 「スイートA」を構成することは公に知られていない）。

また、X9.62は、ハッシュ関数と曲線のすべての組み合わせに対してECDSA署名をどのように計算するか（つまり、ハッシュグループの順序に合わせてハッシュ値を切り捨てまたは拡張する方法）を明確に定義しています。予想通り、実装者はそれを誤解しており、P-256（またはP-384）ではSHA-256（またはSHA-384）しか使用できないと多くの人が信じています。したがって、他のハッシュ関数を使用すると、相互運用性の問題が発生します（つまり、ディスコ時代に生まれなかったアルゴリズムを使用しようとするだけの場合よりも多くの問題が発生します）。

明るい面は、SHA-256を備えたP-256はセキュリティ面で「問題ない」ことです（私はそのWordが大好きです）。暗い面は、その最もサポートされている組み合わせでも、古いブラウザーで問題が発生する（そして、更新に関してかなり保守的な場所があります-私の職場では）許可される唯一のブラウザはIE 7！）です。したがって、バックアップ計画が必要です。バックアップは、RSA PKI全体（ルートからサーバーおよびユーザー証明書までのあらゆる場所にあるRSA）である必要があるため互換性のために、最終的にEC全体のPKIに切り替えるには、2つのルートが必要です。1つはRSAで、もう1つはECです。相互認証を使用すると、移行をある程度スムーズにすることができますが、ワーム。

13
Tom Leek

トムの答えはX.509標準に正解であり、標準のSSLライブラリに基づく多くのブラウザがこのケースをサポートしています。ただし、この大まかな現実の世界では、TLS 1.2ネゴシエーションで、RSA署名のあるECDSA証明書を拒否するデバイスがいくつか見つかりました。

その理由は、デバイスの作成者がRFC-4492に従っているためだと思います（**は私のものです）

2.2.  ECDHE_ECDSA
In ECDHE_ECDSA, the server's certificate **MUST** contain an ECDSA-
capable public key and **be signed with ECDSA.**

The server sends its ephemeral ECDH public key and a specification of
the corresponding curve in the ServerKeyExchange message.  These
parameters MUST be signed with ECDSA using the private key
corresponding to the public key in the server's Certificate.

rFC-5246、TLS1.2でもこの制限は緩和されました。 （** 私の）：

7.4.4.  Certificate Request
...
If the client provided a "signature_algorithms" extension, then all
certificates provided by the server MUST be signed by a
hash/signature algorithm pair that appears in that extension. **Note
that this implies that a certificate containing a key for one
signature algorithm MAY be signed using a different signature
algorithm (for instance, an RSA key signed with a DSA key).  This is
a departure from TLS 1.1, which required that the algorithms be the
same.**  Note that this also implies that the DH_DSS, DH_RSA,
ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the
algorithm used to sign the certificate.  Fixed DH certificates MAY be
signed with any hash/signature algorithm pair appearing in the
extension.  The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are
historical.

そのため、そのようなデバイスが存在することに注意してください。

5
Chul-Woong Yang

RFC 328 によると、署名アルゴリズムに制約は適用されません。

4.1.2.7サブジェクト公開鍵情報

このフィールドは、公開鍵を伝送し、鍵が使用されるアルゴリズム（RSA、DSA、Diffie-Hellmanなど）を識別するために使用されます。アルゴリズムは、セクション4.1.1.2で指定されたAlgorithmIdentifier構造を使用して識別されます。サポートされているアルゴリズムのオブジェクト識別子と公開鍵素材（公開鍵とパラメーター）をエンコードする方法は、[PKIXALGS]で指定されています。

したがって、 RFC 3279 で指定されたアルゴリズムは、CA、サブジェクト、およびCRL署名に個別に使用できます。

4
Bahribayli

いいえ、私の知る限り、彼らは同じタイプのキーを持っている必要はありません。私の知る限り、CAの公開鍵は、署名している公開鍵のエンティティと同じアルゴリズムを使用する必要はありません。

ただし、かなり簡単にテストできるはずです。一般的なブラウザでのテストを強くお勧めします。

2
D.W.

CA署名アルゴリズムは、証明書の公開鍵アルゴリズムと異なる場合があります。

たとえば、ECDSA公開鍵を含む証明書は、RSA-SHA256を使用してCAが署名できます。

これは、RSA-SHA256を使用してCAによって署名されたgoogle ECDSA証明書の実際の例です。

 $エコー| openssl s_client -connect www.google.com:443 -cipher 'ECDHE-ECDSA-CHACHA20-POLY1305' -tls1_2 2>/dev/null | sed -n '/ BEGIN /、/ END/p' | openssl x509 -text -noout 
証明書：
データ：
バージョン：3（0x2）
シリアル番号：3957570017544888113（0x36ec1cf67d7fdf31）
署名アルゴリズム：sha256WithRSAEncryption 
発行者：C = US、O = Google Inc、CN = Google Internet Authority G2 
 Validity 
 Not before：Apr 17 12:48:49 2018 GMT 
 Not After：Jul 10 12:38:00 2018 GMT 
 Subject：C = US、ST = California、L = Mountain View、O = Google Inc、CN = www.google.com 
件名の公開鍵情報：
公開鍵アルゴリズム：id-ecPublicKey 
公開鍵：（256ビット）
 pub：
 04：7a：36：16 ：34：57：32：b6：b4：b0：53：25：48：14：35：
 bb：74：5b：eb：bb：0c：66：1f：33：ed：80： 59：f5：b5：a8：
 2f：82：ab：6b：e7：9a：41：7e：80：e1：af：7d：6c：59：cc：
 9a： 9b：27：63：93：f3：d6：94：a0：6e：70：17：11 ：a5：f8：
 35：0c：66：71：8a 
 ASN1 OID：prime256v1 
 NIST CURVE：P-256 
 X509v3 extensions：
 X509v3拡張キーの使用法：
 TLS Webサーバー認証
 X509v3キーの使用法：重要
デジタル署名
 X509v3サブジェクトの別名：
 DNS： www.google.com 
 Authority Information Access：
 CA Issuers-URI：http：//pki.google.com/GIAG2.crt 
 OCSP-URI：http：// clients1.google.com/ocsp

 X509v3サブジェクトキー識別子：
 24：E8：32：6E：01：88：23：67：42：C7：FA：F1 ：C1：1F：CA：BA：AC：B8：A9：5B 
 X509v3基本制約：クリティカル
 CA：FALSE 
 X509v3 Authority Key Identifier：
 keyid ：4A：DD：06：16：1B：BC：F6：68：B5：76：F5：81：B6：BB：62：1A：BA：5A：81 ：2F 
 
 X509v3証明書ポリシー：
ポリシー：1.3.6.1.4.1.11129.2.5.1 
ポリシー：2.23.140.1.2.2 
 
 X509v3 CRL配布ポイント：
 
氏名：
 URI：http：//pki.google.com/GIAG2.crl 
 
署名アルゴリズム：sha256WithRSAEncryption 
 8e：c6：4b：84：e7：90：af：91：ae：7b：0d：63：89：b4：29：6a：61：92：
 93：79：c4：b2：b0：db：f6：d8：8b：2e：3c：5b：9b：f7：8c：2f：00：df：
 d1：72：40：ba ：22：0b：51：fa：84：01：9b：db：24：15：b9：9c：99：02：
 82：18：fd：8b：ce：42：ff：17： 3d：55：b9：dc：b4：60：cd：0a：5e：d0：
 69：37：f2：54：38：6a：ab：2a：e8：83：e6：56：cc ：58：bf：b1：ac：65：
 7d：f7：6f：7a：88：87：dc：54：fc：16：2b：e7：8a：7d：88：23：54： 9c：
 3f：e9：6b：e5：b5：71：34：b4：46：0d：19：a2：78：92：b6：c2：8e：4a：
 0f： c8：20：b7：d9：48：df：ed：44：98：df：c1：ed：0c：c2：2c：5e：54：
 e2：12：42：b0：5a：0a ：50：36：62：39 ：81：e2：0a：83：45：ca：25：f5：
 40：85：c4：7d：99：47：3f：fd：df：ce：cd：0b：7d：f5： 56：45：21：db：
 9a：6c：ee：37：0e：cd：c1：33：8d：3f：7a：98：d1：ff：68：61：58：52：
 37：6d：34：79：b0：28：fd：fe：e9：f8：53：75：59：39：77：6f：54：7b：
 3d：97：08 ：3f：b6：55：36：9b：b8：b0：86：01：ac：92：9b：ac：30：eb：
 fe：f2：2e：5d：2a：57：a4： 75：6b：94：a1：4c：b3：2e：3d：25：5c：35：
 65：3d：dd：67 
 $
1
M K Saravanan

楕円曲線暗号スイートに関連するRFC4492によれば、

     Key Exchange Algorithm  Server Certificate Type
      ----------------------  -----------------------

      ECDH_ECDSA              Certificate MUST contain an
                              ECDH-capable public key.  It
                              MUST be signed with ECDSA.

      ECDHE_ECDSA             Certificate MUST contain an
                              ECDSA-capable public key.  It
                              MUST be signed with ECDSA.

      ECDH_RSA                Certificate MUST contain an
                              ECDH-capable public key.  It
                              MUST be signed with RSA.

      ECDHE_RSA               Certificate MUST contain an
                              RSA public key authorized for
                              use in digital signatures.  It
                              MUST be signed with RSA.
1
EL69