Кратко

  • Экспериментальный RFC 3183 описал S/MIME-службы на границе организации. Доменная подпись могла подтвердить выпуск после внутренней проверки, но без подписи самого отправителя внешнему получателю разрешалось уверенно назвать только домен.
  • Подписи отправителя, домена, рецензента и дополнительных атрибутов означали разные действия; доменное шифрование и расшифрование ещё раз меняли хранителя данных. Общий статус «доверено» стирал эти различия.

Опубликованный в октябре 2001 года Domain Security Services using S/MIME обращался к MTA, шлюзам, межсетевым экранам и охранным устройствам. Они могли обрабатывать S/MIME за организацию, если на рабочих местах не было PKI, внутренние форматы и сертификаты не сочетались, хранилища меняли письма или политика требовала проверки на границе. Документ не разрешал спор между сквозной и доменной защитой, а давал составные механизмы.

Подпись отправителя связывала отправителя с содержанием. Доменная подпись была подписью по поручению. Перед её созданием доменный подписант обязан был аутентифицировать отправителя: проверить внутреннюю подпись либо воспользоваться механизмом вне S/MIME, а также проверить прочие нужные подписи. При неудаче доменная подпись не должна была появиться.

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

Так разделялись реальное действие, внутреннее решение, протокольное представление и наблюдение. Человек создал текст. Локальная система распознала субъекта. Домен разрешил выпуск. Получатель увидел доменную подпись. Они связаны, но не тождественны.

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

Для различения ролей RFC определил подписанный атрибут SignatureType. Подтверждённая Erratum 3757 добавила пропущенный OID: id-aa-signatureType, 1.2.840.113549.1.9.2.28. Исправление позволяло однозначно распознать тип утверждения, не расширяя его смысл. Одобрение передачи не превращалось в авторство.

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

Вложенные CMS-объекты и списки рассылки показывали важность порядка. Шлюз мог проверить слой, расшифровать следующий, удалить оболочку, сохранить атрибуты, добавить доменную подпись и снова зашифровать. Поэтому «письмо подписано» — слишком грубое описание. Нужны точные байты, тип содержимого, роль подписи, сертификат и положение относительно каждой трансформации.

Современные тому времени RFC по S/MIME, CMS и ESS задавали контейнеры. Позднейшие тексты обновили CMS, S/MIME и PKIX, но не доказывают широкого внедрения RFC 3183 и не меняют его Experimental-статус. Реестр IANA подтверждает выделение идентификатора, а не использование.

Исторический урок — сохранять подлежащее каждого действия. Человек создаёт, домен аутентифицирует и выпускает, рецензент разрешает передачу, орган атрибутов связывает данные, DCA открывает шифр, получатель наблюдает. Зелёный значок без этих субъектов скрывает структуру ответственности.