主要领域
安全
在 主要领域 分类下,安全 按主要领域组织行业情报,帮助读者聚焦互联网基础设施、治理、连接市场或数字资本等方向。页面汇集了相关文章、公开证据、机构、公司、人物、区域关联、运营依赖和市场环境,这些内容可能分散在多个分类页面中。页面解释了该领域、可能的行为主体类型、市场或治理背景,以及读者比较信号时应使用的参考来源。运营商、分析师和治理领域的读者可以观察同一领域如何在事件、档案、市场变化、公开来源证据、区域依赖和更长周期的基础设施决策中随时间显现。

案例档案
授权对话仍在待决,并不等于已经拥有 API 权利:GNAP 的继续边界
客户端可以被允许继续一次授权对话,却并未被允许调用它申请的 API。RFC 9635 把这两件事分得很清楚:继续凭据只让某个授权请求在授权服务器上向前推进;资源权利若会出现,也只会在之后、经由另一道验证出现。

IETF
Sean Turner 与那份没有授权证书签发的私钥证明
申请人能用私钥签名,只能说明这把钥匙确实在某个控制面内。申请人是谁、能否使用所填名称、注册机构改了什么、认证机构是否同意签发,仍是四道不能省略的判断。

IETF
Panos Kampanakis 与一场留下三份安全回执的 SSH 会话
一次 SSH 连接可以同时出现三个真实结果:密钥交换采用 ML-KEM 混合方案,服务器仍用另一把主机密钥证明身份,用户随后再凭自己的凭据获得访问权。它们发生在同一条连接里,却不能合并成一张“量子安全”证书。

IETF
Bas Westerbaan:混合 TLS 密钥协商没有让证书变成后量子证书
一次 TLS 1.3 握手可以同时留下两张收据:密钥协商使用 `X25519MLKEM768`,服务器身份仍由传统签名算法证明。前一张收据不否定后一张,却也不能替后一张升级。把两者压成“后量子已完成”,等于丢掉最需要管理的边界。

IETF
Daniel Fett:多因素认证验证了用户,却没有验证二维码的语境
登录页是真的,密码没有泄露,第二个认证因素也由本人完成。攻击者仍然拿到了访问权,因为系统确认了“是谁在点同意”,却没有确认“他在为哪一台设备、哪一项请求点同意”。

案例档案
证书验证了对端,外部 PSK 仍需要保管人:RFC 9973 与 TLS 权责
设备接入记录上可能同时出现三行漂亮的结果:证书链通过、外部 PSK 被选中、TLS Finished 成功。把它们读成“这台设备已被完全信任”,往往是事故的起点。证书回答的是谁能够完成签名验证;PSK 参与的是哪些秘密进入会话密钥;而制造、交付、备份和运维环节中到底还有谁保有那份 PSK,则是另一条尚未回答的控制链。

案例档案
Cookie 随请求而来,却没有替任何人作出决定:RFC 10025 与环境式权限
一笔高风险操作可以同时具备看似无可挑剔的条件:浏览器走了 HTTPS,请求带着正确的 Cookie,服务器查到了一个仍存在的会话,并返回成功。这个组合仍不能回答:是谁促成了此刻的请求,服务端是否仍接受这段会话,该操作是否获得当前授权,以及最终效果是否真的发生。RFC 10025 规范的是浏览器状态的存取边界,不是把这些问题压缩成一行请求头。

案例档案
密文抵达了密钥,却没有指认发送者:RFC 9180 与 HPKE Base 模式缺失的授权
接收端用正确私钥打开一段 HPKE 密文,只能说明一项受限的密码学事实;它不能自行说明是谁发出、为何当时有效、外层请求代表什么,或系统是否应当据此行动。RFC 9180 把这些责任留给采用 HPKE 的应用,而不是假装由一次解密替代。

案例档案
发送方标了优先级,接收设备仍须决定是否执行:RFC 9993 与触觉渲染权限
RTP 载荷里的 Layer 可以告诉接收方:发送端认为这一触觉单元对体验更重要。它不能告诉接收方:这位用户现在适合感受它、这个致动器仍在安全范围内,或本地的急停是否已经切断输出。优先级是媒体排序,不是越过本地安全边界的权力。

