Перенаправление запросов

[agievich]

В процессах Reenroll и Spawn субъект отправляет УЦ один и тот же запрос: EnvelopedData(SignedData(CSR)), где CSR -- запрос на выпуск сертификата. В первом процессе старый сертификат отзывается, во втором -- нет. Противник может перенаправить запрос с узла /reenroll на узел /spawn и изменить логику поведения УЦ.

Возможны и другие перенаправления. Например, запрос оператора РЦ на Reenroll собственного сертификата не отличается от запроса на выпуск сертификата самому себе в Enroll1.

Общая проблема состоит в том, что нет четкой идентификации типа запроса.

Представляется, что самый простой способ идентификации -- указывать конкретные идентификаторы содержимого в SignedData. Примерный перечень идентификаторов: bpki-id-[название_процесса]-req.

Можно пойти дальше и идентифицировать содержимое SignedData в ответах УЦ. Дополнительный перечень идентификаторов: bpki-id-[название_процесса]-resp.

Обращаю внимание, что если тип содержимого SignedData отличен от стандартного (id-data), то SignedData обязательно содержит два подписанных атрибута: ContentType и MessageDigest. Это следует учесть в спецификации BPKI (раздел CMS).

[mihasK]

да, включение атрибутов в SignedData и в подписанный ответ решит проблему

[agievich]

1. Введены типы содержимого SignedData (запросы Enroll1, Enroll2, Reenroll, Spawn, Setpwd, Revoke и ответ BPKIResp).
2. Тип содержимого EnvelopedData не детализировался. Детализация не имеет криптографического значения, поскольку в конвертованных данных тип содержимого не контролируется.
3. Переписаны demo-скрипты.