CA/Browser Forum: корректировка причин отзыва сертификатовMozilla предлагает пересмотреть существующие причины отзывов сертификатов. Причина понятна, УЦ по-разному трактуют, браузеры по-разному интерпретирует одни и те же коды причин отзывов.
Статистика показывает большой разброс: одни УЦ массово используют код "unspecified", другие "superseded", третьи "cessationOfOperation", что и говорит о разной трактовке одного и того же стандарта.
Ключевое предложение - код должен показывать причину отзыва, а не административное действие. Если ключ был скомпрометирован - код должен быть keyCompromise, даже если сертификат в итоге был заменен.
Представитель TWCA сообщил, что Chrome, публично заявил - отзывы сертификатов добавляются в CRLSet на основе указанного кода причины (keyCompromise или privilegeWithdrawn). Однако, согласно официальной документации, в CRLSet сейчас попадают только keyCompromise, но не privilegeWithdrawn.
В любом случае это означает, что неправильный выбор УЦ кода отщыва влияет на пользователей, т.к. браузер может продолжать принимать скомпрометированный сертификат, если УЦ поставил не тот код. Firefox через механизм CRLite также пытается разделять причины отзывов, но когда семантика кодов размыта - эффективность таких механизмов падает.
Предлагается поэтапный план:
Этап 1 - пересмотр раздела 4.9.1.1 (обстоятельства, требующие отзыва):
🔹установить иерархию, чтобы конкретная причина имеет приоритет над общей
🔹убрать дублирования и пересекающиеся формулировки 🔹чётко разграничить: ключевая безопасность, валидация, авторизация, техническое соответствие
🔹ввести дерево решений для аудиторов и операторов УЦ
🔹пересмотреть, вписываются ли 24-часовые и 5-дневные сроки в новую семантику
🔹определить, как быть с требованиями CP/CPS, которые строже BR - считать ли их нарушением BR или выделять отдельно.
Этап 2 - пересмотр раздела 7.2.2
/RFC 5280 (сопоставление с кодами CRL):
🔹сделать использование кодов единообразным для всех УЦ
🔹пересмотреть устаревшие коды (holdInstruction, removeFromCRL)
🔹чётко определить, когда использовать superseded (только для плановой замены, а не для компрометации)
🔹обсудить возможность изменения RFC 5280 (это более масштабная задача ведь текущие определения не работают)
Как обычно, вопросов много:
1. Как быть с выбором кода неопытным оператором, если он выбирает "на глаз"?
2. Должен ли УЦ проверять обстоятельства или достаточно заявления пользователя?
3. Как УЦ должен проверять причины, заявленные пользователем? Как независимо подтвердить прекращение деятельности?
4. Должен ли УЦ изменить код, если его анализ показывает другую причину?
5. Не пора ли менять RFC 5280, если существующие коды не соответствуют современным реалиям?
"Об ЭП и УЦ"
