2

XML 署名仕様(3.2.2「署名の検証」) によると、 KeyInfo要素は署名される場合があります。

「注意、KeyInfo (またはその変換バージョン) は参照要素を介して署名される場合があります。」

ここでは、そのような署名を持つ xml の例を見ることができます。

証明書自体に署名する理由はありますか?

どのようなセキュリティ リスクを排除しますか?

4

1 に答える 1

2

signingCertificateXAdES の属性に関するこの明確なセクションを見てください。ETSI XAdES は XMLDSig の上に構築され、長期にわたって有効な高度な署名の要件を確立します。

signingCertificateds:KeyInfoが存在しない場合、または署名に使用される証明書が含まれていない場合は必須であり、同じ目的を果たします。

7.2.2 SigningCertificate 要素

多くの実際の環境では、ユーザーは異なる CA から、または同じ CA から、異なる名前の同じ公開鍵を含む異なる証明書を取得できます。主な利点は、ユーザーが同じ秘密鍵をさまざまな目的に使用できることです。秘密鍵を複数回使用できることは、秘密鍵を保護するためにスマート カードを使用する場合に有利です。スマート カードのストレージは常に制限されているためです。複数の CA が関係している場合、証明書ごとに異なる ID が含まれる場合があります (たとえば、国民または会社の従業員など)。したがって、秘密鍵がさまざまな目的で使用される場合、署名の生成時に秘密鍵が使用されたコンテキストを明確にするために証明書が必要です。

現在のスキームの多くは、署名されたデータの後に証明書を追加するだけであるため、さまざまな置換攻撃を受けやすくなっています。代理攻撃の例としては、他人の公開鍵を使用して証明書を誰かに発行する「悪い」CA があります。署名者からの証明書が署名に追加されただけで、署名によって保護されていない場合、ある証明書を別の証明書に置き換えることができ、メッセージは他の誰かによって署名されているように見えます。この種の攻撃に対抗するには、証明書の識別子を署名者からのデジタル署名によって保護する必要があります

于 2017-01-10T12:52:08.827 に答える