案例档案
发现失败,不等于获准发送原文:RFC 9991 与 DMARC 取证披露边界
邮件系统可以准确发现一封信的 DMARC 对齐失败,却没有因此自动获得把信件正文、收件人和转发路径交给域名所有者的权力。RFC 9991 建立了细粒度失败报告的共同格式,也把最重要的一步留在接收方:先决定哪些证据可以离开自己的边界。

IETF
Russ Housley 与证书能够点名、却无法造出唯一性的 MAC 地址
证书可以精确保存六个或八个八位组,却不会因此长出一双观察网络现场的眼睛。地址从哪里来、此刻落在哪个接口、谁看见了它、谁允许它通行,仍是四个不同问题。

IETF
Aaron Parecki 与阻止令牌窃取却不能阻止客户端劫持的 BFF
把 OAuth 令牌移出浏览器 JavaScript,能真正切断凭据外带与独立滥用;但它不会替用户辨认哪一段同源代码怀有恶意。RFC 10017 把这条剩余边界写得很清楚:攻击者拿不到令牌,仍可能借活动会话让 BFF 替它完成请求。

IETF
Hannes Tschofenig:组件权威标识不是令牌签名者
同一个远程证明包里,可以同时出现组件签名者的密钥标识与外层 EAT 的签名;两者都有效,也不代表两者来自同一主体。RFC 10013 的价值,不是再增加一个“可信”标签,而是阻止系统把不同主体的声明压成一个绿色结果。

案例档案
信封标明了证据,却没有绑定设备:RFC 9999 与证明集合中的权限边界
一台服务器可以把主处理器、SmartNIC 与 GPU 的三份签名报告装进同一个整齐的集合。类型都能识别、签名都能验证、解析器也没有报错,仍然不能证明三份报告属于眼前这台设备、同一次会话和同一条受保护的历史。RFC 9999 解决的是可携带性;它也清楚划出了可携带性不能替代的判断。

案例档案
请求签名没坏,证书却可以变:RFC 10002 如何拆开 CMC 的证明与修改权
证书申请系统最危险的误报,往往不是“签名失败”,而是把一串不同主体作出的决定压缩成“已验证”。RFC 10002 展示了另一种更诚实的结构:终端实体保护原始请求,RA 见证身份或密钥占有并在外层提出修改,CA 再依据自己的策略决定最终签发什么。完整性仍在,权力却可能已经换手。

案例档案
令牌从未进入 JavaScript,指令却照样执行:RFC 10017 与浏览器 OAuth 的权限边界
把 OAuth 令牌锁在服务端,能堵住一批真实而严重的攻击,但不能替用户判断浏览器里发出的每一条指令。RFC 10017 的关键价值,正在于把“凭据没有泄露”和“这次操作获得授权”重新拆成两件事。

案例档案
两个算法没有形成两个故障域:RFC 10024 的随机数边界
一条 TLS 连接可以在协议上完整协商 X25519 与 ML-KEM 的混合组,同时在运行上把两者交给同一个失效中的随机数发生器。RFC 10024 分散的是密码学假设;真正的部署还必须证明,组件之间没有被一个共同根重新绑在一起。

案例档案
启动测量通过了,服务器的权限仍须另行决定
RFC 10013 为“被测组件”规定了可在 EAT 中交换的身份与取值格式。它让证据能够跨系统流动,却没有把一次摘要匹配扩大成设备可信、资产归属或访问授权。

案例档案
手机确认了人,却没确认那台设备:RFC 10027 揭示的跨设备授权断层
手机上的网址是真的,通行密钥是真的,批准动作也是真的。可访问权最后落到哪台设备,仍可能是假的。RFC 10027 处理的不是一次普通“扫码诈骗”,而是一种更难察觉的权力错配:用户在可信设备上证明了自己,却替未经认证的发起端完成了授权。

报道
ARIN 已接纳非人工服务账户,现行指南却仍要求使用个人邮箱
7 月底,ARIN 把一个“不能注册”的技术限制改成了“可以接纳”的产品状态。对需要自动维护登记数据的网络运营者而言,这是实质进展。但注册后的责任链仍只能从旧说明里拼凑:账户指南说所有账户都应使用个人邮箱,MFA 问答说账户不能共享,API 密钥页面则说密钥不会自行到期、权限来自所关联的 POC。新主体已经进入系统,公开操作规则却还没有说明这台“机器”由谁负责、如何交接以及怎样彻底退出。
