Не могу понять, почему моя подпись PDF не поддерживает LTV

Question

Я создаю документ PDF с подписью и хочу, чтобы он был включен LTV. Для этого я подписываю PDF при его создании, а затем добавляю вторую версию, содержащую DSS, с информацией, связанной с проверкой (VRI). Как я обнаружил в некоторых статьях, мне нужно добавить цепочку сертификатов (без сертификата root - полномочия) и список отзыва сертификатов (CRL). В моем случае оба будут иметь 2 элемента. После этого я добавляю запись для VRI, которая представляет собой SHA-1 га sh содержимого подписи (найденного в первой версии PDF в / Contents) со значением, которое ссылается на сертификаты и CRL, упомянутые выше.

Как для сертификатов, так и для элементов списка отзыва я использую поток необработанных байтов содержимого.

Вот мой образец PDF

Редактировать

Способ получения информации CRL использует WynCrypt следующим образом:

//Retrieve chained certificate
if(!CertGetCertificateChain(hChainEngine, pSignerCert, pTime, hAdditionalStore, &chainPara, dwFlags, NULL, &ppChainContext))
    return NULL;

//first cert in chain is the end cert; last one is the root cert
for(int i = 0; i < ppChainContext->cChain; ++i)
{
    PCERT_SIMPLE_CHAIN simpleChain = ppChainContext->rgpChain[i];

    for(int j = 0; j < (int)simpleChain->cElement - 1; j++)//do not include root certificate
    {
        PCERT_CHAIN_ELEMENT chainElement = simpleChain->rgpElement[j];

        if(chainElement->pCertContext)
        {   
            //the certificate bytes
            byte* certBytes =chainElement->pCertContext->pbCertEncoded
        }

        if(chainElement->pRevocationInfo && chainElement->pRevocationInfo->pCrlInfo)
        {
            PCCRL_CONTEXT crlContext = chainElement->pRevocationInfo->pCrlInfo->pBaseCrlContext;//get revocation context

            //the bytes that will be written in PDF
            byte* crlBytes = crlContext->pbCrlEncoded;
        }
    }
}

Answer 1

Термин «LTV включен»

Насколько я знаю, нет формальной спецификации значения термина «LTV включен». Есть несколько ненормативных описаний, в частности:

• Леонард Розентхол (PDF Architect & Principal Scientist в Adobe) однажды охарактеризовал его как

  LTV включен означает, что вся информация, необходимая для проверки файла (минус root сертификаты), содержится в.

  (список рассылки iText на 10 января 2013 г.)

• Другой сотрудник Adobe, Стивен Мэдвин, описывает реализацию как

  В рамках процесса проверки [Acrobat] выясняет, нужно ли это go онлайн, чтобы загрузить информацию об отзыве, или, это вся информация об отзыве, встроенная в файл PDF. На данный момент он знает, что он собирается сказать на панели навигации по подписи. Если необходимо было загрузить данные, то подпись не поддерживает LTV, но если в файле содержится все обеспечение отзыва, тогда подпись включена.

  (форумы поддержки Adobe в сентябре 24, 2013)

Таким образом, значение термина «LTV enabled» зависит от деталей реализации алгоритмов проверки подписи Adobe Acrobat (который являются закрытым исходным кодом и не обязательно фиксированными) и на базовых конфигурациях. Вы можете прочесть меня об этом в нескольких старых ответах о переполнении стека ...

Тем не менее, механизмы, лежащие в основе этих деталей реализации, не являются полностью произвольными, они, по сути, образуют профиль (хотя и проприетарный , закрытая и, возможно, даже изменяющая одну) существующих опубликованных спецификаций по этой теме c, в частности RFC.

В частности, совершенно ясно, что вы должны сделать, чтобы иметь хороший шанс пометить свою подпись «LTV включен» - добавить всю информацию, которая может понадобиться валидатору в процессе валидации, в частности

