Summary

  • В индивидуальном проекте IETF владелец подписывает агенту лимит в 200 фунтов. Проверка находит в одном журнале расходы на 230 фунтов и отмечает превышение.
  • Лимит считается по каждому журналу отдельно. Два журнала по 125 фунтов могут пройти проверку, хотя общий счёт на 250 фунтов превысит сумму, которую разрешил владелец.

Два зелёных отчёта и один лишний чек

Агент покупает канцелярские товары для вымышленного офиса. Проект Павла Измайлова даёт ему разрешение максимум на 200 фунтов суммарно и на 100 фунтов за заказ. Поставщик заверяет каждый заказ встречной подписью. Если цена выше 60 фунтов, владелец должен отдельно одобрить именно эту покупку. В учебном журнале четыре записи: 45, 80, 25 и 80 фунтов. Итого 230. Проверяющий обнаруживает превышение и отсутствие одного необходимого одобрения. С этим журналом арифметика работает.

Теперь тот же подписанный документ попадает к двум независимым регистраторам. Каждый записывает покупки на 125 фунтов; нужные подписи и согласования на месте. Первый проверяющий видит 125 из разрешённых 200 фунтов. Второй видит столько же. Оба выдают успешный результат. Владелец платит 250 фунтов. Это расчётный сценарий на основе правил проекта, а не сообщение о реальном инциденте. В разделе безопасности прямо сказано: суммы, число операций и временные ограничения проверяются в пределах одного журнала. Записи по одному разрешению из двух журналов не складываются.

Такую разницу нельзя списать на поддельную подпись. Подпись владельца под общим пределом может быть настоящей. Подписи агентов и поставщиков тоже. Проблема в том, что система выдаёт локальную оценку за ответ на общий вопрос. Если граница расходов общая, но наблюдение разделено, два честных журнала могут совместно нарушить решение человека. У кого есть право сказать, что лимит соблюдён, когда его проверяющий видел только половину касс?

Документ говорит гораздо точнее рекламного обещания

Редакция 01 опубликована 24 октября 2026 года. Официальная карточка IETF указывает индивидуальный Internet-Draft без ответственного директора области и без формального статуса документа потока IETF. Предложение описывает проверяемую последовательность. Владелец подписывает ключом доступа разрешение с машинными ограничениями: общий бюджет, предел отдельной суммы, количество действий и скользящие интервалы. Агент подписывает квитанцию на каждое действие. Регистратор помещает квитанции в дерево с подписанными вершинами и отметками времени. Получив этот набор, сторонний проверяющий может пересчитать его офлайн.

В новой редакции ужесточены некоторые правила, по которым проверяющий принимает ключи, подписи и имена полей. Приложение C одновременно фиксирует: байты самих записей по сравнению с редакцией 00 не изменились. Точнее прочитать один журнал полезно. Автоматически увидеть соседний журнал от этого не получится.

Проверка проводится после совершения действия. Проект не описывает орган исполнения, который останавливает покупку до того, как она начинает действовать. В примере сумма 230 фунтов обнаруживается уже после записи заказа, который поднял итог выше 200. Такая запись пригодится для претензии, спора или сверки. Для остановки расхода на кассе нужен общий резерв денег до подтверждения заказа, а также единое правило для одновременных запросов, повторной отправки после сбоя и двух регионов, видящих старый остаток.

Разные подписи отвечают на разные вопросы. Встречная подпись подтверждает, что указанный ключ поставщика подписал конкретную квитанцию. Сам проект предупреждает: ключ не доказывает реальную личность того, кто его держит. Дополнительное согласие владельца относится к конкретному действию. Подписанная вершина дерева закрепляет историю того журнала, который она охватила. Ничто из перечисленного само по себе не говорит, сколько того же разрешённого бюджета уже потрачено в другом месте.

Безупречная история не создаёт общего счёта

Для журнала проект опирается на дерево Меркла из RFC 9162. Доказательство согласованности показывает, что одно дерево росло добавлением, а не переписыванием прошлого. Если независимый участник хранит подписанную вершину, последующее сокращение увиденной им истории можно обнаружить. Это сильный инструмент при споре о содержимом конкретного журнала. Он не суммирует расходы двух разных деревьев.

Проект отмечает и более очевидные угрозы: регистратор может убрать последнюю вершину, если никто её не сохранил; он может показывать разным людям разные представления без предусмотренного между ними доказательства согласованности. Но схема с двумя расходами по 125 фунтов даже не нуждается в подмене истории. Оба журнала могут быть полными и добросовестными. Превышение возникает между ними, там, где нет общего счётчика. Криптография делает каждый набор записей убедительным, а бухгалтерия владельца остаётся разорванной.

Раздел о реализации перечисляет две библиотеки самого автора. В Python-библиотеке, согласно документу, ещё нет проверки подписи SLH-DSA для вершины дерева; также отмечена проблема с одним атрибутом отметки времени. Независимой реализации документ не называет. Для проверки реального обещания нужен открытый опыт: одно разрешение, два одновременно работающих регистратора, суммарный запрос выше 200 фунтов и отказ в лишнем платеже. Независимый проверяющий должен затем восстановить весь расход из полученных записей.

Sources