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

Tue May 17 12:01:19 MSK 2022

День добрый.

Только сел писать свою версию, получил письмо Андрея Константиновича.
По сему сначала короткий комментарий к нему:
Идея промежуточного СА как раз пересекается с "параллельным" СА, о котором
я говорил ранее.

Теперь вернусь к тому, что я хотел написать сам.

0) По поводу:

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

Я опирался на фразу:

*>Андрей Константинович, вы так говорите, как будто в RDIG есть
деньги>и/или крайняя заинтересованность каких-то входящих в RDIG
организаций>их находить для развития и поддержания RDIG.  Я боюсь, что это
далеко>не так.  Поэтому "ставка с определённым финансированием", а тем*
*>более на отдел, -- это мечты*

И прочие предыдущие "денег нет, но вы держитесь".

Хотя тут есть некая подмена понятий RIDG/НИЦ-КИ.. И прекрасно, если я
ошибался, и что-то где-то таки есть, или по крайней мере, если не деньги,
то силы. Тогда таки можно и чуть детальней

1) Общие соображения:
Привязка администратора к имени хоста и подтверждение прав пользователя на
получение-продление тех или иных сертификатов, а также сертификат именно
для этого хоста -  это исключительно уровень RA. По сему поднимать это на
уровень выше никакого смысла нет. Делать какую-то унифицированную  систему
для всех организаций тоже смысла не вижу. Привязку пользовательского DN к
хосту можно делать в рамках WLCG или EGI, т.е. на уровне GOCDB, но RDIG-CA
охватывает несколько большие множество возможных пользователей:

The person certificates may be used for user authentication and data
integrity
checking in various applications: Globus, LCG, gLite and similar GRID
middle-
ware, electronic mail, Web server access, etc

Посему я бы не рассматривал данную привязку в рамках структуры RDIG-CA.

2)

>* Но сама по себе автоматизация имеет место быть.

"Автоматизация" -- это полностью автоматическая выдача сертификата
после его одобрения RA?*

Да, именно это я и имел ввиду. Именно этот момент мне и не понятен. Если  у
нас до уровня подписания СА уже одобренного сертификата всё идёт
автоматически (в обычной ситуации). И сама по себе возможность
автоматической подписи документально не запрещена, исходя из того, что церн
полностью автоматически генерирует сертификаты.  Да, перечислены некоторые
возможные проблемы, такие, как повторные запросы и незашифрованные
сертификаты RA (последнее не совсем ясно, но думаю тоже доступно
автоматической проверке). По повторным сертификатам  - ввести проверку,
если существует сертификат на этот DN, которому осталось жить более месяца
- откладывать до индивидуального рассмотрения. Это сократит а) время выдачи
сертификата. 2) Занятость одного конкретного СА.
Если Вы, Евгений Александрович, считаете, что эта предлагаемая "новация"
есть небезопасный online-сервис:

*Если у нас будет online-сервис (в котором для создания
и хранения корневого /или промежуточного/ сертификата УЦ
используются аппаратные средства), то сразу возникают вопросы,
связанные с защитой такого online-сервиса.  Вопросов --
много, не возьмусь их решать:........
 - если думать об УЦ, который почему-то хотят подломить и люди,
   заинтересованные в этом, минимально оснащены мозгом
   и/или деньгами, -- не возьмусь.  Поскольку у меня нет
   физических средств (даже обнаружив и установив "личности"
   нападающих) обеспечить их привлечение к ответственности
   (вплоть до ликвидации вообще)

*То именно про это я и говорю: "средств, которые НИЦ-КИ не предоставляет".

3)

Так же была моя идея создание дублирующего CA, в случае, если первый
работает в исключительно ручном режиме, причём руками только одного
человека. Но тут даже не перешли к техническому обсуждению такого
варианта (кроме предложения Андрея Константиновича час назад) ,  так
как никто не высказал достаточную заинтересованность.

4)
Варианты же апдэйта  интерфейса, они интересны, возможно, но не столь
срочно ожидаемы.

Best Regards,
Andrey Zarochentsev
---------------------------------------
Всего доброго,
С уважением,
Андрей Зароченцев.

вт, 17 мая 2022 г. в 10:19, Andrey Kiryanov <Kiryanov_AK at pnpi.nrcki.ru>:

> Евгений, добрый день.
>
> Раз уж пошла речь про будущие функции CA, хотя бы теоретически, у меня
> есть насущный вопрос:
>
> [вступление] У нас активно используется FreeIPA для управления
> пользователями, узлами, аутентификацией, правами доступа и т.д. Она
> умеет пользователям и узлам выдавать сертификаты X.509. Обычно она это
> делает, генеря свой собственный корневой CA, но ей можно подсунуть и
> промежуточный.
>
> [сам вопрос] рассматривался ли когда-либо и в принципе возможен ли
> выпуск в рамках RDIG CA промежуточных CA (хотя бы для внутри НИЦ КИ и
> ОИЯИ, где есть военные по периметру ;), которые можно было бы
> использовать для локальной автоматизации без необходимости обращения к
> внешним CA? Фактически, это тот же сертификат, только с флагом
> "CA:TRUE", и при возникновении вопросов его так же можно отозвать через
> CRL, отозвав при этом и всё то, что им подписано, без ущерба для других.
>
> On 16.05.2022 22:29, Eygene Ryabinkin wrote:
> > Андрей Константинович,
> >
> > это, на мой вкус, слишком сильное упрощение ситуации.  Детали --
> > важны, без них выйдет ничего.
> >
> > 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.
>
> --
> С уважением,
>         Андрей Кирьянов.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://theory.sinp.msu.ru/pipermail/ru_ngi/attachments/20220517/040b89af/attachment-0001.htm>