Кратко

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

Подтверждать, не владеть

IAB и связанная с существующей записью IETF IESG в RFC 1984 признали законную роль удостоверяющих центров. Центр подписывает утверждение о том, что определённая личность использует определённый открытый ключ. Иерархия центров и государственный центр для сделок с гражданами допустимы.

Для этой функции закрытый ключ пользователя не нужен. Сертификат создаёт проверяемое публичное утверждение; депозитарий хранит возможность расшифровать или подписать. Общее слово «доверие» скрывает разницу между свидетельством и управлением.

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

Восстановление для владельца

Владелец архивных данных может добровольно сохранить восстанавливаемую копию ключа. Он принимает дополнительный риск хранения ради защиты от безвозвратной потери. Ключ короткого разговора может вообще не требовать жизни после сеанса.

Обязательное депонирование меняет адресата услуги. Если запасная копия доступна государству, но не владельцу после утраты, она не обеспечивает его непрерывность. Запись о приёме ключа также не доказывает, что ключ актуален, полон, не скомпрометирован, доступен законно и действительно открывает нужные данные.

Подпись с двумя возможными авторами

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

Это изменение возникает в момент копирования, а не после злоупотребления. Решение резервировать ключи конфиденциальности не распространяется автоматически на ключи подписи. Назначение определяет допустимое хранение.

Самое слабое правило становится общей сборкой

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

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

Открытая оболочка может содержать другой шифртекст

Пользователь способен сначала зашифровать сообщение и только затем применить обязательную депозитарную оболочку. После её снятия хранитель увидит ещё один шифртекст. Видимое соблюдение требования не является доказательством доступного содержания.

RFC 1984 различает долговременный закрытый ключ и состояние сеанса. При прямой секретности получение долговременного ключа до или после разговора может не восстановить прошлый трафик; контроль может требоваться во время сеанса. Сам RFC называет это упрощением. Надёжный вывод узок: постоянная копия сама по себе не доказывает читаемость истории.

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

В 2015 году изменение статуса IETF без переписывания текста сделало его Best Current Practice, ныне BCP 200. Это свидетельство институциональной преемственности, а не закона, внедрения или результата эксплуатации.

RFC 1984 сохранил карту несовместимых доказательств: сертификация не равна хранению; хранение не равно восстановлению для владельца; восстановление не равно авторству; долговременный ключ не равен открытому тексту сеанса.

Первичные документы

RFC 1984 TXT · RFC 1984 HTML · запись RFC Editor · запись IETF · изменение статуса · история · голосование IESG · IAB · IESG · существующая запись IETF