В. Р. Гинзбург Перевод с английского
жүктеу/скачать 2,74 Mb. Pdf көрінісі
|
практическая криптография
Глава 23. Стандарты ют адаптировать свои реализации, чтобы они могли взаимодействовать друг с другом. Описанный процесс обычно изобилует проблемами. Фракции комитета практически не уделяют внимания разработке хорошего технического стан- дарта. Самое главное для комитета — достичь согласия. Окончательный ва- риант стандарта принимается тогда, когда каждый член комитета не доволен результатом. Чтобы удовлетворить интересы различных фракций, стандарты наделяются массой возможностей, расширенной функциональностью, беспо- лезными вариантами и т.п. А поскольку каждая фракция имеет собственные идеи, собственное мнение и собственный взгляд на проблему, наилучший ком- промисс зачастую оказывается противоречивым. Многие стандарты содержат внутренние нестыковки или даже противоречат сами себе. Ситуацию еще более усложняет то, что компании начинают реализацию своих продуктов прямо в процессе принятия стандарта, основываясь на его черновиках. Как следствие этого, в стандарт очень трудно внести изменения, поскольку кто-то уже реализовал свой проект и не желает начинать все снача- ла. Разумеется, различные компании реализуют проекты разными способами, поэтому на собрании комитета они будут бороться за то, чтобы максимально подогнать стандарт под свою реализацию. Иногда единственным возможным решением является выбор варианта, который не реализовала ни одна компа- ния, — просто для того, чтобы они оказались одинаково не удовлетворены результатом. Технические же качества стандарта никого не волнуют. 23.1.1 Стандарт Один из результатов описанного процесса состоит в том, что стандарты невероятно сложно читать. Документ, описывающий стандарт, разрабатыва- ется договорным путем, поэтому ни у кого нет стимула сделать стандарт понятным, четким, точным или читабельным. В действительности, чем ниже читабельность документа, тем легче с ним работать. Такой документ пой- мут лишь немногие члены комитета, а потому они смогут спокойно прорабо- тать его, не отвлекаясь на препирательства с остальными членами. Вникать в сотни страниц плохо написанной документации — занятие не из приятных, поэтому большинство членов комитета не станут читать весь текст чернови- ка и ограничатся просмотром лишь тех небольших фрагментов стандарта, которые их интересуют. 23.1.2 Функциональность Как уже отмечалось, в процессе принятия стандарта всегда требуется проводить тестирование продуктов разных поставщиков на совместимость. 23.1. Процесс стандартизации 391 Разумеется, каждая компания реализует один и тот же стандарт по-своему. Зачастую реализация немного отклоняется от того, что определено в стан- дарте, а поскольку компания уже продвигает свои продукты на рынке, вно- сить изменения, как правило, слишком поздно. Мы не раз наблюдали, как продукты двух различных компаний настолько отклоняются от стандарта, что становятся несовместимыми, в результате чего разработчики вынужде- ны подгонять один продукт под другой. Довольно часто стандарты включают в себя огромное количество возмож- ностей. В реализациях, однако, применяется лишь ограниченный набор этих возможностей, конечно же, с некоторыми ограничениями и расширениями, так как сам по себе стандарт описывает нечто нежизнеспособное. И разуме- ется, отличие реализации от стандарта нигде не документируется. В большинстве случаев продуктам различных поставщиков удается кое- как взаимодействовать друг с другом, но только в рамках базовой функцио- нальности. Точка доступа беспроводной сети позволит клиенту подключиться к последней, однако управлять этим клиентом в окружении с оборудованием другого поставщика она, скорее всего, не сможет. Простые HTML-страницы будут корректно отображаться во всех обозревателях, однако отображение страниц, содержащих более сложные элементы, в разных обозревателях даст различные результаты. Мы все настолько привыкли к подобным вещам, что практически не обращаем на них внимания. В действительности же такое положение дел можно назвать более чем печальным. Наша индустрия, и мы вместе с ней, не может создать стандарт, который был бы по крайней мере корректным или читабельным, не гово- ря уже об обеспечении совместимости различных продуктов сверх базовой функциональности. 23.1.3 Безопасность Таким образом, обычный процесс разработки стандартов никак не под- ходит для обеспечения безопасности. Здесь мы имеем дело с активным зло- умышленником, который проберется в самые удаленные уголки стандарта. Кроме того, общая безопасность системы определяется ее слабым звеном, а значит, любая отдельно взятая ошибка может оказаться роковой. Мы уже неоднократно подчеркивали, насколько важной является про- стота. Стандарты же обладают чем угодно, только не простотой. Процесс разработки стандарта договорным путем исключает простоту и неизбежно приводит к появлению чего-то настолько сложного, что будут не в состоянии понять сами члены комитета. Уже одного этого вполне достаточно, чтобы стандарт нельзя было считать безопасным. |