[Ru_ngi] Варианты развития центра GRID аутентификации.

[Eygene Ryabinkin]

Андрей Константинович,

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

Andrey Zarochentsev wrote at around Mon, May 16, 2022 at 08:34:14PM +0300:
> 2) Возможный апгрэйд/автоматизация/оптимизация существующей схемы требует
> средств, которые НИЦ-КИ не предоставляет (хотя мне казалось я слышал
> какие-то слова с год назад об RDIG2. Но про деньги я тогда тоже ничего не
> услышал).

Я совсем не представляю, откуда взялось суждение "НИЦ-КИ
не предоставляет средств".  Потому что не могу понять, с какой
стати НИЦ-КИ должен это делать.  Так что ваш парафраз в этом месте,
боюсь, совсем не точен.

И я не понимаю, что именно подразумевается под "возможный апгрэйд"
(поэтому мне дополнительно неясно долженствование НИЦ-КИ
в предоставлении средств: не только "с какой стати", но и
"для чего именно"): я постарался объяснить, почему всё устроено так,
как устроено и что мешает (не "не позволяет", но мешает) сделать
сильно иначе.

Поясните, пожалуйста, что именно вы имеете в виду под этим, какие
шаги?  И если вдруг я в письме
  https://theory.sinp.msu.ru/pipermail/ru_ngi/2022-May/000085.html
поставил под сомнение правильность каких-то из этих шагов, не могли
бы вы объяснить,

 - ошибаюсь ли я в своей оценке правильности (если да, то почему);

 - такие шаги нужны no matter what (и почему);

 - что-то ещё (что именно/почему), что заставляет вас всё же включать
   такие шаги в "возможный апгрэйд".

> Далее технические детали о возможном/невозможном переводе на частичную
> автоматизацию работы CA - тут Евгений Александрович уточнил ряд нюансов, но
> общие возражения относятся скорее к пункту 2.

Я не понимаю этого параграфа вообще, извините.  Что такое "общие
возражения относятся скорее к пункту 2"?  Чьи/какие возражения?
К пункту 2 какого именно письма, на которое я отвечаю сейчас?

Что есть "нюансы"?  Если нюансами названо то, что начинается
с параграфа
  https://theory.sinp.msu.ru/pipermail/ru_ngi/2022-May/000085.html
{{{
А ещё -- чтобы инициировать процедуру подписания новых
сертификатов, CRL и отзыва сертификатов на offline-машине.
...
}}}
то я бы не рассматривал это как нюансы (кроме случая, когда
соответствующая функциональность нужна no matter what; о чём
бы, как я просил выше, хотелось понимать особенно подробно).
Это, повторюсь, объяснения "почему так и почему иначе сделать
преставляется затруднительным; не полностью невозможным,
но затруднительным".

> Моё скромное мнение, что новости о безвременном уходе аутентификации
> посредством x509 несколько преждевременны. И для нужд NICA, таки
> понадобится структура типа RIDG-CA.  Но понятно это будет через некоторое
> время, через которое я и предлагаю вернуться к этой теме.

А давайте, раз вы начали обсуждать, то закончим не вот таким
"кратким пересказом" и "понятно будет через некоторое время",
а чем-то более конкретным?  Скажем, требованиями к тому, что надо
до/переделать в RDIG CA.

У меня в списке вот что (в порядке приоритета):

 - сделать настраиваемыми указание subjectAlternativeName
   при создании запроса;

 - поднять рабочий (а не адски экспериментальный и поэтому
   заброшенный) OCSP;

 - попробовать приспособить интерфейсы RDIG CA для работы
   с acme-client, который в последнее время довольно
   распространён (для выдачи сертификатов узлов);  там придётся
   понимать, как расширить/приспособить практики подтверждения
   владения доменным именем узла до уровня верификации, который
   сейчас есть в RDIG CA;

 - попробовать сделать привязку администраторов узлов/сервисов,
   имеющих пользовательские X.509-сертификаты, к своим узлам/сервисам;
   с возможностью иметь несколько администраторов и наделением их
   правами добавлять/удалять из своих рядов коллег.  Т.е., скажем,
   у cow.grid.kiae.ru будет сертификат, который будет привязан
   к DN некоторых граждан из КИ.  И, если тут появляется/исчезает
   администратор, то текущий пул может в список "ответственных"
   добавлять/удалять соответствующие DN.  Это всё, в моей идее
   происходящего, должно

   а. давать возможность администраторам видеть список "своих"
      сертификатов узлов, их близость к истечению и т.п.;

   б. давать (при соответствующем изменении CP/CPS и консультации
      с EUGridPMA) упрощённую процедуру получения нового сертификата
      узла, когда уже есть истекающий (т.е. обновления сертификата).

 - попробовать сделать (для сертификатов пользователей) создание
   запроса прямо через броузер (а не сценарий на shell).  Теоретически,
   не обязательно только сертификатов пользователей, но первые
   кандидатуры на такое -- именно, думаю, они.


Это из видимых "наружу" планов.  Внутренние переделки, думаю,
обсуждать здесь не стоит, ибо их никто (надеюсь) не распознает,
кроме граждан, обслуживающих RDIG CA.
-- 
Eygene Ryabinkin, National Research Centre "Kurchatov Institute"

Always code as if the guy who ends up maintaining your code will be
a violent psychopath who knows where you live.