Добрый день.

Сейчас мной начаты работы для приведения в соответствия между моей ИС (Java и Weblogic) и вашей новой модернизированной информационной системы "НУЦ РК".
От Вас была получена анкета с перечнем работа которые нужно провести. По некоторым пунктам у меня возникли не ясность , что они значат. Как и их проверять. Прошу разъяснить их мне и думаю другим участникам форума это будет тоже полезно.
Пойду по порядку работ изложенных в Вашей анкете:

1) "Замена криптопровайдера в ИС"
Это использования класса kz.gov.pki.kalkan.jce.provider.KalkanProvider в коде моей ИС? Так?
Сам ваш криптопровайдер нужен судя по примерам для только проверок с помощью служб OCSP и TSP? Если его еще для чего то можно использовать то приведите примеры?

2) "Проверка электронной цифровой подписи"

Это замена апплета в коде моей ИС? Так?

3) " Проверка построения корректной цепочки от проверяемого регистрационного свидетельства до доверенного корневого регистрационного свидетельства удостоверяющего центра, с учетом промежуточных регистрационных свидетельств удостоверяющих центров;"

Что сей пункт означает мне не понятно. Как это проверить? Разве есть сертификат подписанный КУЦ но не подписанный НУЦ2? Если да , то где?
У меня есть ваши сертификаты КУЦ и НУЦ2. Я поместил их в хранилище ключей для Веблоджика (JKS) как доверительный центры сертификаций. Это и есть то что ваш пункт требует ? Или нет, еще что то нужно сделать? Напишите что и пример приведите.

4) " Проверка срока действия регистрационного свидетельства. Проверка сроков действия от проверяемого регистрационного свидетельства до доверенного корневого регистрационного свидетельства удостоверяющего центра, с учетом промежуточных регистрационных свидетельств удостоверяющих центров;"

Проверяем сертификат просрочен. Да? Но как? Я так и не смог настроить свою ИС что бы он смог понимать ваши новые клиентские сертификаты? Я так понимаю вы должны еще перевыпустить сертификат нашей ИС с sha -2. И только с ним я с могу тестировать аутентификаций новых сертификатов с веблоджиком в моей ИС. Я правильно думаю?
Так же Веблоджик у моей ИС не берет просроченные сертификаты при аутентификаций. Это и есть проверка что вашему пункту и нужна?
Или же вы имеете в виду проверку сертификата при подписаний документа апплетом?
--------------------
Как видите вопросов много. Проясните ситуацию хотя бы по этим первым четырем пунктам вашей анкеты.
Жду с Ваших скорейших ответов, без просто я не смогу работать дальше.

------------------------------
С наилучшими пожеланиями
Рустем Жунусов (MCSD, OCPJP 6)
Гл. специалист Отдела разработки прикладных приложений
РГП "Информационно-вычислительный центр Комитета по статистике
МНЭ РК"

1) Да, все верно, но криптопровайдер нужен не только для работы с OCSP и TimeStamp.
Он в первую очередь нужен для формирования и проверки подписи.

2) Обычно проверка подписи пользователя происходит на стороне сервера. Но на стороне сервера как правило не используют апплет, а подключают библиотеку криптопровайдера и работают с API JCE.

3) В новом НУЦ цепочка доверия будет следующая КУЦ->НУЦ->Пользователь.
Что касается проверки подписи, то необходимо проверять все сертификаты в цепочке доверия. Реализация у всех разная. Для проверки цепочки можно и использовать сам файл сертификата, не обязательно использовать jks. Если же вы имеете в виду только аутентификацию, то да, в таком случае в JKS необходимо поместить корневой сертификат КУЦ и промежуточный сертификата НУЦ.

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

2) Обычно проверка подписи пользователя происходит на стороне сервера. Но на стороне сервера как правило не используют апплет, а подключают библиотеку криптопровайдера и работают с API JCE.
3) В новом НУЦ цепочка доверия будет следующая КУЦ->НУЦ->Пользователь.
Что касается проверки подписи, то необходимо проверять все сертификаты в цепочке доверия. Реализация у всех разная. Для проверки цепочки можно и использовать сам файл сертификата, не обязательно использовать jks. Если же вы имеете в виду только аутентификацию, то да, в таком случае в JKS необходимо поместить корневой сертификат КУЦ и промежуточный сертификата НУЦ.
-----------------
Код проверки подписи есть только в примере апплета. Соответственно логично было предположить что проверять сертификат тоже нужно вашим апплетом. Если нужно использовать API JCE то странно что у вас нет примеров работы с нем . Это получается всем десяткам организаций которые использует ваш апплет нужно догадаться и потратить время на это . Хотя один пример от вас мог бы закрыть проблему. И потом почему у все должна быть разная реализация? Пусть будет одна у всех от Вас.

Также у меня есть два вопроса на сегодня :

а) Когда ваш апплет проверяет подписанные данные то он выполняет вашу же проверку которые вы поставили в требованиях:
" Проверка построения корректной цепочки от проверяемого регистрационного свидетельства до доверенного корневого регистрационного свидетельства удостоверяющего центра, с учетом промежуточных регистрационных свидетельств удостоверяющих центров;"
" Проверка срока действия регистрационного свидетельства. Проверка сроков действия от проверяемого регистрационного свидетельства до доверенного корневого регистрационного свидетельства удостоверяющего центра, с учетом промежуточных регистрационных свидетельств удостоверяющих центров;"
То есть если я вызову ваш метод (например verifyPlainData) данными подписанными чужим сертификатом или просроченным сертификатом то ваш апплет выдаст сообщение об ошибке ?

б) У вас в SDK не хватает сертификатов которые не должны работать . Для того чтобы реально протестировать ИС. Нужен совершено чужой тестовый сертификат для подписи чтобы проверить что он не пройдет. И сертификат подписанный КУЦ , но не подписанный НУЦ2 чтобы проверить работу цепочки. Я уже писал об этом в первом письме. Без них получается я не могу по настоящему протестить свою ИС , а только могу предположить что она работает так как я думаю. Между предположениями и реальностью иногда бывает разница. Как на счет того чтобы их добавить?

--------------------------
С наилучшими пожеланиями
Рустем Жунусов

Добрый день.

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

1) Нет, не выдаст. Будет просто осуществлена проверка подписи.
Методика в первую очередь предназначена для ИС, которые самостоятельно пишут код
серверной части или апплета, просто используя нашу библиотеку криптопровайдера.

2) Сертификатов, выпущенных не НУЦ, но входящих в общую иерархию удостоверяющих центров у нас нет.
Но в любом случае, такие сертификаты будут доверенными для конечных пользователей НУЦ, так как у них один общий корневой УЦ.