| ||||
| ||||
| По документации получается, что все OCSP-сервера жёстко привязаны к "своим" удостоверяющим центрам. А почему нет возможности некоего "электронного нотариуса": когда из сертификата извлекается CRL, скачивается, проверяется валидность и даётся ответ? | ||||
| Ответы: | ||||
| ||||
| Уважаемый Сергей. "Жесткая привязка" обусловлена не столько конкретным техрешением, сколько организационно-правовой составляющей, позволяющей ответить на вопросы: а почему данный OCSP или нотариат вообще взялся за проверку сертификата из чужого домена, почему следует доверять результатам такой проверки и т.п. И процедура привязки будет всегда присутствовать, например, http://www.ttp-pki.ru/report.html в виде "Типового соглашения ..." Ну и далее с точки зрения техники происходит именно то о чем вы пишете, Службой получается сертификат, добывается другая дополнительная информация (теже CRL например) и формируется квитанция-ответ. | ||||
| ||||
| Тем не менее существующие конфигурации OCSP-сервера от крипто про не позволяют осуществлять нотариат для нескольких УЦ в режиме "онлайн", поскольку организовать свовременную доставку CRL в пределы UNC и файловой системы OCSP-сервера не всегда представляется возможным. Например, хотим устроить в корпоративной информационной системе свой OCSP-сервер, но эта инфомрационная система до УЦ доступа не имеет, только до CRL. Для нас это достаточная юридическая сила и мы можем это закрепить в регламенте информационной системы. Или я переворачиваю всё с ног на голову? | ||||
| ||||
| Если сервер OCSP будет получать информацию из CRL, не проще ли вообще без него обойтись и проверять статус непосредственно по CRL? Смысл OCSP как раз в том, что статус берется из базы, а не из CRL, который на момент проверки уже может устареть. | ||||
| ||||
| Нужно обдумать, но мне кажется, что проще в реализации использовать только OCSP-сервер, чтобы ПО не ведало о том, каким образом проверен сертификат. Или это так важно с юридической точки? А если временно некоторые из УЦ не доступны напрямую (например, до решения организационно-технических вопросов, проблемы с прямой связью), то можно было бы возвращать их статус с использованием данных CRL. Да, еще одно применение. Внутренняя закрытая корпоративная система. А доступ в интернет имеет только OCSP-сервер, который и проверяет статусы. А остальные в безопасности. Ведь никогда не знаешь, какие CRL могут понадобиться и откуда. Фильтрами такое закрыть хотя и можно, но сложно. | ||||
| ||||
| 1. OCSP конечно может (но не обязан)цепляться к базе, конечно работая с базой все произойдет быстрее. 2. По поводу ситуации, когда сертификат отозван, но регулярный СОС еще не издан. Это вызвано исключительно отсутствием поддержки delta-CRL. Но и это разруливается - например в тех же бумагах ETSI есть понятие грейс-периода. 3. Видимо Сергею хочется иметь что то меморабельное о факте проверки, именно для этого он и пытается использовать некий внешний сервис. Таких протоколов на самом деле два - OCSP и функция VPKC из состава DVCS. 4. А далее Сергею видимо придется накладывать получение желаемого результата и конкретные технические решения с учетом реальной топологии - это кроме него никто внешний не сделает :-) | ||||
| ||||
| По хорошему, в сертификате должна быть информация о том как его проверить. Если есть адрес OCSP - ПО проверяет по OCSP, если есть адрес CDP - по CRL. "Внутренняя закрытая корпоративная система. А доступ в интернет имеет только OCSP-сервер, который и проверяет статусы. А остальные в безопасности." В составе ПАК "КриптоПро УЦ" есть задача по переносу CRL. Она как раз умеет забирать CRL с внешнего ресурса и публиковать его на внутренний, в т.ч. в Active Directory. "Это вызвано исключительно отсутствием поддержки delta-CRL." А как delta CRL решит проблему с grace периодом? Публикацией после каждого отзыва? | ||||
| ||||
| Про пометку в сертификате о сервере OCSP согласен. А про перенос: вот именно, что задача переноса должна инициироваться тем, кто публикует CRL, а не периодически сервером OCSP, поэтому считаю данное регламентное задание в контексте указанного применения практически бессмысленной | ||||
| ||||
| Для Кирилла: 1. Без поддержки дельт , реакция системы на изменение статуса определяется периодом публикования регулярного СОС. Поскольку публикация дельты весч почти мгновенная, то и в базу сертификатов нет нужды лазить. В вашем решении OCSP, вы видимо данные о статусе черпаете прямо из базы, но тут есть некая засада, насколько я помню (могу и ошибиться) OCSP квиток может содержать ссылку на СОС которого еще нет. 2. Грейс период расшивает ситуацию, когда запрос на статус мог оказаться в периоде (определяемым организационно-техническими процедурами управления статуса в конкретном УЦ) обработки запроса на изменение статуса. И все это конечно связано со временем реакции системы на изменение статуса сертификата. Для иллюстрации всег сказанного можно просто нарисовать график имея исходные времена, например, грейс период - 1 час, периодичность выпуска регулярного СОС - 1 день. И посмотрите что получится с дельтами и без дельт. | ||||
| ||||
| "задача переноса должна инициироваться тем, кто публикует CRL" И им безусловно тоже, если ЦС находится где-то в защищенной зоне а CRL должен лежать в общем доступе. Но если CRL от внешнего ЦС нужен какой-то закрытой системе - то забирать его она будет сама, сам ЦС то туда доступа не имеет. Муругов Сергей Михайлович: конечно, это все так - ЦС который умеет публиковать дельты безусловно имеет преимущество. Но для онлайн проверки статуса все-таки удобнее OCSP. Вообще, если OCSP есть - с CRL можно не заморачиваться, выпускать их раз в год например при смене ключей. | ||||
| ||||
| Кирилл, я с вами целиком согласен ! OCSP именно для этого и придумали , чтобы упростить (и упорядочить) всем жизнь, Единственное (гложет червь сомнений) надо бы открыть RFC по OCSP и посмотреть квиток должен/может ссылаться на актуальный СОС. Если это так, то OCSP не поможет улучшить реакцию системы, поскольку все равно придется создавать СОС (раз на него есть ссылка в квитке, ну а раз создали, то почему бы и не опубликовать) и СОС с регулярностью раз в год не прокатит :-) | ||||
| ||||
| Может, но не должен. RFC 2560 4.4.2 It may be desirable for the OCSP responder to indicate the CRL on which a revoked or onHold certificate is found. Также CRL может использоваться для проверки сертификата самой службы. | ||||
Веревкин Сергей