Цифровият подпис с удължена валидност (Long-Term Validation, LTV) е вид цифрово подписване, при което се удължава валидността на подписа върху съдържание, дори валидността на потребителския (end-user) X.509 сертификат, с който е извършен подписа върху съдържанието, да е изтекла, на базата на времеподпиване на подписа върху съдържание чрез Time Stamping сървърски сертификат с много дълго време на валидност.

Важно! Отбележете, че при създаване на LTV, се времеподписва цифровия подпис, който е извършен върху съдържанието, а не самото съдържание.

Обяснено с пример: на 28 април 2019, съдържание е подписано с потребителски сертификат, който има валидност до 18 май 2020 г, а получения цифров подпис е времеподписан от Time Stamping сървър, чиито X.509 сертификат е валиден до 31 декември 2029 г. В този случай валидността на подписа върху съдържанието е до 31 декември 2029 г, а не до 18 май 2020 г.

Валидността на LTV трябва да бъде проверявана внимателно. Не бива потребителският X.509 сертификат, чрез който е подписано съдържанието, да е бил отменен от издателя си преди времето, по което е извършено неговото цифровото подписване от Time Stamping сървъра. Това налага определени изисквания върху този, който издава потребителски сертификати, чрез който може да се извършва LTV - в CRL списъците (и OCPS) на издателя трябва да са описани серийните номера на отменени сертификати (ако такива има) даже, ако срока на валидност на тези сертификати е вече изтекъл. Целта е така да се покаже на всеки, който проверява LTV, дали X.509 сертификата, чрез който се валидира подписа върху съдържанието, не е бил отменян (поради разкриване на частния ключ към него, поради злоупотреба и др) преди времето, по което Time Stamping сървъра е подписал цифровия подпис върху съдържанието.

Съществуват различни формати, в които може да бъде запазен LTV. Подписите върху съдържнието и подписа за времето, по което е създаден подписа върху съдържанието (това са два отделни цифрови подписа), могат да бъдат запазени в два различни файла, както това е показано в примерите по-долу. Възможно е тези подписи да бъдат запазени в един XML блок, в един бинарен (двоичен) блок и прочие. Във всеки отделен случай е нужно да знаете как да отделите двата подписа и да ги проверите независимо един от друг.

Защо е нужно да се използва LTV или защо е нужно да се прави времеподписване на подписа върху съдържанието, а не на самото съдържание? Т.е. не е ли напълно достатъчно да се направи само времеподписване на съдържнието, както това е показано в документа "Заявяване на TSA цифрово подписване на време, относно същестуващо съдържание, в CentOS 7 и Scientific Linux 7, с последваща проверка на подписването и използването му за датиране на съдържание"? Обърнете внимание на факта, че при времеподписването с изпращане на заявка към Time Stamping сървъра, вие не влагате в тази заявка никаква информация относно вашата идентичност, от гледна точка на X.509 PKI. Вие влагате единствено контролната сума на съдържанието. Поради това времеподписването гарантира, че дадено съдържание е било известно към даден момент от време, но не може да каже кой е видял (имал достъп до) това съдържание. Когато създавате LTV, вие правите това не върху съдържанието, а върху цифровия подпис, който някой е направил върху въпросното съдържание. По този начин, времеподписването в LTV свидетелства, че този, който е имал достъп до частния ключ на X.509 сертификата, с който се валидира цифровия подпис върху съдържанието, е този, който е видял (достъпвал) съдържанието към момента на времеподписването.

За да създадете цифров подпис с удължена валидност (LTV) върху съдържание, вие трябва да разполагате с валиден потребителски (end-user) X.509 сертификат и достъп до Time Stamping сървър.

Първо подпишете съдържнието, създавайки отделяем цифров подпис (отделяем значи, че този подпис е във файл, който е различен от файла, в който е съдържанието). Може да използвате следния пример, в който съдържнието се намира във файла content.file, частния ключ към вашия X.509 сертификат е във файла user_key.pem, копие от вашия X.509 сертификат е в user_cert.pem, а сертификатната верига е в SU_ECC_Identity_Management_CA.crt:

