angelov () wrote: 1. Бог с ними, с обещаниями Микрософт - каждая домохозяйка с детства знает, что без разрешения Госдепа США" Бог с ними, но, насколько я понял, обсуждается сегодняшнее положение дел (практически снятые ограничения), заявленная стойкость в продуктах MS и реакция на это заявление со стороны ФАПСИ. Соответствие реализации заявлениям и возможные предположения о тайном сотрудничестве MS с Госдепом (NSA, FBI и т.д.) я бы отделил в отдельный тред и не принимал бы в нем участия: для меня самой закрытости исходников достаточно, чтобы я никогда всем этим не пользовался в серьезных целях. 2. Мне лично были бы понятны опасения ФАПСИ в отношении сильного крипто, если бы слабое крипто уже было бы прозрачно для этой организации. Неужели там уже свободно "крякают" DES-56? И прочих слабаков? Здесь вопрос о степени свободы. Читать трафик, закрытый даже 40-битным шифрованием, в массовом порядке значительно сложнее, чем открытый. Сложнее и для ФАПСИ, и для более богатых их западных коллег. В то же время, на мой взгляд, очевидно, что отдельное сообщение прочитать несложно. Дальше можно только предполагать. 2.1 Возможно, в ФАПСИ хотели бы, чтобы оставалась возможность прочитать любое отдельное сообщение (фрагмент трафика). 2.2. Возможно (более интересный вариант) - чтобы оставалась возможность продемонстрировать нестойкость того или иного решения, или просто сослаться на уже продемонстрированную нестойкость, чтобы навязать пользователю свою продукцию/услуги в ситуации, когда пользователь защищает "чужие" данные. Может быть" Это все - предположения. 3. Из моего абзаца выдернуто не то что предложение, а два словосочетания - "сильный крипто" и "слабый крипто", и поехали обьяснять, что для поимения сильного нужно устанавливать сильный Service Pack. "Волга впадает в Каспийское море", "Лошади любят овес" Т.е. суть абзаца была лишь в том, что SSL/TLS/SMIME "не страшные", а PPTP/L2TP "страшные", потому что" Но я не понимаю, почему. И SSL, и L2TP защищают топологию (в частности) "точка-точка", просто в разных слоях сетевой модели. Помимо всего прочего, технология VPN по PPTP была и в более ранних продуктах MS (W98, NT4), и я не вижу здесь никакого радикального отличия W2K. Что касается предотвращения DoS-атак посредством VPN, то, во-первых, я не понимаю, какое это имеет отношение к разборкам между MS и ФАПСИ. ФАПСИ у нас, что, патентованный организатор DoS-атак? Или крутой поставщик antiDoS средств? До сих пор все отношение ФАПСИ и работающих под ее крышей производителей к DoS-атакам было таким: не используйте IP-сети (столь же правильно, сколь и бесполезно). 4. Попробую пояснить свой последний абзац моей реплики. Другое дело было бы, если бы да кабы было бы правило - при продаже билета в Турунтаево требовать оформленный с применением крипто пропуск, и при отсутствии оного - никаких продаж билетов и тем более полетов, И точка проверки пропусков перемещается в кассы продажи билетов, они и становятся мишенью для атаки. А если даже не становятся, сама необходимость распределенной (касс-то много) проверки пропусков сожрет больше ресурсов, чем любая атака ;) Точно так же, в любой VPN-сети поверх IP шлюз является первой уязвимой точкой для DoS-атак. 5. Что это за " масса различных технологий и приложений", которую, по-Вашему, содержит Win 2000? E=mc*2??? Помимо упомянутых SSL/TLS/SMIME и L2TP, это (в штатной поставке) как минимум NTFS EFS, шифрование паролей" В общем, берем полную установку W2K, отрисовываем дерево вызовов, и видим, сколько программ завязано на модули CAPI. Много. Еще интереснее, что обращения к CAPI содержат ряд приложений-отдельных продуктов от MS. Например, Office2000 в варианте SR1, использует хэш и подпись для проверки "кода авторизации", полученного после регистрации. Ну и т.д. Спасибо.
Комментарии (9)
-
ФАПСИ не будет препятствовать началу продаж Windows 2000
========================================================= Здравствуйте, Максим ! У Вас начало реплик прямо как на митинге: "angelov пишет", "angelov wrote". Остается ожидать "angelov будет писать"...
В общем - "контора пишет...": По существу дела. Мне и в голову не приходило, но теперь то я вижу, что Вы, батенька, даже и держали в руках очень хорошую книгу: "Windows 2000 Server Deployment Planning Guide" Для примера - вот что "там", у Микрософт, есть из "массы различных технологий и приложений" (цитирую из книги): Chapter 17 "Determining Windows 2000 Network Security Strategies".
........
Preparing for Windows 2000 Network Security Technologies. In some cases, Windows 2000 network security technologies are dependent on other Windows 2000 security technologies. For example, the virtual private networking Layer Two Tunneling Protocol (L2TP) uses IPSec to provide security from the remote client to the VPN server. The IPSec security negotiation requires certificates to authorize the connection. Therefore, a certification server is required with the appropriate configuration. Typically, a Windows 2000 certificate server is joined to a domain. The domain specifies Group Policy with public key infrastructure (PKI) settings for computers to auto-enroll in this certificate authority to get a computer certificate for IPSec. L2TP creates the necessary IPSec policy to ensure the L2TP traffic is secure. However, administrators might want to also secure other traffic between all servers and lients. This requires the configuration of IPSec on each client and server. Because IPSec is configured using a policy, after you create the policy in Active Directory", you can apply it to all computers on a group or domain basis. You can deploy certificates and IPSec policy to all domain computers by centralized administration using Group Policy in Active Directory. For more information about planning for the deployment of Windows 2000 certificates, see "Planning Your Public Key Infrastructure" in this book. For more information about Active Directory planning, see "Designing the Active Directory Structure" in this book.
............ Deploying VPNs. If you are planning to deploy VPNs, there are various issues you need to consider, such as: -Which security protocol to use - Point-to-Point Tunneling
Protocol (PPTP) or Layer Two Tunneling Protocol (L2TP). -Whether to use IPSec (if L2TP is selected). -What certificates to use when connecting with L2TP/IPSec. -Where to locate the VPN server - in front of your firewall,
behind it, or beside it. -How to use Connection Manager to give users predefined
settings. -How to use VPNs as part of your remote access policy.
...........
Конец цитирования. Книгу эту, в тыщу страниц, можно поиметь уж как с месяц и бесплатно на:
http://www.microsoft.com/technet/win2000/dguide/home.asp Чем она хороша - обыкновенно у Микрософт слишком большая разница, по точности и актуальности, между "книжной" документацией и Help'ом. Здесь - приятное исключение, и через Windows 2000 Server Help можно получить сведения об употребляемых технологиях не прибегая к трассировке вызовов модулей и манипуляциям "Start Service"\"End Service". Да и отрисовка дерева вызовов чаще всего дает единственный результат: "много". Просто - масса модулей!!! И практически ничего - про технологии... И тогда чаще всего вспоминают, что - "когда ничего не помогает, приходится читать документацию..." До свиданий, Максим. C уважением отваги и бесстрашия,
Виктор Ангелов.
-
ФАПСИ не будет препятствовать началу продаж Windows 2000
angelov() wrote: По существу дела. Мне и в голову не приходило, но теперь то я вижу, что Вы, батенька, даже и держали в руках очень хорошую книгу: "Windows 2000 Server Deployment Planning Guide". Не держал. Мне ее не удосужились прислать, да и непонятно, зачем бы мне ее читать: это же "Руководство по планированию разворачивания"" Я не собираюсь нигде разворачивать W2K Server. Я вообще не специалист по Windows-технологиям, на то у меня (как консультанта) есть свои консультанты. 17-ю главу, впрочем, не то, чтоб "читал", но просмотрел внимательно в свое время, не в связи с интересом к Windows, а в связи с интересом к "защите" и тому, как ее понимает один из производителей софта (точнее, как "впаривает"). Для примера - вот что "там", у Микрософт, есть из "массы различных технологий и приложений" (цитирую из книги): Моя реплика относилась к тому, что на MSCAPI основано много чего, причем отнюдь не только "технологии", которые относятся к сетевым службам. Та же EFS работает локально и использует CAPI. Ну и к чему была эта длинная цитата про сетевые "технологии"? Что, MS будет мне рассказывать на своем идиолекте о том, что такое IPSec или L2TP? У меня, вроде как, спецификации есть" Книгу эту, в тыщу страниц, можно поиметь уж как с месяц и бесплатно на:
http://www.microsoft.com/technet/win2000/dguide/home.asp Я думаю, это - полезная ссылка для всех, кому это надо профессионально или в связи с собственными интересами. Чем она хороша - обыкновенно у Микрософт слишком большая разница, по точности и актуальности, между "книжной" документацией и Help"ом. Чем она плоха - так это обычным для MS "склеиванием" маркетингового и технологического дискурсов. У "специалистов по технологиям Windows", вскормленных на MS-овских доках и книжках аффилиированных авторов, обычно жуткая каша в голове. Причем - даже у настоящих Специалистов, которые знают Windows от и до. Книгу я не читал, но мнение имею; собственно, процитированного отрывка достаточно, чтобы таковое составить. Здесь - приятное исключение, и через Windows 2000 Server Help можно получить сведения об употребляемых технологиях. "Технология" здесь - ничего не значащее слово, поскольку вопрос именно в том, какой модуль к какому обращается. Не факт, что отдокументировано все и отдокументировано корректно. Если - да, то MS можно только поздравить с движением в правильном направлении. Раньше они точностью в таких вопросах не отличались. А в вопросах, цепляющих не только технологические, но и "политические" моменты, предпочитают темнить и сейчас (см. недавнее интервью Дергуновой нам ("Компьютерре", http://www.computerra.ru). Да и отрисовка дерева вызовов чаще всего дает единственный результат: "много". Это смотря кто и чем отрисовывает. Просто - масса модулей!!! И практически ничего - про технологии... Конечно. Поскольку "технология" в устах MS - маркетинговое слово, типа "русского артикля" "@#$". "У нас там технологии, @#$ !". Есть распространенный язык для обсуждения криптографии и ее применений: протоколы и примитивы (алгоритмы). По отношению к примитивам всегда можно задать вопрос: какие примитивы используются в реализации того или иного протокола тем или иным производителем в том или ином продукте. Собственно, все вопросы к Ms про "запрещенные алгоритмы" сводились к вопросам о конкретных примитивах, собранных в конкретные библиотеки. Ответы шли на уровне трепа о "технологиях".
-
ФАПСИ не будет препятствовать началу продаж Windows 2000
===================================================== Здравствуйте, Максим !!! Спорщик Вы еще тот - то утверждаете, что у Микрософт нет двух групп технологий про кои я сдуру заикнулся, а есть - "там есть масса различных технологий и приложений". То есть сами утверждаете, что технологии то вообще-то есть, но они различные. Теперь у Вас - "там" технологии вообще нет, в хорошем смысле этого слова, а для обсуждения криптографии и ее применения достаточно оперировать протоколами и алгоритмами. Согласен с первой частью - для обсуждения криптографии достаточно языка протоколов и алгоритмов, например: - hash алгоритмы MD-5, SHA-1
- cripto алгоритмы DES-56, 3DES-168, IDEA-128, Fortezza,... - протоколы SSL Record,SSL Handshake, SSL Change Cipher Spec, SSl Alert, ... А вот для обсуждения применения криптографии языка алгоритмов и протоколов уже недостаточно, ибо алгоритмы и протоколы - это продукты прикладной математики и кибернетики, а вопросы применения результатов прикладных наук всегда относились к технологии, ибо см. Oxford Dictionary: "technology - knowledge or use of the mechanical arts and applied sciences", лучше и не скажешь, прямо-таки "Hard+Soft", то есть технология - не такое уж и ругательное слово, и относительно вышеперечисленных протоколов и алгоритмов мы можем иметь следующее и вполне удобное: применяем их на LAN - имеем SSL технологию, а применяем их через Интернет - имеем TSL, Transport Layer Security, технологию. А то что это слово "затаскали" в различного рода тусовках и административных "трепах" - ну дык это не удивительно, придите с конкретным вопросом хоть в ЖЭК, хоть в Микрософт, и если на него не хотят или не могут ответить конкретно, то и будут отвечать, вроде бы и по делу (Oh, yes,sec technologies - в MS; да, наша технология генерации пара- лучшая в районе, это в ЖЭКе), а по существу - треп...Да что в Микрософт ходить, вы почитайте проектные документы по СОРМ-2, ведь треп пошибчее будет, не технологического, а протокольного уровня... Что касается настоящих Специалистов по MS Windows, то их нужно определять следующим образом. Пусть кандидаты в настоящие Спецы сдают сертификационные экзамены на MCSE. Потом выбираем тех из них, кто провалил экзамены. Из проваливших экзамены выбираем тех, кто не смог или неправильно (по мнению MS) ответил на вопросы типа: Q32. How many IP addresses can be bound to a single NIC in Windows NT Server? a. five
b. four
c. three
d. two
e. one Q33. Which of the following can resolve the nament.course.com to an IP address, a. DNS server
b. WINS server
c. DHCP server
d. all of the above
e. only a and b Q34. Which of the following steps are required if you want to configure Microsoft Mail for remote access: a. Install Hyper Terminal
b. Install Dial-Up Networking?
c. Install Microsoft Remote Mail?
d. Configure the server on which the postoffice resides После этого смотрим на конкретные ответы провалившихся кандидатов в Спецы и...некоторым присваиваем звание MS Engineer-Спеца. Пора закругляться... Так как же все-таки насчет "технологий"? Ну в хорошем смысле этого слова? Я тут нашел бумагу от MS, хорошую бумагу, всего в 10 страниц, но с более-менее толковым изложением позиций Микрософт по VPN технологиям:
http://www.microsoft.com/technet/win2000/win2ksrv/technote/msppna.asp C уважением к несдающимся,
Виктор Ангелов.
-
ФАПСИ не будет препятствовать началу продаж Windows 2000
Здравствуйте! Что-то увяла наша дискуссия о технологиях в криптографии, эдак многие и вправду могут подумать, что для обсуждения вопросов криптографии вполне достаточно оперировать алгоритмами и протоколами. Попробую еще раз показать, что это - далеко не так. Начну с того, что на сегодняшний день существуют 2 подхода к криптованию данных: a. symmetric or secret-key (private-key) cryptography
b. asymmetric or public-key cryptography a. Симметричная криптография - это технология, в которой для криптования и декриптования (encryption and decryption) используется один и тот же ключ (a secret key\private key). В этой технологии используются стандарты и алгоритмы: Data Encryption Standard (DES)
Triple-DES (3DES)
International Data Encryption Algorithm (IDEA)
Password Usage Сами по себе стандарты и используемые в них алгоритмы весьма хороши, c точки зрения простоты использования и, особенно DES, в скорости работы при реализации алгоритмов ввиде наборов чипов (hardware, в программной реализации IDEA более "проворен" чем DES). То, что DES 1976-ого "года рождения" с его 56-тью битами ключа буржуи научились "крякать" еще два года назад (1998, а КГБ CCCР - возможно и еще раньше - кто знает?), это недостаток, конечно, но главные недостатки всех 4-х вышеперечисленных алгоритмов и стандартов - технологического плана: 1.Единственный ключ, используемый и Отправителем, и Получателем, надо как-то надежно передать через Интернет (key distribution problem);
2.Если кто-то "спер" этот ключ, используемый, скажем, мной и моим другом, то этот "кто-то" может спокойно выступать в переписке от моего имени и мой друг не заподозрит подмены, он ведь уверен, что ключ знают только он и я, и если мой друг успешно декриптовал сообщение, то вроде бы только я один мог его послать (source authentication problem);
3.Этот "кто-то" может перехватить мое платежное поручение банку и поставить свои реквизиты на получение денежных средств (message integrity problem) Приведенных 3-х недостатков вполне достаточно, так думается, чтобы понять - да, в протоколах могут использоваться соответствующие стандарты и алгоритмы, и можно обсуждать их достоинства и недостатки как таковых, но совершенно непрактично в криптографии обходить стороной вопросы применяемых технологий, а посему: b. asymmetric or public-key cryptography - это технология, впервые обнародованная by Diffie and Hellman, и в которой для криптования и декриптования используются разные ключи, конкретно - пара ключей, public key and the private key, и каждый из них может как криптовать, так и декриптовать исходный материал, называемый в криптографии plaintext. Далее, троица из MIT (Rivest, Shamir and Adelman) в 1977-м, через год после рождения DES, изобрела крипто алгоритм (RSA public key algorithm) и технологию его применения (RSA public key cryptography), коротко - RSA, то, что сейчас является стандартом де-факто в Интернете - RSA Internet encryption and authentication technology. Идея MIT'овской троицы, RSA, заключалась в замене единственного DES ключа на пару ключей - public key and a private key. Каждый, и отправитель, и получатель, имеют свою собственную пару (public-private key pair), и свободно дают, кому не лень, свой public key, оберегая в секрете свой private key. В принципе, по технологии обнародованной by Diffie and Hellman, сообщение может быть криптовано любым, public или private, ключом из пары, и декриптовано соотвествующим противоположным ключом из пары.
RSA несколько ограничили сие вольнодумство/вольтерианство - сообщение следует криптовать с использованием public key получателя и тогда оно может быть декриптовано только с использованием private key получателя. Это - то, что называют RSA encryption. RSA криптование позволяет решить первую и третью из проблем безопасности, упомянутых выше (key distribution problem + message integrity problem). Оставшуюся source authentication problem RSA предложили решать следующим образом: сообщение криптуется (is encrypted, locked) с использованием private key отправителя и декриптуется (is decrypted, unlocked) с использованием public key того же отправителя. Это - то, что называют RSA signing. Получается следующая картина - если заменяем DES encryption на RSA signing (а это есть фактически RSA криптоалгоритм + технология применения ключей отправителя), то любой, кто успешно декриптовал мое сообщение, может быть уверен, что оно притопало именно от меня. Далее, я могу использовать RSA encryption (RSA криптоалгоритм + технология использования ключей получателя) для криптования этого же, уже помеченного (RSA-signed) сообщения с использоваием public key получателя, дабы еще и самому быть 100% уверенным, что только желаемый мною получатель сможет прочесть мое сообщение. Все это хорошо, но встает еще одна проблема, и опять же - технологического плана. Дело в том, что RSA алгоритм работает много медленне DES, и это еще при том, что я должен сделать 2 медленные криптографические операции при передаче каждого сообщения - RSA encryption и, отдельно, RSA signing. А сообщение то может быть и большим, скажем, длиной чуть меньше 2^64 бит... И используемые компьютеры - не у всех суперкомпы... Что придумали для решения этой проблемы:
При отправке сообщения, для его криптования использовать временный, свежесгенерированный DES ключ, и использовать его только для передачи этого сообщения. Для другого сообщения - генерируем новый DES ключ, поэтому ключи такого типа называют DES session key. Из самого сообщения делать своего рода "выжимку", "экстракт" сообщения такого свойства - если человек есть аналог сообщения, то "экстракт" (the hash) есть аналог узора на пальцах в смысле уникальности. Имеющиеся hash-алгоритмы (SHA-1, MD-5) позволяют путем спецвычислений делать маленький, скажем 160 бит, "отпечаток пальцев" с большого сообщения, и если отправитель этого сообщения "заверит" (RSA signing) эти 160 бит и отправит их получателю, то будем иметь то, что называют digital signature, или еще можно встретить название - a keyed hash. Приведенных сведений вполне достаточно, чтобы описать технологию применения RSA в случае, например, когда я посылаю сообщение своему другану: Что должен сделать я: 1.сгенерировать DES session key
2.закриптовать мое сообщение, используя этот DES ключ
3.закриптовать этот же ключ, используя RSA encryption, то есть используя public key получателя
4.вычислить hash сообщения
5.подписать (digital signature) полученный hash, используя RSA signing, то есть используя мой private key
6.отправить получателю: DES-криптованное сообщение, раз; RSA-криптованный DES ключ, это два; RSA signed hash, это три. Что должен сделать друг-получатель: 1.Декриптовать полученный и криптованный DES ключ, используя свой private key
2.Декриптовать полученное сообщение, используя этот DES ключ
3.Сделать hash декриптованного сообщения и запомнить его
4.Декриптовать переданный мной hash, используя МОЙ PUBLIC KEY
5.Сравнить запомненный hash c полученным
6.В случае совпадения полученного hash с вычисленным на месте - все в порядке, мин нет!!! Подобные процессы выполняются на любом компе, использующем security options of MS Internet Explorer or Netscape Communicator/Navigator, или на компе, использующем PGP (Pretty Good Privacy) технологию (за разницей - в PGP вместо DES используется 128 битовый IDEA и для частного употребления RSA 512-2048 bits вроде бы не требуется патента), только в качестве друга-получателя будут выступать Web-server или E-mail программа, и за одним существенным дополнением - поскольку в процессе участвуют двое и может обьявиться своего рода самозванец, третий, утверждающий, скажем, что он - это я, то все public keys, участвующие в процессах, принято заверять, сертифицировать (RSA signing), третьей стороной, которой вынуждены доверять все участники обмена. Эта третья сторона называется CA - Certificate Authority (VeriSign, AT&T, US Postal Service, Microsoft, Netscape, ...), и суть ее работы сводится к сертификации (персональных деталей (identity) личности или организации + public key этой identity). При этом используется private key, принадлежащий CA, а сам сертификат называют Digital Certificate. Поэтому и число разновидностей Digital Certificates соответсвует числу типов владельцев public keys: Personal (Client), Server (Site), E-mail and finally CA сертификаты. Легко сделать summary: Public Keys употребляются для криптования посылаемого сообщения, для верификации Digital Signature и authentication отправителя; Private Keys - для декриптования криптованного сообщения и для посылки Digital Signature. Что-то вроде Заключения: Техническую реализацию вышеупомянутых технологий или элементов можно найти практически во всех протоколах (IPSec, L2TP, PPTP), используемых в VPN технологиях MS Windows 2000 для обеспечения безопасности сетевых коммуникаций. Более того, в Windows 2000 предусмотрена возможность "шлепать" собственные сертификаты для клиентов of сервисов этой операционной системы, достаточно только получить "корневой" сертификат от какого-нибудь уважаемого CA - Certificate Authority, и уж потом выступать как CA для своих клиентов.
Я это все к тому, что по крайней мере странно читать заявления некоторых спецов, что выкорчевать серьезную криптографию из Windows 2000 не представляет большого труда, и, что более странно, эти спецы не предлагают свои услуги. Также - удивляет, скажем, простодушное отношение к технологиям вообще и к технологиям Microsoft в частности со стороны моего оппонента по дискуссии. Мой оппонент хотел бы получить от Микрософт списки вызываемых модулей и списки библиотек. И ключ от квартиры, где деньги лежат... Я так думаю, в Микрософт бешено хохотали, получив такой запрос (Oh, those Russians!!!). Я надеюсь, что сие робкое роптание не послужит причиной "вырезания" уважаемым Редактором Либертариума моей реплики из дискуссии, я ведь все таки не "поднялся" до выяснений, у кого "в голове каша"... До свиданий.
Виктор Ангелов. Где можно найти подробности: очень путние словари: http://www.freeswan.org/freeswan_trees/freeswan-1.2/doc/glossary.html
http://www.netarrant.com/comm/support/glossary.htm все, или, как утверждают авторы, почти все о PGP:
http://www.stack.nl/~galactus/remailers/index-pgp.html
http://www.eskimo.com/~joelm/pihelp.html RSA:
http://www.alumni.caltech.edu/~yang/jy_crypto.html Web security:
http://www.microsoft.com/technet/security/web.asp
http://www.securityportal.com/research/www-auth/ Как "крякали" DES:
http://www.eff.org/descracker.html Certificate Overview:
http://www.collegeboard.org/aes/sss/html/docs/overview.htm NetScape Admin Guide:
http://developer.netscape.com/docs/manuals/cms/41/adm_gide/kycrt_in.htm
-
ФАПСИ не будет препятствовать началу продаж Windows 2000
...
Более того, в Windows 2000 предусмотрена возможность "шлепать" собственные сертификаты для клиентов of сервисов этой операционной системы, достаточно только получить "корневой" сертификат от какого-нибудь уважаемого CA - Certificate Authority, и уж потом выступать как CA для своих клиентов
...
А зачем подписывать ключ у уважаемого СA? Это возможный вариант, но не обязательный, тем более что в последнее время я как-то не нахожу у уважаемых СA такую услугу. Единая иерархия CA эта какая-то древняя идея в духе CCITT. Причем идея, imho, очень вредная. А учитывая последнюю моду на кросс-сертификацию возможно через пару лет, вообще останется только один CA, он же самый уважаемый СА--
xtens
-
ФАПСИ не будет препятствовать началу продаж Windows 2000
============================================== Приветствую Вас категорически -один CA останется тогда, когда наступит мировой коммунизм, то есть когда вымрут нотариальные и адвокатские конторы, ибо пока что CAs выполняют в E-commerce вполне аналогичные функции этих контор. "Это возможный вариант,но не обязательный, тем более что в последнее время я как-то не нахожу у уважаемых СA такую услугу." О каком продукте конкретно идет речь? ("не обязательный" вариант - для каких конкретно Сертификационных Серверов?) А "как-то" найти такую услугу у CA - очень просто, особенно если Вы имеете дело с Netscape Certificate Server или MS IIS (в моей реплике, напомню, речь шла о MS): http://www.microsoft.com/TechNet/iis/train9.asp
http://developer.netscape.com/docs/manuals/cms/41/adm_gide/kycrt_in.htm Если не нравятся эти продукты, можно использовать давно проверенный:
http://www.zdnet.com/pcweek/reviews/0414/14xcert.html "Единая иерархия CA" - я не знаю, признаться, что это такое,что это за идея, imho. Много на белом свете идей... Если растолкуете - буду очень признателен,только, пожалуйста, с разьяснением сути и - в чем эта идея "очень вредная" (например, вредная для здоровья или для обсуждения под водку?). Я знаю про употребление "деревянной" структуры CAs при наличии в корне (root) такого CA, который "знает" все кратчайшие пути для кросс-сертификации, дабы не гонять понапрасну по всем инстанциям Клиентов с их сертификатам, полученным у разных CAs. А вообще-то эта "последняя мода", кросс-сертификация, уже лет 5 как последняя... Виктор Ангелов.
-
ФАПСИ не будет препятствовать началу продаж Windows 2000
Здравствуйте, Виктор.
один CA останется тогда, когда наступит мировой коммунизм, то есть когда вымрут нотариальные и адвокатские конторы, ибо пока что CAs выполняют в E-commerce вполне аналогичные функции этих контор
Не совсем так. Я как-то писал в этом форуме, что digital certificate любителю пива должен выдавать клуб любителей пива, девушке на выдане -- брачное агентство и т.д., однако на практике есть Verisign, Thawte и еще пара десятков существенно более мелких CAs, которые явно тяготеют если не к объединению, то к координации [скудного] набора предлагаемых услуг. Фантазии этих CAs хватает на связывание открытого ключа и dns имени сервера или e-mail владельца сертификата. Согласитесь, если бы мы использовали сертификаты в дискуссии на этом форуме, Вам было бы куда интереснее увидеть сертификат изданный каким-либо учебным заведением, подтверждающий профессиональный уровень оппонента, чем верисайновскую гарантию того, что адрес электронной почты собеседника, действительно user@home.
Спектр нотариальных услуг Verisign ограничивается проверкой регистрации организации. Для Y2K такой сервис выглядит как-то убого. И, кстати, про e-commerce. Вернее про то о чем в e-commerce постояннно забывают, по крайней мере в России. Непосредственно о предоставлении "электронных" услуг (всех кто занимается и-коммерцией, почему-то интересуют электронные платежи, т.е. не то как можно предоставлять услуги через Internet, а как получать за это деньги). Я уже где-то здесь писал, что сертификаты, куда интереснее использовать именно при предоставлении услуг через инет. Е-mail от доктора с диагнозом заболевания, приобретет вес, если он подписан цифровой подписью, а ключ, заверен сертификатом какой-либо медицинской ассоциации, и если врач схалтурил, то он будет отвечать за свое письмо, а ассоциация за то что выдала ему сертификат, ну и т.д. Одним словом сертификаторам пока есть куда расти, никакие они не нотариусы и тем более не адвокатские конторы. После приобретения Verisign-ом Network Solutions этот уважаемый CAs можно с полным правом обзывать доменным регистратором, которым видимо он всю жизнь и хотел стать. Про услуги: я хочу подписать сертификат своего CA у Verisign и не нахожу как это сделать, поэтому использую в MS Certificate Sеrvices самоподписанный сертификат для заверения всяких других сертификатов (это же можно было делать и в MS Certificate Sеrver, который поставлялся с NT Option Pack). Впрочем, этот продукт не опрадывает мои ожидания, и на сегодня старый добрый ssleay (openssl) справляется с задачами CA куда лучше, imho. Про иерархию CA: я говорю о том что дерево CAs нарисованное в X.509 в 1988 году, действительно может вырасти, причем в мире будет только одно дерево с корнем в уже упомянутом verisign. Чем это плохо? Да тем, что когда у root-а этого дерева поедет крыша и он, например, решит что в сертификате должен быть обязательный атрибут ICQ UIN всем придется с этим считаться и ставить себе аську. (в этой связи, про скандалы с распределением доменных имен лучше и не вспоминать). Кстати, в младших версиях Internet Explorer и Netscape Navigator нельзя было добавлять сертификаты CAs. Был фиксированный список сертификатов "прошитый" заводом-изготовителем, а сертификаты других authority вызывали у броузеров поток гневных предупреждений. --
xtens
-
ФАПСИ не будет препятствовать началу продаж Windows 2000
================================================= Здравствуйте, Максим!!! Спасибо за подробный ответ. Видимо, я уж слишком в буквальном смысле истолковал Вашу фразу о "Единой иерархии СА", конкретно - слово "единой" я отождествил с "единственной для всех"... В принципе, я согласен с Вашими доводами относительно бедного набора нотариально-адвокатских функций CAs. Однако, в примере с любителем пива - почему "digital certificate
любителю пива должен выдавать клуб любителей пива"? Именно - почему ДОЛЖЕН то? Почему я, как любитель пива, не могу выбрать в качестве СА ту контору, которую считаю нужным или просто она мне нравится ? Например, брачное агенство. Да и вообще я считаю, что пиво надо "сертифицировать" водочкой, а не бумажно\цифровым сертификатом, в том смысле, что любительство пива - это процесс, вся приятность которого заключается в возможности повторения его и завтра, и послезавтра, а сертификат любителя пива - это нечто, фиксирующее заслуги, а какие могут быть у меня заслуги перед моими со-кружниками, со-бутыльниками, если завтра-послезавтра мы соберемся опять и начнем с нуля? А засертифицировать мои анкетные данные (DN of subject, X.509) и Public Key Info я могу и обыкновенным способом... Пардон за задержку с ответом. Have a good weekend!!!
Victor.
-
Эволюция института CA
Давайте разберемся, что такое сертификаты и как их использовать. В самом общем виде получение вами некой заверенной сертификатом информации означает: "<Лицо, знающее секретную информацию А> подтверждает истинность некоего <Утверждения>, сделанного <Лицом, знающим секретную информацию Б>". В качестве <Утверждения> может фигурировать: "<Лицо, знающее секретную информацию Б>, является Васей Пупкиным, паспорт.... выдан..."
"<Лицо, знающее секретную информацию Б>, является гомеопатом с 25-летним стажем" и т.п. Такая структура, если ее желательно использовать для связи с реальным миром (деньги, медицина) предполагает наличие связки на каком-то уровне. В вершине дерева должно стоять типа: "<Лицо, которому можно доверять> подтверждает истинность некоего <Утверждения>, сделанного <Лицом, знающим секретную информацию Б>". При этом природа доверия к <Лицу, которому можно доверять> принципиально должна носить нецифровой (или не тольео цифровой) характер. Начиная от этого утверждения, можно строить цепочки сертфикатов для разных лиц, с учетом особенностей различных Утверждений. В настоящее время роль этих первых утверждений играет факт наличия сертификатов от ряда СА, встроенных в фирменный браузер. Расширение круга этих утверждений делается при получении вами сертификата, которому вы доверяете в силу некой дополнительной информации. Таким образом, эволюция СА может пойти уймой путей. Например, один обязательный официальный СА на страну (юрисдикцию) для выдачи паспортов физ.лицам. И от этого вы не уйдете, пока не изменится природа суверенного права.
|