• Добавить все промежуточные сертификаты из сертификата подписавшего в сертификат, которому доверяет Adobe. Если вы не уверены, какие сертификаты являются доверенными, добавьте все сертификаты до root сертификата. Если вы знаете, что какой-либо из этих сертификатов будет перекрестно подписан другим ЦС, добавьте сертификаты всех этих возможных цепочек.
• Для всех этих сертификатов (кроме root сертификатов) получите информацию об отзыве (CRL или ответы OCSP). ) и добавьте их тоже.
• Для каждого добавленного ответа CRL и OCSP определите свой соответствующий сертификат подписавшего, добавьте этот сертификат и сертификаты в его цепочке к документу, найдите и добавьте информацию об отзыве для них (если они root сертификаты или сертификаты с расширением id-pkix-ocsp-nocheck, или у вас уже есть информация об их аннулировании) и т. д.

Однако остается одна проблема, и она определяет, как именно добавьте всю эту информацию в свой PDF.

Если перед подписанием вы знаете сертификат подписавшего, вы можете добавить все сертификаты в хранилище сертификатов в контейнере подписи для создания и все данные отзыва в подписанный adbe-revocationInfoArchival атрибут SignerInfo в нем.

Если вы этого не сделаете, вы можете поместить эти сертификаты и информацию об аннулировании в хранилище безопасности документов (DSS) PAdES, то есть в специальные структуры при постепенном обновлении подписанного PDF. Этот DSS еще не определен в ISO 32000-1; Первоначально он был определен в технических спецификациях ETSI (ETSI TS 102 778-4) и более поздних нормах (ETSI EN 319 142-1) и был принят в текущую спецификацию PDF ISO 32000-2.

Почему ваша подпись PDF не поддерживает LTV

Ваш PDF использует DSS для хранения сертификатов и информации об аннулировании, но в ней есть недостатки.

Как уже объяснил Питер Г. в его ответе , DSS вашего PDF в массивах CRL и CRL не содержит фактических CRL.

Объекты там - это не просто ответы OCSP, как сказал Питер Г., но вместо этого ответы OCSP обернуты в какую-то другую структуру. Фактический ответ OCSP в этих объектах начинается со смещения 160 ...

Я думаю, ваш код в этом буфере crlContext->pbCrlEncoded содержит некоторую оболочку для произвольной информации об аннулировании, и вы должны сначала проанализировать ее, чтобы увидеть, какой тип это на самом деле и затем разверните этот фактический объект информации отзыва и вставьте его в соответствии с его типом. Я не знаю WynCrypt, так что это просто догадки ...

Дополнительные элементы в DSS

Два года go Я также создал LTV-enabler. В то время эксперименты предполагали, что Adobe Acrobat требует определенных элементов DSS, которые указываются как необязательные, по крайней мере, при определенных обстоятельствах: я включил LTV в PDF, используя Adobe Acrobat, и постепенно уменьшил этот PDF до того, что я создал. Оказалось, что подраздел VRI DSS и записи в нем TU были необходимы, удалив либо сделав файл не поддерживающим LTV.

Теперь я использовал свой тот LTV -enabler (на самом деле вариант, которому могут быть предоставлены дополнительные сертификаты) для LTV-включения вашего PDF. Это сработало. Из интереса я также сократил этот PDF с поддержкой LTV. Интересно, что я мог бы удалить TU и даже VRI без потери статуса с поддержкой LTV.

Таким образом, либо Adobe Acrobat изменился, чтобы вообще больше не требовать этих элементов или файл, с которого я начинал в моих предыдущих экспериментах, был несколько особенным случаем, требующим дополнительных данных, в то время как в других случаях они не требуются.

Answer 2

Только что посмотрел, и объекты 15 и 16 являются ответами OCSP, но вы добавляете их как CRL:

Потоковый объект 15

Потоковый объект 16

Этот декодер ASN.1 очень удобен!

В моем средстве просмотра исходного кода словарь DSS (Объект 21):

<<
/CRLs 19 0 R
/Certs 20 0 R
/VRI 18 0 R
>>

19 указывает на атом массива: [15 0 R 16 0 R]

Опять VRI не нужен для LTV, в настоящее время это в основном оптимизация (см. Приложение A1 в ETSI TS 102 778-4 , которое в основном взят из спецификации PDF 2.0). Если вы используете его и добавляете метку времени (/ TS запись), Adobe в настоящее время даже не отображает ее правильно. В VRI TU / TS также является полностью необязательным и не влияет на достоверность LTV (там же).

Answer 3

РЕШЕНИЕ

Это то же решение, которое работало для этой проблемы: Другая проблема