はい、その通りです。現在のCMS RFCでは、メッセージダイジェスト属性について次のように述べています。
signerInfoのSignedAttributesには、message-digest属性のインスタンスを1つだけ含める必要があります。同様に、AuthenticatedDataのAuthAttributesには、message-digest属性のインスタンスを1つだけ含める必要があります。
したがって、標準の署名付き属性を使用して複数のメッセージダイジェスト値を提供する唯一の方法は、複数のsignedInfoを提供することです。
もちろん、どのセキュリティシステムも最も弱いリンクと同じくらい強力なので、理論的には、SHA-1も受け入れる場合は、SHA-256でSignedInfoを追加しても何も得られません。前述のように、より強力な署名はいつでも削除できます。
カスタム属性を使用したスキームを破るのは少し難しいですが、攻撃される可能性のあるSHA-1ハッシュがまだ浮かんでいます。署名で覆われているため、属性を削除するほど簡単ではなくなりました。だが：
最終的な署名値の基礎として機能する署名された属性をダイジェストするために使用されるダイジェストアルゴリズムもあります。そこで何を使うつもりですか？SHA-256またはSHA-1？SHA-1の場合、以前と同じ状況になります。
SHA-1の衝突を生成できる場合は、カスタムSHA-256属性を取り除き、署名の最終的なSHA-1ダイジェストが再び加算されるようにSHA-1属性を偽造します。これは、署名ダイジェストアルゴリズムがSHA-256である場合にのみセキュリティが向上することを示していますが、下位互換性を維持したいので、これはオプションではないと思います。
あなたの状況で私が提案するのは、SHA-1をずっと使い続けることですが、RFC3161準拠のタイムスタンプを署名されていない属性として署名に適用することです。これらのタイムスタンプは、実際には独自の署名です。良い点は、そこにあるメッセージのインプリントにSHA-256を使用できることです。多くの場合、タイムスタンプサーバーは、提供したものと同じダイジェストアルゴリズムを使用して署名を適用します。次に、そのようなタイムスタンプを含まないか、SHA-256よりも弱いメッセージインプリント/署名ダイジェストアルゴリズムを使用するタイムスタンプのみを含む署名を拒否します。
このソリューションの利点は何ですか？レガシーアプリケーションは、署名されていないタイムスタンプ属性の存在と、それに強力なダイジェストが使用されているかどうかを確認する必要がありますが、それ以外の場合は無視して、以前と同じ方法で署名を検証し続けます。一方、新しいアプリケーションは署名を検証しますが、タイムスタンプも検証します。タイムスタンプ署名は署名値を「カバー」するため、攻撃者が署名を偽造する方法はなくなりました。シグニチャはダイジェスト値にSHA-1を使用しますが、攻撃者はタイムスタンプのより強力なダイジェストも中断できる必要があります。
タイムスタンプの追加の利点は、作成日を署名に関連付けることができることです。つまり、タイムスタンプの時刻より前に署名が作成されたと安全に主張できます。したがって、署名証明書が取り消された場合でも、タイムスタンプを使用すると、証明書が取り消された時間に基づいて、署名を拒否するか受け入れるかを正確に決定できます。タイムスタンプの後に証明書が取り消された場合、タイムスタンプの時刻より前に取り消された場合は、署名を受け入れることができます（安全マージン（別名「猶予期間」）を追加します。情報が公開されるまでに時間がかかります）。次に、署名を拒否します。
タイムスタンプの最後の利点は、特定のアルゴリズムが弱くなった場合に、時間の経過とともにタイムスタンプを更新できることです。たとえば、最新のアルゴリズムを使用して5〜10年ごとに新しいタイムスタンプを適用し、新しいタイムスタンプですべての古い署名（古いタイムスタンプを含む）をカバーすることができます。このようにして、弱いアルゴリズムは、より新しく、より強力なタイムスタンプ署名によってカバーされます。CMSに基づいており、CMS署名の長期アーカイブを提供するためにこれらの戦略を適用しようとするCAdES （ RFCも存在しますが、現在は古くなっています）をご覧ください。