Является ли использование цифровой подписи для подписи сборки со строгим именем плохой практикой?

Просто разбейте это на чистые части, потому что я не совсем уверен, о чем вы спрашиваете.

Можно ли использовать закрытый ключ цифровой подписи (например, Authenticode) для строгого присвоения имени сборке?

Да, по крайней мере теоретически, поскольку все ключи представляют собой последовательность байтов.

Есть ли в этом смысл?

Поскольку вам не нужно платить за закрытый ключ для строгого именования, использование платной цифровой подписи для этого не имеет особого смысла, нет. Вы платите за доверие, связанное с цифровой подписью. Сильное именование, как объяснили Эрик Липперт, Алексей и другие, не означает доверия.

Будет ли это брешь в безопасности, если вы все равно это сделаете?

Нет. Независимо от того, используете ли вы цифровую подпись или строгое именование, и независимо от того, какой закрытый ключ вы можете использовать для этого, все, что вы выдаете со сборкой, - это открытый ключ. Открытый ключ предназначен для всеобщего сведения - в этом весь смысл асимметричной криптографии. Пока ваш закрытый ключ остается закрытым, в нем нет дыры.

ETA: Я бы хотел увидеть сообщения, упомянутые в вопросе, о строгом именовании с использованием подписи Authenticode (в отличие от их объединения).

Является ли использование цифровой подписи для подписи сборки со строгим именем плохой практикой?

Нет. Это совершенно хорошая практика.

Кажется возможным использовать цифровую подпись для подписи сборки со строгим именем, если вы очень постараетесь.

Это немного сложно, потому что и сильное именование, и цифровая подпись изменяют сборку. Сборка должна быть сначала со строгим именем, а затем подписана.

Я предполагаю, что с помощью этой практики можно обойти цель цифровой подписи, используя ее таким образом, поскольку сборка со строгим именем может быть взломана

Хорошо, значит, вы предполагаете, что есть атака. Я предполагаю, что нет. Укажите уязвимость и предлагаемую атаку.

(по крайней мере, в каком-то посте так сказано).

Вы собираетесь заставить нас угадать, в каком посте это сказано?

«сильные имена сами по себе не предполагают такого уровня доверия, как тот, который обеспечивается, например, цифровой подписью и подтверждающим сертификатом».

Это правильно. Строгие имена и цифровые сертификаты похожи, но решают разные проблемы. Строгие имена решают проблему идентификации сборок. Подписи решают проблему цепочки доверия.

Я видел примеры Интернет-плакатов, которые пытались делать именно это, думая, что они защищают свое программное обеспечение.

Ни строгое именование, ни подпись сертификатов вообще не защищают программное обеспечение! Цель системы безопасности не в защите программного обеспечения, а в защите пользователей. У нас нет водительских прав, чтобы уберечь Департамент транспортных средств от нападений ниндзя. У нас есть водительские права, подтверждающие, что их предъявитель действительно является тем, кем они являются, и имеет право водить машину. Любой, кто думает, что сильное именование используется для защиты программного обеспечения, очень и очень сбит с толку.

Правильно ли я предполагаю, что использование цифровой подписи таким образом на самом деле является плохой практикой, которая может создать брешь в безопасности и определенно бесполезна?

Нет, вы ошибаетесь по всем пунктам.

хорошо это или плохо - переходить ручейки (извините за юмор.)?

Почему это должно быть плохо? Все, что у нас есть, - это ваше заявление о нападении и никаких доказательств того, что оно действительно есть.

Или это вообще возможно?

Конечно, это возможно.

Я видел сообщения со ссылками на их совместное использование (использование цифровой подписи для подписи сборки с конкретным именем (без цифровой подписи)) возможно или лучше, чем ничего не делать?

Вы просите нас прокомментировать достоверность сообщений, которые мы не читали и на которые вы не указали ссылки. Как нам узнать, точны они или нет?

Для ключей, используемых для строгой подписи сборок, не существует цепочки доверия. Вы не можете использовать ключи одного и того же типа для подписи строгого имени и «подписи кода»: поэтому нет проблем с «смешиванием и сопоставлением». Эти два типа сервера подписи имеют разные цели, и вам нужно выбрать те, которые вам нужны в вашем конкретном случае (скорее всего, просто подписание строгого имени и .Net не имеет встроенной проверки для другого).

При подписании строгого имени вы не можете сказать, принадлежит ли конкретный ключ конкретному объекту, в отличие от других типов подписи, когда вы знаете источник сертификата подписи (например, подписывание аутентификационного кода или сертификаты SSL для HTTPS) и можете быть достаточно уверены в его происхождении.

Строгая подпись говорит вам, что сборки, подписанные одним и тем же ключом, созданы одной и той же «сущностью», но нет указания на то, что / кто эта «сущность». Вы не можете сказать «эта новая версия сборки построена компанией FooBar», вы можете только сказать «она построена той же компанией / группой, что и предыдущая».

Примечание. Действительно, существуют некоторые «хорошо известные» открытые ключи (например, сборки Framework, подписанные Microsoft), но вы не можете получить какую-либо сборку и сказать «подписано X», просто взглянув на открытый ключ.

Обратите внимание, что это подробно описано в ответе Эрика Липперта - Подписание сборок .NET.