Java-реализации TSP, OCSP и CMS

#java #cryptography #pki #jce #jca

#java #криптография #pki #jce #jca

Вопрос:

Я пытаюсь понять java API для цифровых подписей. Я должен использовать пользовательский cryptoprovider для создания цифровой подписи. Я знаю, как подписать документ и получить отдельную подпись, используя этот CSP, теперь мне нужно добавить временную метку и статус сертификата к этой подписи (чтобы сделать подпись действительной для государственных органов). Это делается с использованием TSP и OCSP. Вопрос:

  1. где должен быть TSP-клиент?
  2. прав ли я, что достаточно использовать встроенную поддержку java OCSP для проверки сертификата?
  3. связана ли tsp и информация о проверке каким-либо образом с CMS?
  4. последнее и самое интересное: что мне делать с информацией о временной метке и информацией о проверке сертификата: будут ли это отдельные файлы или они являются частями подписи??

Ответ №1:

где должен быть TSP-клиент?

Чтобы использовать CMS, TSP и OCSP, вы можете проверить Bouncy Castle. Они поддерживают все те, что входят в основной пакет, а также дополнительные пакеты CMS и TSP.

прав ли я, что достаточно использовать встроенную поддержку java OCSP для проверки сертификата?

Хотя стандартный механизм проверки сертификата PKIX поддерживает OCSP, может иметь смысл интегрировать, например, код OCSP Bouncy Castle в виде пользовательского средства проверки PKIXCertPathChecker. Вы можете либо добавить его поверх существующей проверки, либо сделать его полноценной заменой, инструкции можно найти здесь . У нас были проблемы с использованием встроенной поддержки OCSP при подключении через прокси, поэтому мы заменили значение по умолчанию, используя этот метод в прошлом.

связана ли tsp и информация о проверке каким-либо образом с CMS?

Ответ с меткой времени, который отправляет вам TSP-сервер, является не чем иным, как еще одним подписанным CMS, поэтому сам по себе снова является своего рода подписью. То, что вы обычно делаете, чтобы избежать множества отдельных файлов, — это использование функции unsigned properties CMS для включения вашей временной метки в саму исходную подпись. Вы просто добавляете временную метку как свойство подписи без знака в поле usignedAttrs в SignerInfo, тем самым сводя к минимуму отдельные файлы ровно до одного, сама подпись, которая включает всю дополнительную информацию в поля signedAttrs и unsignedAttrs.

последнее и самое интересное: что мне делать с информацией о временной метке и информацией о проверке сертификата: будут ли это отдельные файлы или они являются частями подписи??

Временные метки, которые я уже описал; информация о проверке, такая как CRLS и ответы OCSP, может быть встроена в поле «crls» подписанных данных. Вы можете добавлять их, когда захотите, не нарушая фактическую подпись — это содержимое, а также неподписанные свойства не будут приниматься во внимание ни для генерации, ни для проверки подписи.

Если вы встраиваете информацию, используя только CMS (RFC 5652), это означает, что в итоге вы получите довольно проприетарную схему. В зависимости от ваших потребностей, этого может быть уже достаточно. Однако, если вам понадобится что-то более совместимое, вы можете обратиться к CAdES (ETSI TS 101 733), бесплатному стандарту ETSI, который можно загрузить по адресу http://pda.etsi.org . Этот стандарт предоставляет больше информации о том, как правильно вставлять дополнительные данные подписи, такие как временные метки и информация об отзыве.

Комментарии:

1. может быть, вы можете ответить мне (я думаю, вы довольно разбираетесь в вопросах криптографии): я реализую CAdES-X Long Type 1, а в подписанных атрибутах SignerInfo есть обязательный атрибут с именем SigningCertificateV2.SigningCertificateV2 ::= ПОСЛЕДОВАТЕЛЬНОСТЬ { ПОСЛЕДОВАТЕЛЬНОСТЬ сертификатов ESSCertIDv2, ПОСЛЕДОВАТЕЛЬНОСТЬ политик PolicyInformation НЕОБЯЗАТЕЛЬНО } PolicyInformation ::= ПОСЛЕДОВАТЕЛЬНОСТЬ {policyIdentifier CertPolicyId, policyQualifiers РАЗМЕР ПОСЛЕДОВАТЕЛЬНОСТИ (1 .. MAX) PolicyQualifierInfo НЕОБЯЗАТЕЛЬНО } может быть, вы знаете, где я могу найти источник информации о политике?

2. Добро пожаловать! Информация о политике является необязательной и AFAIK не используется в подписях CAdES.

Ответ №2:

Я бы рекомендовал использовать BouncyCastle (http://www.bouncycastle.org/java.html ) если вы изучаете криптографию Java, связанную с поставщиком.

Цитирование с его веб-сайта:

  • Генераторы / процессоры для OCSP (RFC 2560).
  • Генераторы / процессоры для TSP (RFC 3161 и RFC 5544).