Запросы на выпуск / перевыпуск сертификатов могут обрабатываться неопределенно долго. Поэтому в ответах на запросы возвращается reqId -- идентификатор запроса (билет), предъявив который позже можно получить нужный сертификат.
В BPKI закреплена следующая логика:
В результате обработки запроса может возвращаться как билет, так и собственно сертификат (если УЦ успевает его сформировать онлайн).
Билет reqId отправляется на специальный узел retrieve, общий для процессов Enroll, Spawn, Reenroll.
Каждый из двух пунктов дискуссионен. Возможны другие варианты.
В результате обработки запроса всегда возвращается билет. Сертификат возвращается только при предъявлении этого билета. При этом процессы становятся более конкретными, повышается модульность.
Билет reqId отправляется на узел процесса, в котором он был получен (enroll, reenroll, spawn).
Чтобы отличить отправку билета от отправки первоначального запроса на тот же узел соответствующий HTTP-заголовок Content-Type принимает специальное значение (например, application/bpki-retrieve-req).
Развилки: 1 vs 3, 2 vs 4.
И еще. В продолжение комментария по #36 следует подумать о продолженной обработке запроса на отзыв (процесс Revoke).
Запросы на выпуск / перевыпуск сертификатов могут обрабатываться неопределенно долго. Поэтому в ответах на запросы возвращается reqId -- идентификатор запроса (билет), предъявив который позже можно получить нужный сертификат.
В BPKI закреплена следующая логика:
Каждый из двух пунктов дискуссионен. Возможны другие варианты.
application/bpki-retrieve-req
).Развилки: 1 vs 3, 2 vs 4.
И еще. В продолжение комментария по #36 следует подумать о продолженной обработке запроса на отзыв (процесс Revoke).