Кратко

  • В RFC 3029 служба могла успешно выполнить запрос и вернуть подписанный DVC, в котором результат проверки объекта был отрицательным.
  • Сертификат связывал запрос или отпечаток, время, серийный номер, политику, общий статус и результаты элементов; получатель всё равно проверял ответ и принимал собственное решение.

Слово «сертификат» часто воспринимается как знак одобрения. Data Validation Certificate из RFC 3029 был другим инструментом: подписанной записью о выводе сервера при определённых условиях. Отрицательный вывод не делал такую запись ошибочной. Напротив, он мог быть её главной ценностью.

Спецификация прямо говорит, что DVCSCertInfo возвращается после успешного выполнения службы, но это не означает успешной валидации. Запрос мог быть понят и обработан, подпись ответа могла быть верной, а документ или сертификат — не пройти правила. Эти три состояния нельзя сводить к одному слову «успех».

Четыре службы утверждали разные факты

cpd удостоверяла владение данными, которые действительно были представлены серверу. ccpd принимала только дайджест и удостоверяла заявление, связанное с этим отпечатком; исходные байты сервер мог не видеть. Доказательство предъявления идентификатора нельзя превращать в доказательство предъявления объекта.

vsd проверяла подписанные документы, включая математическую правильность подписей, сертификаты, их состояние и цепочки доверия. vpkc проверяла один или несколько сертификатов на заданный момент. Входными данными могли быть CRL, OCSP, каталоги и другие DVCS, но RFC 3029 не предлагал заменить ими CRL и OCSP в крупных открытых средах.

Внешне похожие DVC отвечали на разные вопросы: были ли предъявлены данные, был ли предъявлен дайджест, удовлетворяет ли подписанный документ политике, удовлетворяет ли сертификат правилам пути и состояния. Единая отметка «проверено» уничтожила бы эти границы.

Подпись защищала структурированный ответ

DVC представлялся как CMS SignedData. Внутри сохранялись сведения запроса, messageImprint, возрастающий серийный номер, время ответа, политика, общий статус и подробности по сертификатам или подписям. Если время поступало от внешней службы, DVCS должна была проверить и его.

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

Политика объясняла разные честные выводы об одном объекте. Службы могли выбирать разные корни доверия, источники статуса и пороги числа подписей. DVC не утверждал всеобщую действительность. Он фиксировал: такой сервер в такое время по такой политике вернул такой результат для такого запроса.

Общий статус не заменял детали

В наборе сертификатов общий сбой мог быть вызван одним элементом, который находился в подробностях. В документе с несколькими подписями одна плохая подпись не обязательно означала провал всего документа: если политика требовала достаточного набора, был возможен grantedWithMods. И наоборот, отдельные правильные подписи могли не удовлетворять общему числу или сочетанию. granted допускался только при успешной проверке всех подписей.

WAITING тоже не был слабым разрешением. Он означал отсутствие окончательного ответа. Общий статус был выводом политики, а не заменой элементных фактов.

Подписанное «нет» отличалось от ошибки без полномочия

После выполненной проверки подписанный DVC мог сообщить, что объект недействителен. Если формат или аутентификация заявителя мешали выполнить запрос, сервер возвращал уведомление об ошибке. В первом случае вопрос получил отрицательный ответ; во втором до существа не дошли.

Если DVCS не могла создать действительную подпись, например при известной компрометации ключа, RFC 3029 предусматривал структуру без сведений о подписавшем. Клиент обязан был считать её критической и фатальной ошибкой и не доверять содержанию по умолчанию. Подписанный отрицательный вердикт — атрибутируемое свидетельство. Неподписанная ошибка — отказ самой власти ответа.

RFC 3029 вышел в феврале 2001 года как Experimental, а не Internet Standard. Позднее RFC 3379 и RFC 5055 описали требования и протокол делегированной проверки. Они не доказывают внедрение DVCS. Историческая граница уже: передача вычисления службе не передаёт ей автоматически решение прикладной системы.

Источники

Lu Heng не писал и не одобрял RFC 3029 или связанные стандарты PKIX. Его тексты используются здесь как явно раскрытые аналитические рамки.