Статус: Активный участник
Группы: Участники
Зарегистрирован: 04.10.2011(UTC)
Сообщений: 74
Откуда: Moscow
Сказал(а) «Спасибо»: 1 раз
Поблагодарили: 1 раз в 1 постах
|
Здравствуйте, пытаюсь реализовать подпись в формате CAdES-X Long Type 1 используя JCP. Достаточно ли полная в JCP реализация сущностей для формирования CAdES-X Long Type 1? В частности есть ли TSP Client (package ru.CryptoPro.JCP.ASN.PKIXTSP оно?) OCSP Client (package ru.CryptoPro.JCP.ASN.PKIXOCSP оно?) Подскажите пожалуйста, есть ли пример для этого (почитал примеры в samples.jar, но там как я понял только CAdES-BES формируется). Все ли указанные в RFC-5126 атрибуты подписи необходимо использовать? Стандарт который вы предлагаете использовать немного путан(или я не туда смотрю?), Цитата:
7.1.4. Создание ЭЦП производится следующим образом:
1. Документ, который должен быть подписан, загружается в средство криптографической защиты информации (СКЗИ).
2. Создаются подписываемые атрибуты, указанные в перечислении 5 пункта 5.
Перечисление 5 в пункте 5: Цитата:5) Хэш-коды каждого из перечислений 1-6 (см. ниже), составляющих доказательства подлинности. Доказательства подлинности включают в себя:
1) Сертификат ключа подписи, указанной в перечислении в).
2) OCSP-ответ, позволяющий удостовериться в действительности сертификата ключа подписи.
3) Сертификат OCSP-сервера, позволяющий удостовериться в действительности OCSP-ответа.
4) Сертификат службы штампов времени, позволяющий удостовериться в действительности штампа времени, заверяющего ЭЦП.
5) Сертификаты промежуточных УЦ, если таковые имеются.
6) OCSP-ответы, позволяющие удостовериться в действительности сертификатов ключей подписи промежуточных УЦ, указанных в перечислении 5, либо, если сертификаты таких УЦ не содержат поля AIA (содержащего адрес службы OCSP), соответствующие CRL.
Хэш-коды доказательств подлинности содержатся в следующих атрибутах:
complete‑certificate‑references. Определяется в ETSI TS 101 733 и содержит хэш-коды всех сертификатов, используемых при проверке ЭЦП, указанные в перечислениях 1), 3), 4) и 5).
complete‑revocation‑references. Определяется в ETSI TS 101 733 и содержит хэш-коды всех CRL и/или OCSP-ответов, использующихся при проверке ЭЦП, указанные в перечислениях 2) и 6). Не вяжется, либо я чего то не знаю. С примером формирования CAdES-X Long Type 1 было бы значительно проще.
|
|
|
|
|
|
Статус: Сотрудник
Группы: Администраторы, Участники Зарегистрирован: 10.12.2008(UTC) Сообщений: 924  Откуда: Крипто-Про Поблагодарили: 99 раз в 95 постах
|
Здравствуйте! Цитата:Достаточно ли полная в JCP реализация сущностей для формирования CAdES-X Long Type 1?
Подскажите пожалуйста, есть ли пример для этого (почитал примеры в samples.jar, но там как я понял только CAdES-BES формируется). В настоящий момент у нас нет примера формирования CAdES-X Long Type 1 с использованием JCP и мы не пытались реализовать подпись в формате CAdES-X Long Type 1 при помощи JCP. Набора сущностей вполне хватит для самостоятельной реализации CAdES-X Long Type 1. Цитата:В частности есть ли TSP Client (package ru.CryptoPro.JCP.ASN.PKIXTSP оно?) OCSP Client (package ru.CryptoPro.JCP.ASN.PKIXOCSP оно?) Нет. Цитата:Все ли указанные в RFC-5126 атрибуты подписи необходимо использовать? Необходимо использовать все те атрибуты, про которые в RFC5126 сказано, что они должны присутствовать в подписи нужного вам формата (CAdES-X Long Type 1). Цитата:Стандарт который вы предлагаете использовать немного путан(или я не туда смотрю?) Данный стандарт следует рассматривать как образец документа для внутреннего регламента учреждения, использующего подпись типа CAdES-X Long Type 1, а не как руководство по ее созданию. Смотреть лучше на RFC5126 и ETSI TS 101 733
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 04.10.2011(UTC)
Сообщений: 74
Откуда: Moscow
Сказал(а) «Спасибо»: 1 раз
Поблагодарили: 1 раз в 1 постах
|
Спасибо за скорый ответ! Новожилова Елена написал:Цитата:В частности есть ли TSP Client (package ru.CryptoPro.JCP.ASN.PKIXTSP оно?) OCSP Client (package ru.CryptoPro.JCP.ASN.PKIXOCSP оно?) Нет. Елена, подскажите пожалуйста достаточно ли для формирования OCSP ответа использовать класс CertPathValidator(в стандартной поставке java, package java.security.cert), совместим ли ответ (CertPathValidatorResult) c API входящим в JCP? Возможно ли комбинирование функционала bouncycastle 1.4.6 и криптопро jcp, где в качестве криптопровайдера и api для формирования ASN1 формата используется криптопро, а функционал TSP и(?) OCSP клиентов реализован через bouncycastle (как с правовой так и с технической точки зрения)? Отредактировано пользователем 18 октября 2011 г. 20:06:34(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Сотрудник
Группы: Администраторы, Участники Зарегистрирован: 10.12.2008(UTC) Сообщений: 924 Откуда: Крипто-Про Поблагодарили: 99 раз в 95 постах
|
Честно говоря затрудняюсь ответить, так как мы не тестировали совместимость JCP с другими продуктами.
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 04.10.2011(UTC)
Сообщений: 74
Откуда: Moscow
Сказал(а) «Спасибо»: 1 раз
Поблагодарили: 1 раз в 1 постах
|
Новожилова Елена написал:Цитата:В частности есть ли TSP Client (package ru.CryptoPro.JCP.ASN.PKIXTSP оно?) OCSP Client (package ru.CryptoPro.JCP.ASN.PKIXOCSP оно?) Нет. Похоже вы ошибаетесь(по крайней мере насчет TSP), только все же что-то не так с декодированием ответа. Завел новый тред.
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
