Поскольку мы - крупная фирма и у нас все как у взрослых - то решили двигаться к идеалу. Для УЦ решили сделать каталог выпущенных сертификатов, наподобие того, что есть для PGP. Естественно, путь сей усеян граблями разной длины и жесткости. Среди прочих:
- DN для УЦ CryptoPro жестко фиксирован и имеет email в конце - ну что делать, стали использовать что есть. Никакой древовидности создать из этого нельзя, конечно.
- Для безопасности к нашему УЦ обращаются только люди, комьпьютеры изолированы сетевым способом - поэтому и экспорт запускается с помощью функций УЦ КриптоПро и с помощью нашей софтины(кому надо - обращайтесь), которая экспортит в LDAP. То, что было написано у КриптоПро - работает с AD, а не с произвольным LDAP-каталогом.
- Оказалось, что поиск в LDAP работает на ура - пока дело касается классов и атрибутов. А вот поиск частей атрибутов - уже сложнее. Хотя бы тем, что кодировка в сертификате не может быть изменена LDAP-сервером, а стало быть и поиск по ней неясно как выполнять. Далее выяснилось, что согласно rfc - серийный номер - Integer, но при этом 20 октетов содержит. То есть 2^60. Ну поскольку все кругом 32b - поиск и работа с такими серийниками затруднены. Даже в части ExactMatching не очень ясно как это делать.
- Также, поскольку сертификат содержит персональную информацию типа email, выставление базы сертификатов всем грозит спамом и атакой на почту. (заметка от ИБ). Стало быть, надо дать доступ на RO только держателям этих самых сертификатов. Ботаем LDAP на SSL, понимаем, что он берет закрытый ключ из pem файла. А CryptoPro Хранит все в спец хранилищах и как оттуда доставать приватный ключ для OpenLdap - мало понятно.
- Естественно вопросы производительности, а еще если учитывать что Web приложение потребуется в любом случае (на основе DSML) - то конечно и это тюнить надо.
соотв. что получилось
Посмотрим, что из этого всего выйдет.
Избитая тема, но сегодня удалось выполнить эту процедуру самому по работающим инструкциям.
В духе бестолковых журналистов, поделюсь найденным (не мною) - если обратиться к регламентам рынка электроэнергетики России (например), то можно обнаружить, что области действия сертификатов начинаются на 1.3.6.1.4.1. В данном OID среди прочих есть 1.3.6 - US Department of Defense (Мин. обороны США).
Из этого можно было бы состряпать приличную историю о демонтаже энергетики из США, но причина здесь другая. OID, соответствующий России, был получен Thu Dec 18 18:17:52 CET 2003. Причем, зарегистрировала его вполне себе частная организация - Центральный Телеграф. А рынок и соответствующий УЦ были запущены в работу уже в 2002 году.
В один момент понадобилось получать таблицу из часов для передачи во вложенные вызовы. Понятно, что select ‘0′ from dual union all … select 23 from dual - не годился. У нас есть переходы на летнее время и хотелось бы их учитывать. ФОРС по моему вопросу признался что это не легко и они написали процедуру специально для такого случая.
А вот как это можно делать селектом. (дата которая подставляется снаружи - через bindParameter в jdbc
SELECT '0' as hour from dual union all
SELECT '1' as hour from dual union all
SELECT '2' as hour from dual union all
SELECT '3' as hour from dual union all
SELECT '4' as hour from dual union all
SELECT '5' as hour from dual union all
SELECT '6' as hour from dual union all
SELECT '7' as hour from dual union all
SELECT '8' as hour from dual union all
SELECT '9' as hour from dual union all
SELECT '10' as hour from dual union all
SELECT '11' as hour from dual union all
SELECT '12' as hour from dual union all
SELECT '13' as hour from dual union all
SELECT '14' as hour from dual union all
SELECT '15' as hour from dual union all
SELECT '16' as hour from dual union all
SELECT '17' as hour from dual union all
SELECT '18' as hour from dual union all
SELECT '19' as hour from dual union all
SELECT '20' as hour from dual union all
SELECT '21' as hour from dual union all
SELECT '22' as hour from dual union all
SELECT '23' as hour from dual union all
SELECT '24' as hour from dual
where rownum < (SELECT DECODE(was || will, '0203', 23, '0302', 25, 24)
FROM (SELECT TO_CHAR(testdate + INTERVAL '1' DAY, 'hh24') was,
TO_CHAR(testdate + INTERVAL '2' DAY, 'hh24') will
FROM (SELECT CAST(TRUNC(TO_DATE('2006.03.26', 'yyyy-mm-dd')) -
INTERVAL '2' DAY + INTERVAL '3' HOUR AS TIMESTAMP WITH TIME ZONE) AT TIME ZONE 'Europe/Moscow' testdate
FROM DUAL)))
Проверял работу, используя данные о переходах на летнее/зимнее время и между ними.