Тема
Цифровая идентичность и удостоверения
В фасете «Тема» значение «Цифровая идентичность и удостоверения» объединяет статьи по конкретной теме или предмету наблюдения. Здесь собраны связанные публикации, источники, участники рынка и последствия для инфраструктуры. Страница помогает сравнить повторяющиеся сигналы, затронутые организации, непрерывность услуг, закупки, конкуренцию, соблюдение требований и вопросы стратегического планирования, а также понять, почему тема важна операторам, заказчикам, инвесторам и специалистам по политике.
IETF
Одно письмо получило один статус — но не все его части: RFC 9787
Почтовый интерфейс собирает тело, вложения, пересланные сообщения и криптографические фрагменты в одну страницу. RFC 9787 не считает эту визуальную близость общим контуром защиты. Единая сводка относится только к непрерывным слоям вокруг криптографической нагрузки.
Облачные сервисы: тенденции мира
Orchid Security: остановку ИИ нужно подтвердить результатом
Новые средства контроля идентичностей обещают вмешательство при отклонении агента от поручения. Заказчику важно выяснить, какие полномочия прекращаются, а не только увидеть подтверждение принятой команды.
История
Прежде чем подписывать почту, шлюзу пришлось перестать её переписывать: RFC 2015
Почтовый шлюз мог сохранить для читателя каждую фразу и одновременно уничтожить цифровую подпись. RFC 2015 сделала это противоречие частью PGP/MIME: подписывался не абстрактный смысл письма, а точная MIME-сущность — заголовки содержимого, транспортное кодирование, пробелы и…
IETF
Сервис ответил. Ключ Onion — ещё нет: RFC 9799
Выданный сертификат показывает итог, но скрывает развилку, на которой центр сертификации выбрал источник CAA. RFC 9799 допускает два пути — зашифрованный дескриптор и подписанный набор внутри ACME — и одновременно требует отдельного доказательства владения ключом, породившим имя…
История
RFC 1991: сообщение расшифровано, но границы доказательства остались
В старом PGP-интерфейсе всё могло завершиться успехом: ASCII-оболочка снята, CRC совпал, пакеты разобраны, сеансовый ключ восстановлен, шифртекст открыт, данные распакованы, подпись проверена. Шесть удачных операций легко принять за один окончательный вердикт. RFC 1991 показывает…
История
Сертификат не был хранилищем ключей: границы RFC 1984
В 1996 году спор о сильном шифровании свели к точному вопросу о полномочиях. Государство могло управлять удостоверяющим центром, не получая закрытый ключ гражданина. RFC 1984 отделил публичное подтверждение от секретной возможности действовать и тем самым развёл хранение…
IETF
Восемь подтверждений между запуском идентичности и результатом рабочей нагрузки
Проект WIMSE показывает, как заменить долгоживущие секреты короткими и ограниченными по аудитории учетными данными платформы. Однако более безопасная аутентификация не объединяет доказательства экземпляра, владения ключом, ротации, разрешения, исполнения и результата.
IETF
Jim Schaad и идентификатор ключа, который был лишь подсказкой
Короткая метка помогает быстро открыть нужный ящик, но не гарантирует, что внутри лежит единственный ключ. В COSE это не исключение, а часть модели. Работа Jim Schaad позволяет точно отделить подсказку для поиска от криптографической проверки, личности и полномочий.
IETF
Patrik Fältström и ответ ENUM, который не завершил звонок
Номер разрешился, проверенный DNS-ответ вернул URI, но телефон так и не зазвонил. Работа Patrik Fältström над ENUM особенно полезна тогда, когда эти три факта не превращают в одну отметку об успехе.
IETF
Дэвид Харрингтон и контекст SNMP, который не идентифицировал оператора
Запрос точно указал движок, контекст и объект. Ни одно из этих полей не сообщило, какой человек принял решение об операции. Архитектура SNMP Дэвида Харрингтона сохраняет этот пробел, не превращая техническую координату в вымышленную личность.
IETF
Редакция 36 превращает продление ваучера в решение о контроле без протокола
Новая дата окончания — лишь видимая часть продления ваучера для подключения устройства. В редакции 36 проекта IETF описана содержательная проверка: продолжает ли действовать прежняя связь между pledge, Domain и службой производителя. MASA проверяет новый запрос, доступ к ключу…
IETF
Бернард Абоба и метод EAP, который не предоставил доступ к сети
Учётные данные оказались верными, а метод аутентификации завершился штатно — но контролируемый порт остался закрыт. Работа Бернарда Абобы над EAP объясняет, почему эти два факта не противоречат друг другу.
IETF
Крис Ньюман и защищённый почтовый порт, который не авторизовал пользователя
TLS начался раньше первой почтовой команды, но сервер всё равно запретил адрес отправителя. RFC 8314 Криса Ньюмана показывает, почему защищённый канал, личность сервиса, учётные данные и право на действие нельзя свести к одной отметке.
История
RFC 1964: билет, ответ и полномочие — три разных факта
RFC 1964 описал проводной механизм Kerberos V5 для GSS-API и поместил в аутентификатор сведения о привязке канала, доступных услугах контекста и необязательном делегировании. Такая плотность формата удобна, но опасна для отчётности: наличие билета, флага или защищённого сообщения…
IETF
Делегирование подписал принципал. Ключ агента всё равно связал эмитент
Две корректные подписи в одном токене не обязаны подтверждать одно и то же полномочие. Новая редакция AIC-JWT помещает подписанное принципалом делегирование внутрь токена эмитента и тем самым показывает, кто отвечает за имя агента, а кто — за ключ предъявления.
Истории
RIPE Database 1.124.1 исправила выбор сертификата. Выводу «признаков эксплуатации нет» нужны границы
RIPE NCC обоснованно не стала ждать обычного цикла испытаний, чтобы закрыть сообщённую уязвимость аутентификации. Но после срочного исправления возникает отдельная обязанность: показать, какой период, какие запросы и какая история реестра были проверены перед публичным выводом об…
IETF
Ваучер допуска приходит после раскрытия идентификатора устройства
ELA позволяет строго связать допуск ограниченного устройства с конкретным обменом EDHOC. Но решение появляется только после того, как идентификатор уже передан аутентифицированному участнику V и использован сервером W. Отказ остановит подключение, однако не отменит состоявшееся…
IETF
Nat Sakimura и критический заголовок, который нельзя игнорировать даже при верной подписи
Математическая проверка подписи JWS может завершиться успешно, а сообщение всё равно окажется недействительным. В RFC 7515 для этого существует защищённый параметр `crit`: он перечисляет расширения, которые получатель обязан понимать и обрабатывать. Целостность байтов, понимание…
IETF
Justin Richer и активный токен, который не мог одобрить запрос
Строка `active: true` легко превращается в зелёную галочку для всей операции. Сервер авторизации знает токен, не считает его отозванным и видит, что срок действия не истёк. Но RFC 7662, автором которой указан Justin Richer, отвечает лишь о состоянии токена. Решение по конкретному…
IETF
Rifaat Shekh-Yusef и счётчик nonce, который не нумерует транзакцию
Клиент не получает ответ, запрашивает новый challenge и повторяет действие. Обе проверки HTTP Digest проходят успешно, хотя прикладная операция могла выполниться дважды. Поле `nc` из RFC 7616 под редакцией Rifaat Shekh-Yusef помогает серверу заметить повтор запроса в пределах…