$ openssl cms -binary -sign -in content.file -inkey user_key.pem -signer user_cert.pem -certfile SU_ECC_Identity_Management_CA.crt -out content.file.p7b -outform DER -md sha384

Резултатът ще бъде запазен във файла content.file.p7b (ако следвате имената на файлове във примера по-горе).

След това, трябва да създадете заявка за подпис за време, да я изпратите до Time Stmping сървъра и да получите от него подписа върху времето. Това може да направите като следвате инструкциите в секции "Създаване на заявка за подписване на време с цел датировка на съдържание" и "Изпращане на заявката за подписване на време към TimeStamp сървър и получаване на цифрово подписания отговор" на документа "Заявяване на TSA цифрово подписване на време, относно същестуващо съдържание, в CentOS 7 и Scientific Linux 7, с последваща проверка на подписването и използването му за датиране на съдържание". Ако следвате имената на файлове, които са използвани в примерите, подписа за време ще е във файла content.file.p7b.tsr.

Създаденият цифров подпис с удължена валидност (LTV) е двойката цифров подпис върху съдържанието и цифров подпис върху времето на подписа върху съдържанието! Т.е. ако се следват имената на файлове от примера по-горе, то двата файла content.file.p7b и content.file.p7b.tsr (заедно) са LTV.

За да валидирате LTV цифрово подписване, което е било извършено по начина описан по-горе, трябва да разполагате със съдържанието, което е обект на проверката (за примера това е съдържанието във файла content.file), с цифровия подпис върху него (content.file.p7b) и подписа за време върху този цифров подпис (файла content.file.p7b.tsr). След това изпълнете следната двустадийна процедура:

• проверка на цифровия подпис върху съдържанието:

  За целите на тази проверка, трябва да имате файла с отделения цифров подпис, файла със съдържанието (което е било обект на подписването) и X.509 сертификата на този удостоверител, който валидира веригата от сертификати към сертификата на извършителя на цифровия подпис (този извършител трябва да вложи веригата в цифровия блок с подписа). В примера по-долу цифровия подпис е във файла content.file.p7b, подписаното съдържание е в content.file, а файла, който съдържа X.509 сертификата на удостоверителя е SU_ECC_Root_CA.crt. На базаа на тези уточнения, проверката на валидността на цифровия подпис спрямо съдържанието се извършва по следния начин:

  $ openssl cms -verify -in content.file.p7b -inform DER -binary -content content.file -CAfile SU_ECC_Root_CA.crt -out /dev/null

  Ако цифровият подпис е успешно валидиран, ще получите следния резултат:

  Verification successful

• проверка на цифровия подпис за време и датиране на съдържанието:

  Тази проверка има смисъл само, ако предишната (виж "проверка на цифровия подпис върху съдържанието" по-горе) е успешна! Идеята на този процес е да датира подписа, който е извършен върху съдържанието и който е проверен по рецептата, показана по-горе. Ако този подпис е датиран успешно, то е ясно, че той е поставен върху съдържание, което е било известно на подписващия го по времето, по което заявката за времеподписване е изпратена до Time Stamping сървъра. Такова датиране на съдържание е транзитивно.. Датирането може да бъде извършено по инструкциите в "Заявяване на цифрово подписване на време, относно същестуващо съдържание, в CentOS 7 и Scientific Linux 7, с последваща проверка на подписването и използването му за датиране на съдържание". За целта (ако следвате примерните файлове, дадени за илюстрация по-горе), ще трябва да датирате съдържанието във файла content.file.p7b спрямо подписа върху времето, наличен в content.file.p7b.tsr.

Ако и двете проверки, описани по-горе, са успешни, това означава, че с голяма вероятност може да твърдите, че подписалия съдържанието във файла content.file (този, който е създал подписа в content.file.p7b) е имал достъп до това съдържание по, преди и след времето, което е цифрово подписано от Time Stamping сървъра и запазено в content.file.p7b.tsr.