【每日文稿】2024-12-09
今日共有19篇文稿更新，涉及6个area里的15个WG
ART
cbor
- Title: CBOR Extended Diagnostic Notation (EDN)
- Authors: Carsten Bormann(cabo@tzi.org)
- Summary: 这篇文稿主要定义了扩展诊断注释语法（EDN），它是一种数据格式，用于表示文本和字符串。本文定义了EDN的结构、术语、基本功能等，并指出了其应用场景。 主要内容包括： 1. 引言：说明EDN的设计目标和用途，如小代码大小、较小消息大小以及可扩展性。 2. 简介EDN的结构、目的和特点。 3. 应用定向扩展标识符的定义。 4. 表达式约束语法的定义。 5. 安全考虑。 6. 参考文献。 总之，这篇文档提供了EDN的基本定义、实现和标准，为未来的发展提供了一个基础框架。
- Diff: 新的文档（draft-ietf-cbor-edn-literals-14）对旧版的EDN（Extended Diagnostic Notation，扩展诊断注释）进行了整合和升级，并定义了两个新的应用向导扩展：dt和ip。 1. 主要区别： 1) 标准化了EDN，使其与现有的标准JSON兼容性更强，同时增加了对epoch时间、IP地址等数据结构的支持。 2) 增加了对日期时间表示和IP地址表示的支持，使得诊断符号能够更自然地表达这些类型的数据。 3) 改进了编码指示符的处理逻辑，使在不同的编码格式下输出的文本更容易被识别。 4) 增加了更多关于字符串和数值语法的说明，以便开发者更好地理解和使用这个标准。 总的来说，新版文档扩展了EDN的功能，使其能更好的支持实际的应用场景，并且提供了更多的工具互操作性和语言级别的信息。
INT
madinas
- Title: Randomized and Changing MAC Address: Context, Network Impacts, and Use Cases
- Authors: Jerome Henry(jhenry@ieee.org), Yiu Lee(yiu_lee@cable.comcast.com)
- Summary: 本文主要讨论了使用无线网络设备的MAC地址作为身份标识的情况。文稿指出，由于无线网络的特性，即使在物理连接受限的局域网内，一些设备也需要通过MAC地址来确定其通信目的，否则可能导致地址冲突。因此，为防止此类情况的发生，客户操作系统供应商开始实施随机和更改MAC地址（RCM）技术。 然而，这种技术可能会对用户体验造成影响，并可能破坏网络服务的有效性。例如，在某些情况下，设备会继续使用相同的稳定标识符，这将导致MAC地址随机化的效果被抵消。此外，如果多个用户同时实施MAC地址的频繁更改，可能会产生意外的服务中断。 针对这些问题，文中提出了几个解决方案：首先，应制定关于RCM的统一标准，以避免不同网络环境下的混乱；其次，应在各层协议之间建立信任关系，如802.1X、OpenRoaming等；最后，可以采用隐私增强框架，如[IEEE_802E]推荐实践文档中的隐私考虑因素，以及基于安全的最佳实践指南等，来保护用户的个人隐私。
- Diff: 该文档讨论了在Wi-Fi网络中使用随机化和更改MAC地址（RCM）技术的问题。RCM旨在减少通过MAC地址确定设备的意图和活动带来的隐私问题。然而，这种地址变化可能影响用户体验和网络操作效率，并对用户的个人信息产生不利影响。 此外，文档还分析了现有框架，如802.1X与WPA2/WPA3、OpenRoaming等，以及这些框架如何维持用户隐私的同时保留用户体验和网络效率。这些框架的目标是平衡保护用户隐私与提高用户体验之间的权衡。 总的来说，该文档提供了一个全面的视角，从不同角度评估了RCM的影响，并提出了维护用户隐私和体验的建议。它强调了理解和识别不同环境中的信任关系的重要性，并为开发者提供了关于如何管理RCM及其潜在影响的指导。
OPS
ivy
- Title: A YANG Network Data Model of Network Inventory Software Extensions
- Authors: Bo Wu(lana.wubo@huawei.com), Cheng Zhou(zhouchengyjy@chinamobile.com), Qin Wu(bill.wu@huawei.com), Mohamed Boucadair(mohamed.boucadair@orange.com)
- Summary: 本文主要讨论了网络设备及其软件组件在物联网网络中的角色和功能。它定义了一个新的网络设备扩展模型，该模型包含了更多关于软件属性的信息，如软件版本、补丁版本等，并且提供了更详细的安装和激活信息。此外，还定义了更多的非物理网络元素（如软件网络设备）以及与之相关的软件组件属性。文稿还提出了安全考虑，并对IANA注册进行了说明。总之，这个模型为物联网网络管理提供了一种更加全面和精确的方式来收集和分析设备信息。 总结：本文详细介绍了如何构建一个更准确、更完整地描述物联网网络中各种设备和软件组件数据的模型，以支持网络管理和监控。它定义了多种新类型的网络设备和软件组件，并添加了更多关于软件属性的信息，这些都对提高网络安全性至关重要。同时，也对如何保护敏感数据节点提出了一些建议。
opsawg
- Title: A YANG Data Model for Augmenting VPN Service and Network Models with Attachment Circuits
- Authors: Mohamed Boucadair(mohamed.boucadair@orange.com), Richard Roberts(rroberts@juniper.net), Samier Barguil(samir.barguil@gmail.com), Oscar Gonzalez de Dios(oscar.gonzalezdedios@telefonica.com)
- Summary: 该文档定义了一个模块，用于更新现有的服务和网络虚拟私有网络（VPN）模型，并在这些模型中添加信息来绑定特定的服务到附加电路（AC），这些附加电路是在使用AC服务（ietf-ac-svc）和网络模型（ietf-ac-ntw）时创建的。这种模块使得运营商可以分离AC的配置与实际的VPN服务配置。例子包括描述了如何将服务AC引用加入到一个具体的服务网络访问中，以及如何将AC引用从单个VPN实例中分离出来。另外，文档还规定了如何在服务提供商的网络范围内粘贴L2NM或L3NM服务。 总的来说，它提供了一种机制，使运营商能够根据需要管理附加电路，并且当他们请求附加电路时，他们可以从网络控制器那里获得关于附加电路的信息。
- Diff: 在新版本的文档中，主要增加了以下几点： 1. 修订了编辑注，并且删除了相关部分。 2. 增加了定义和说明，如AC、LNW等名词含义。 3. 添加了样例使用案例，用于说明如何将特定的服务绑定到AC上。 4. 在模块树结构图中，加入了关于AC服务与网络模型之间的增强关系。 5. 提供了关于安全考虑的详细信息以及IANA关注点。 总体来说，主要是对文档进行了修改以使其更加完整准确，并提供了更多的示例来帮助理解这些新的数据模型。
RTG
bess
- Title: EVPN Virtual Ethernet Segment
- Authors: Ali Sajassi(sajassi@gmail.com), Patrice Brissette(pbrisset@cisco.com), Rick Schell(richard.schell@verizon.com), John Drake(jdrake@juniper.net), Jorge Rabadan(jorge.rabadan@nokia.com)
- Summary: 本文主要讨论了在以太网隧道(EVPN)和提供商背板以太网隧道(PBB-EVPN)中扩展的概念——虚拟以太网段(virtual Ethernet Segment, vES)。作者讨论了单个归属和多归属vES的区别，并描述了设计指定转发(Designated Forwarder)选举、以太网故障和恢复机制、快速收敛等关键概念。 文中还讨论了如何将传统的物理以太网连接扩展到多个vES，以及如何在访问以太网(MPLS网络)的环境中使用vES来提供附加服务。此外，文稿提出了一个方案，即通过一种称为“颜色”的方法，为每个以太网自动发现（Ethernet Automatic Discovery, Ethernet A-D）路径分配不同的颜色，从而表示它们属于哪个vES。 总的来说，本文提供了在EVPN和PBB-EVPN解决方案中支持vES所需的必要扩展，这些扩展旨在满足以太网服务提供商(SPs)对增强多归属能力的需求。
- Diff: 该文档主要介绍了一种新的概念——虚拟Ethernet Segment（vES），它允许在以太网段（ES）的基础上添加多个实体或服务，如多播域、VLAN等，并定义这些实体或服务为一个整体，形成一个更广泛的网络结构。这种扩展的概念称为虚拟以太网段（vES）。与传统以太网段不同的是，它可以在同一个物理端口上处理来自多个实体的服务。对于单个实体的以太网段，可以使用单一物理端口；而对于多实体的以太网段，则可以通过关联实体的数量来配置不同的操作。 总的来说，这个新版本的主要区别在于引入了vES的概念，并详细描述了如何支持vES在以太网解决方案中的实现。此外，还提出了相应的OAM和故障恢复机制，以及对快速收敛的支持。总的来说，这个新版本提供了更丰富的功能和支持，以满足未来以太网网络的需求。
- Title: BGP Usage for SD-WAN Overlay Networks
- Authors: Linda Dunbar(dunbar.ll@gmail.com), Ali Sajassi(sajassi@gmail.com), John Drake(jdrake@juniper.net), Basil Najem(basil.najem@bell.ca), Susan Hares(skh@ndzh.com)
- Summary: 本文讨论了在大规模软件定义广域网络(SDWAN)覆盖网络中的复杂性,以及不同SD-WAN场景的要求。它展示了如何使用BGP作为控制平面来高效地管理这些网络,而无需手动干预。 主要要求包括支持SD-WAN分段、满足客户服务需求和进行零触点部署。另外，文稿还探讨了各种加密模式（Homogeneous、Differential和PE-based）及其各自的特性，并指出了BGP作为控制平面的优势。 此外，本文提出了SD-WAN转发模型的概念，以及不同的加密方法如何与之相匹配。最后，文稿总结了SD-WAN的管理性和安全性考虑，以及对于未来可能引入的新技术的准备。
- Diff: 本文为一篇关于软件定义广域网（Software Defined Wide Area Network，SD-WAN）网络使用案例和管理复杂性的探索性文档。 主要内容包括： 1. 网络架构：本文探讨了SD-WAN网络的基本结构、关键特征及如何利用BGP控制平面来有效地管理这些大规模的SD-WAN网络。 2. 要求：详细描述了SD-WAN网络的主要需求，如支持分段SD-WAN、零接触配置等，并讨论了不同的SD-WAN场景。 3. 控制平面：BGP作为SD-WAN控制平面的优势在于其在多网络环境下能够高效地管理和协调流量，同时确保安全性和隐私性。 4. 多层SD-WAN：文中讨论了不同类型的SD-WAN部署模式，例如混合SD-WAN、私有VPN边缘SD-WAN等，并分析了它们各自的优缺点。 5. SD-WAN前向模型：阐述了基于IPSec隧道的SD-WAN前向模型，包括启动流程、包走查等步骤。 6. 管理可操作性考虑：讨论了如何确保SD-WAN网络的管理简便性和安全性。 7. 安全考虑：详细介绍了SD-WAN网络的安全措施和技术，以及如何保障网络数据的安全。 8. 概述：最后对本文的核心目标进行了概述，即通过说明BGP控制平面如何管理大规模SD-WAN网络，以实现最小手动干预。 总的来说，与旧版相比，新版更加详尽地介绍了SD-WAN网络的特点及其管理难点，特别是在BGP控制平面的应用方面提供了新的视角。它有助于提升SD-WAN网络的实施效率和管理能力。
bfd
- Title: BFD Encapsulated in Large Packets
- Authors: Jeffrey Haas(jhaas@pfrc.org), Albert Fu(afu14@bloomberg.net)
- Summary: 本文是关于网络管理工作组发布的关于使用大包封装BFD协议的一个草案。主要讨论了在BFD协议中使用大包来检测路径MTU（最大传输单元）的问题。文稿首先介绍了这种机制的背景和需要解决的问题，然后详细阐述了如何实现这个功能以及相关组件的设计。最后对实施和部署考虑、安全性和IANA注册等进行了总结。 总的来说，本文提供了一个用于测试多跳BFD连接MTU的解决方案，旨在帮助开发者和工程师更好地理解和验证网络中的BFD连接。它还定义了相关的YANG模块和组件，并提供了详细的配置指南。
- Diff: 该文档提供了关于在多跳网络环境中使用大包封装的BFD（Bidirectional Forwarding Detection）协议的新建议。 与之前的版本相比，最大的不同在于引入了一个新的BFD特性：BFD Encapsulated in Large Packets（简称BFD-LAP）。这个特性允许在传输层进行额外的填充来携带更多的数据包大小，并且能够通过更小的控制报文来验证路径MTU。此外，还定义了相关的组播、LACP和MPLS配置选项，以及一个统一的配置选项group“bfd-large-common”，使得不同的BFD客户端可以使用相同的参数来支持这一特性。 总的来说，这一版本的主要区别在于引入了一个新的特性——BFD-LAP，以及相应的组播、LACP和MPLS配置选项，从而实现了对大包封装下BFD的支持。这些变化有助于提高多跳网络中的连接可靠性，为用户提供更好的服务体验。
idr
- Title: BGP Dissemination of Flow Specification Rules for Tunneled Traffic
- Authors: Donald E. Eastlake 3rd(d3e3e3@gmail.com), Hao Weiguo(haoweiguo@huawei.com), Shunwan Zhuang(zhuangshunwan@huawei.com), Zhenbin Li(lizhenbin@huawei.com), Rong Gu(gurong_cmcc@outlook.com)
- Summary: (Draft-IETF-IDR-Flowspec-NVO3-21) 是一个关于边路协议(BGP)在网络层可达信息(NLRI)编码格式的补充规范。该规范主要定义了用于匹配多层头部和特定隧道头字段的流规格(TLSF)。它还可以支持对通过隧道传输的数据包进行过滤。 文稿详细介绍了新的流规格结构，包括SNMP的流规格和其适用场景。它还说明了在不同类型的隧道头类型下如何应用不同的规则，以及哪些情况下需要使用内层流规格组件。 此外，文稿讨论了流规格的验证流程，以及在不遵守路由可达性的情况下，如何处理数据包。最后，文稿提到了IANA为流规格设置的SAFI代码点，并指出本文档的作者是独立开发者的列表。
- Diff: 这篇新的标准文档，名为“BGP Tunnel Flowspec”，主要对BGP流量规格（Flowspec）进行了扩展和改进。 主要内容包括： 1. 定义了一个新的SAFI（安全属性标识符），用于标记网络层可达信息（NLRI）。这个SAFI为77，用于表示使用Tunnel Header（隧道头）字段来匹配Tunneled Traffic（通过隧道传输的数据包）。 2. 对Tunnel Header Flowspec进行了重定义，新增了类型1-6的组件，可以用来测试不同的Tunnel Header字段。 3. 增加了具体的Tunnel Types描述，比如VXLAN、VXLAN-GPE、NVGRE等，并对应地添加了相应的组件。 4. 提供了一些通用的安全考虑，如Cookie长度和值的验证等。 5. 对IANA进行了更新，加入了更多的Tunnel Encapsulation Attribute（隧道封装属性）类型。 总的来说，这篇新版本的文档对现有的BGP流量规格进行了更广泛的适应性和灵活性增强，提供了更多元化的Tunnel Header字段支持，以满足不同场景的需求。
- Title: Advertisement of Segment Routing Policies using BGP Link-State
- Authors: Stefano Previdi(stefano.previdi@gmail.com), Ketan Talaulikar(ketant.ietf@gmail.com), Jie Dong(jie.dong@huawei.com), Hannes Gredler(hannes@rtbrick.com), Jeff Tantsura(jefftant.ietf@gmail.com)
- Summary: 本文主要介绍了一种机制，用于在交换机（头端）节点收集并发布交换机上可选路径（SCP）的状态信息。这些状态信息包括各个 SCP 的配置、SID 列表等。 该机制采用 BGP 路由协议来传递这些信息。其中，一个特殊的属性——“SR Policy Candidate Path”（候选路径），被定义为 BGP 路由条目的一部分，用来携带 SR Policy 的状态信息。这种状态信息包含在一个称为“SR Policy Candidate Path”的结构体中，它代表了一个特定的 SCP 的拓扑和状态信息。 此外，还定义了几个相关的 TLV（Type-Length-Value），比如用于报告 SR Policy 名称、候选路径名称、约束信息等。这些 TLV 是通过扩展现有的 BGP 路由条目来实现的，它们承载着 SR Policy 状态信息，并能够提供给外部组件如网络管理系统的全局可见性。 总之，本文提出了一个基于 BGP 协议的机制，可以有效将 SR Policy 状态信息从交换机传播到外部系统，从而支持服务规划和其他功能的优化。
- Diff: 这个新版本的文档是关于在BGP链路状态（BGP-LS）协议中发布段路由政策信息。主要内容有： 1. 新增加了对段路由（SR）政策的描述。 2. 定义了新的TLV格式来携带SR政策的信息。 3. 提供了一种机制让外部组件收集并报告段路由节点的状态信息。 与旧版本的不同之处在于： 1. 新增了对段路由政策的支持，包括SR和SRv6两种类型。 2. 添加了新的TLV格式来携带SR政策的信息。 3. 描述了一个通用的机制让外部组件从端点获取SR政策状态信息，并将这些信息传递给控制器。 总体来说，该文档补充了BGP-SR安全分层（SR-SAFI）和SRv6扩展分层（SRv6-SF）的功能，使它们能够通过BGP-LS协议发布段路由政策信息。
lisp
- Title: LISP Distinguished Name Encoding
- Authors: Dino Farinacci(farinacci@gmail.com), Luigi Iannone(ggx@gigix.net)
- Summary: 本文主要讨论了LISP（Locator/ID分离协议）中使用的“标识名”格式，以及如何使用它来编码特定设备角色、功能或自定义名称。LISP中的EID和RLOC地址可以被编码为标识名，并且这些标识名在不同的场景下具有不同的用途。例如，在一个实施例中，路由器注册其代理Egress隧道路由器的角色到映射系统中，以便吸引外部网络流量。此外，还可以通过标识名驱动端口到端口连接，用于迁移至可靠传输。 文中还提到了关于标识名碰撞的问题，强调了分配和命名的重要性。最后，文稿总结了实践中对于标识名部署经验，包括一些示例和建议，提供了实用的信息给未来的开发者。
- Diff: 本文档主要讨论了LISP（Locator/ID Separation Protocol）中的地址族标识符AFI为17“Distinguished Names”的编码格式。该部分详细介绍了这个新的编码格式及其用途、特性以及使用场景。 相较于旧版标准文档，本新版新增加了以下主要区别： 1. 增加了定义了关于术语和概念的段落。 2. 提供了一个明确的字符串终止字符，用于确定长度信息。 3. 定义了映射系统对Distinguished Name EIDs的查找规则。 4. 引入了例子使用案例来说明如何使用Distinguished Name格式。 5. 对名字碰撞考虑进行了更新。 6. 加入了安全方面的考虑。 7. 重新组织了文档引用列表。 8. 将文档状态从"Work in Progress"改为"Proposed Standard"以反映标准化进展。 9. 添加了示例部署经验，包括在LISP控制平面中的应用。 总的来说，新版标准文档更注重实用性和可扩展性，并增加了更多的细节，使其成为更加全面且易于理解的技术指南。
SEC
cose
- Title: COSE Receipts with CCF
- Authors: Henk Birkholz(henk.birkholz@ietf.contact), Antoine Delignat-Lavaud(antdl@microsoft.com), Cedric Fournet(fournet@microsoft.com), Amaury Chamayou(amaury.chamayou@microsoft.com)
- Summary: 本文提出了一种新的数据结构类型，用于可信执行环境（TEE）生产的交易账目生产系统中记录事务详情的证明。该数据结构定义了Conectional Consortium Framework（CCF）账目的验证数据结构，包含索引化事务信息的二叉树形式，并且能够绑定完整的事务细节、内部业务证据和数据摘要。此外，它还提供了对事务写入行为的完整性保护。 这种数据结构设计旨在增强账目系统中的确信度保证，并提供更强的审计能力。同时，它通过使用可信赖的加密技术来防止篡改，并确保与新状态下的VDS一致性，从而支持可靠的交易处理。 总之，该文稿提出了一个基于可信执行环境的新型账目系统验证数据结构，为提高交易账目系统的安全性和可靠性提供了新的思路。
- Diff: 这篇新版本的英文标准文稿定义了一个新的可验证数据结构类型用于COSE签名树证明（Cose Receipts）, 专门设计用于由可信执行环境（TEE）产生的交易账本（Ledger）。该VDS使用二叉梅尔树存储索引和包含内部信息的新事务，以便在分布式共识无法建立时保留交易记录。同时，它还提供了额外审计功能。 与之前版本不同的是，文中增加了关于CCF（Confidential Consortium Framework）账本的详细描述，并定义了CCF账本中的包括但不限于：内部事务哈希、内部证据、以及数据哈希等组件。此外，文稿还添加了CCF包含凭证（Inclusion Proof）的验证算法。 总体来说，这个新版本引入了对可信执行环境下交易的完整细节的绑定，以及对这些细节进行审计的功能。这将为交易账本提供更强的抗伪造证据保证。
- Title: PQ/T Hybrid KEM: HPKE with JOSE/COSE
- Authors: Tirumaleswar Reddy.K(kondtir@gmail.com), Hannes Tschofenig(Hannes.Tschofenig@gmx.net)
- Summary: 本文提出了一个名为PQ/T Hybrid KEM（公钥封装加密机制）的新协议，该协议利用了传统和量子计算安全算法。它结合了两个或多个KEM算法，并且至少其中一个必须是量子计算安全的。例如，它可以用于使用传统密钥交换算法和量子计算安全算法同时发送密钥。 本文还介绍了两种与量子计算机相关的安全性考虑：在使用量子密钥交换算法时，应确保共享秘密的安全性；并且，在使用量子加密算法时，应该考虑到量子密码分析的可能性。此外，文稿详细描述了如何组合不同的KEM算法以创建混合的KEM，以及如何确保这些组合能够提供足够的保护。 总的来说，本文提出了一种新的混合式KEM协议，可以为用户提供更加灵活和可扩展的加密解决方案。
- Diff: 该标准文档主要提出了一个名为PQ/T Hybrid KEM的机制，它结合了传统和量子计算安全的两种加密技术来提供多算法组合的安全性。这个机制允许用户使用混合公钥交换（HPKE）协议同时支持传统的椭圆曲线公钥加密（EC-PKE）、量子密钥交换（QPKE）以及COSE、JOSE等现代密码协议。 在安全性方面，该文档强调了在合并多个安全算法时实现“混合”特性的重要性，并详细描述了如何确保即使只有一种组件被破坏的情况下，整个密钥交换也能保持安全。此外，文档还要求在对这些机制进行注册时考虑其与其他已有的协议或规范的关系。 总的来说，这个新的标准文档扩展了HPKE协议的能力，使其能够更好地融合量子计算技术和传统公钥加密，从而为用户提供更全面的安全解决方案。
lamps
- Title: X.509 Certificate Extended Key Usage (EKU) for Instant Messaging URIs
- Authors: Rohan Mahy(rohan.ietf@gmail.com)
- Summary: 本文主要介绍了关于IM（即时通讯）系统中的身份证书认证，特别是在使用X.509公钥证书时，提供了一个新的扩展密钥用途ID(id-kp-imUri)，用于证明即时消息客户端的身份。这个ID可以在公钥证书中被包含，并且可以是选择性的或非选择性的。 该文档还详细讨论了实施此扩展密钥用途的安全性考虑，以及在进行注册和管理时需要遵循的一些标准和建议。 此外，本文指出了IANA（国际互联网架构组）在管理有关IMURIS ID的ASN.1模块方面的工作需求，以及在实施此ID的过程中可能遇到的问题和挑战。 最后，作者提到了这篇文稿可能会被提前从标准化文档列表中移除，因为它的目的是作为工作草案而非最终标准。
- Diff: 本文对X.509证书中的Extended Key Usage（ECU）进行了扩展，新增了一个名为id-kp-imUri的ECU，用于证明即时消息客户端的身份。这个ECU可选为关键或非关键。 相比旧版本，主要区别在于： 1. 新版文档添加了关于IM URI的ECU，并定义了其OID和描述，这与旧版相比增加了新的内容。 2. 新版文档明确了ECU的可选性，即用户可以选择是否使用该ECU。 3. 新版文档还更新了作者信息，以及提供了来源链接等参考信息。 总的来说，新版文档在原有基础上增加了关于IM URI的ECU，并更清晰地指出了ECU的选择性，同时提供了一些额外的信息来帮助理解这一特性。
- Title: X.509 Certificate Extended Key Usage (EKU) for Automation
- Authors: Hendrik Brockhaus(hendrik.brockhaus@siemens.com), Dr. David Goltzsche(david.goltzsche@siemens.com)
- Summary: 本文主要讨论了自动化领域中的一组新的扩展密钥使用标识符（Extended Key Usage，Eku），这些标识符用于标识安全相关的功能。本文定义了几个关键的Eku类型，包括一般用途和信任锚配置文件、软件更新包和安全性通信，以确保在工业自动化领域的设备能够安全地进行操作。此外，还对证书的生成和应用进行了详细的解释，以及与认证权威机构的关系，强调了必须遵守规定的组合方式。文稿最后提出了几个注意事项，比如避免滥用特定的Eku组合，并提出了一些可能的安全性和隐私性问题。总之，本文为工业自动化领域提供了新的加密和签名标准，旨在提高系统的安全性。 总结：本文详细介绍了如何在工业自动化环境中使用新的Eku标识符来确保网络安全，并指出了一系列需要注意的问题和潜在的风险。这将有助于推动行业的标准化进程，提升系统整体的安全性。
- Diff: 摘要：RFC 5280 指定了几种扩展密钥使用标识（KeyPurposeIds）用于X.509证书。本文定义了几个通用和信任锚配置文件、软件和更新包签名、以及安全通信的关键用途ID以包含在X.509 v3公钥证书中的Extended Key Usage（Eku）扩展中。Eku扩展可以与证书的Key Usage（Ku）扩展一起使用，该扩展指示可用于证书公开密钥的基本加密操作的有效性集合。 相比旧版文档，新的标准文档： 1. 定义了自动化特定的扩展密钥使用标识（KeyPurposeIds），例如id-kp-configSigning、id-kp-trustanchorSigning、id-kp-updateSigning和id-kp-safetyCommunication，分别用于验证一般目的或信任锚配置文件的签名、验证安全软件或更新包的签名、以及认证通信端点的安全通信。 2. 在证书中包括这些关键用途标识不会排除其他密钥用途标识的使用。 3. 新的规范强调了认证授权机构（CA）应确保正确插入Eku扩展中指定的KeyPurposeIds，并且如果CA知道证书用户必须使用这些密钥用途标识，则应强制它们包含。 4. 新的文本对一些潜在跨协议攻击的防范措施进行了补充说明，如禁止某些组合的KeyPurposeIds的使用，允许或禁止使用Excluded KeyPurposeId和Permitted KeyPurposeId等策略。 5. 对隐私考虑方面也做了相应的补充，即当证书交换为明文形式时，Eku扩展有助于观察者确定其目的是什么；对于由公共认证机构颁发的证书而言，Eku扩展还可以帮助追踪证书的目的。 总的来说，新的标准化文档提供了更全面的保护机制，旨在提高工业自动化系统中基于网络的设备的安全性和互操作性。
suit
- Title: A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest
- Authors: Brendan Moran(brendan.moran.ietf@gmail.com), Hannes Tschofenig(Hannes.Tschofenig@gmx.net), Henk Birkholz(henk.birkholz@ietf.contact), Koen Zandberg(koen@bergzand.net), Øyvind Rønningstad(oyvind.ronningstad@gmail.com)
- Summary: 是关于软件更新系统信息模型（SUIT）的一种格式规范，旨在提供一种标准的方式来存储和传输软件更新数据。该文件详细描述了SUITManifest格式及其组成部分、功能、使用方法等。 文稿首先介绍了SUITManifest格式的基本概念，包括其结构、功能、目标等，并对各种相关的安全措施进行了阐述。其次，讨论了SUITManifest在不同应用场景中的应用，如网络运营商对兼容性的检查、设备运营商对更新的影响分析等。 此外，文稿还提供了SUITManifest创建和处理的相关技术文档，以及相关的安全性考虑。最后，提出了标准化SUITManifest压缩格式的建议，以满足不同需求下的软件更新和管理要求。总的来说，这篇文稿为如何有效管理和保护软件更新数据提供了详细的指南。
- Diff: 上述新版本的英文标准文稿定义了软件更新管理(SUIT)格式及其在互联网物联网(SUIT)Manifest上的应用。它描述了SUITManifest结构、使用场景、设计原则等。与旧版相比，主要区别在于： 1. 增加了新的术语和概念，如SUIT、Payload、Resource、Update等。 2. 提供了一个概览性的SUITManifest概述，介绍了其组成部分和工作原理。 3. 对SUITManifest的各个部分进行了更详细的描述，包括CriticalMetadata、CommonMetadata、CommandSequences等内容。 4. 描述了SUITManifest处理器的行为，以及创建SUITManifest的过程。 5. 规定了SUITDigestContainer的概念，并对SUITManifest的结构进行了详细解释。 总的来说，新版文档更加全面地阐述了SUITManifest的各个方面，为实现SUITManifest提供了更为详尽的信息和支持。
tls
- Title: TLS 1.2 is in Feature Freeze
- Authors: Rich Salz(rsalz@akamai.com), Nimrod Aviram(nimrod.aviram@gmail.com)
- Summary: 本文主要讨论了TLS 1.2的安全性问题以及未来可能面临的风险。由于量子计算技术的发展，RSA、FFDH和ECC等传统加密算法在未来的使用环境中将变得不再安全。因此，需要考虑如何在未来的新版本中保护这些传统加密算法。 此外，为了适应未来的网络环境，还应考虑如何使用新的加密技术和协议来增强安全性。文中提到了几个正在开发的工作组，如TLS工作组（TLSWG）和DTLS工作组（DTLSWG），他们正在研究如何利用量子计算机来提高加密强度，并为过渡到后量子世界做准备。总之，文稿强调了未来可能会面临的挑战，并提出了一些应对策略。
- Diff: 新的版本保留了旧版本的主要观点和定义，并指出了以下关键区别： 1. 对于TLS 1.2而言，不再批准任何新特性（除了紧急安全修复、DTLS除外）。这将限制其扩展性。 2. 现在规定，只有当NIST完成量子计算标准的标准化工作时，才支持使用这些算法或协议ID。 3. 新的规范不适用于DTLS，只对TLS适用。 4. 没有新的加密算法、命名曲线等添加到TLS 1.2，因为它们现在被视为较弱的密钥交换方法。 5. 对于后量子时代，IETF正在积极研究使用PQC进行协议设计，同时考虑使用混合算法和标识符来过渡到这一领域。
uta
- Title: New Protocols Must Require TLS 1.3
- Authors: Rich Salz(rsalz@akamai.com), Nimrod Aviram(nimrod.aviram@gmail.com)
- Summary: 本文讨论了使用TLS的新要求，特别是对于新的加密协议。新要求指出，由于TLS 1.3已经成为广泛使用的标准，并且修复了许多TLS 1.2中的缺陷，因此任何使用TLS的新协议都必须默认支持TLS 1.3。 此外，本文还提出了一个更新版本的建议，即在部署考虑因素上，如果需要的话，可以允许支持TLS 1.2作为额外的选择。但需要注意的是，为了确保安全，应选择TLS 1.3或更晚的版本。 总的来说，该文稿强调了新协议必须默认支持TLS 1.3的原因，特别是在使用TLS进行加密通信的情况下。这有助于防止未来可能出现的安全漏洞和威胁。
- Diff: 摘要： 本文对TLS 1.2和TLS 1.3进行对比分析，并指出：TLS 1.2存在诸多问题，如错误的密钥交换、未被配置的安全性等问题；TLS 1.3则通过加密更多的流量并使用更安全的设计解决了这些问题。 此外，本文指出由于TLS 1.3的广泛使用，因此新的协议必须支持它，而不适用DTLS（任何DTLS版本）。这是为了确保所有的新协议都默认地采用TLS 1.3作为其安全层。然而，这不适用于DTLS。 总的来说，本文的主要区别在于增加了对TLS 1.3的支持要求，而对DTLS的配置没有做相应的变化。
WIT
core
- Title: Conditional Attributes for Constrained RESTful Environments
- Authors: Bill Silverajan(bilhanan.silverajan@tuni.fi), Michael Koster(michaeljohnkoster@gmail.com), Alan Soloway(asoloway@qti.qualcomm.com)
- Summary: 本文是关于CoAP协议中的条件通知和控制属性定义。这些属性允许客户端对资源状态进行细粒度的控制，如接收特定条件下的更新或等待指定的时间间隔后发送更新。这些属性可以通过查询参数传递给服务器，用于观察和配置资源的行为。 主要分为以下几个部分： 1. 引言：描述了条件通知和控制属性的概念以及它们在CoAP协议中的应用。 2. 术语概述：列举了相关的标准和技术术语，为后续的详细解释提供基础。 3. 条件属性定义：介绍了几种条件属性，包括更严格的阈值（c.gt）、较宽松的阈值（c.lt）等，并讨论了如何处理它们以满足不同需求。 4. 实施考虑：提供了使用条件属性时需要考虑的一些实施细节，如最小和最大时间间隔、资源状态的变化幅度等。 5. 安全性考虑：讨论了条件属性在安全方面的应用，特别针对对抗放大攻击的方法。 6. IANA考虑：介绍了新属性的注册流程，确保它们能唯一映射到正确的查询参数名称。 总的来说，文稿重点介绍了条件属性的定义及其应用场景，强调了这些属性对于实现细粒度的状态监控和自适应行为控制的重要性。
- Diff: 上述新版本的英文标准文稿定义了条件通知和控制属性，这些属性用于与CoAP Observe（RFC7641）一起使用，以实现对受限环境中的机器设备的机器数据和机器元数据的RESTful接口。 与旧版相比，新版本的主要区别在于： 1. 支持更多的通知类型：除了传统的Greater Than、Less Than和Change Step之外，还引入了Notification Band、Edge等新的通知条件。 2. 引入了更精细的通知周期控制：可以通过Minimum Period、Maximum Period等参数设置通知的频率和间隔。 3. 强调了客户确认机制：在某些情况下，服务器需要向客户端发送一个确认消息来指示已收到通知，这使得整个过程更加可靠。 4. 更好的错误处理和异常处理：提供了更多关于错误状态码和错误信息的详细描述，以及如何更好地处理各种异常情况。 总体来说，新版本通过增加新的通知条件和更丰富的控制能力，进一步扩展了CoAP Observe的功能，并提升了其性能和可靠性。
httpbis
- Title: Cookies: HTTP State Management Mechanism
- Authors: Steven Bingler(bingler@google.com), Mike West(mkwst@google.com), John Wilander(wilander@apple.com)
- Summary: 本文定义了HTTP Cookie和Set-Cookie头部字段，用于在HTTP服务器上存储状态信息（称为cookies），让服务器能够在客户端维护一个状态性的会话。使用Set-Cookie头字段可以将cookies发送给客户端，并通过客户端返回给服务器。 服务器应遵循与《准一致的规范来生成cookies。用户代理应遵循更宽松的处理规则以最大化兼容性，避免向客户端发送可能无法被其他服务器读取的cookies。 本文概述了一个web服务器如何通过Set-Cookie响应字段发送状态信息到客户端，以及客户端如何通过Cookie请求字段返回这些状态信息给服务器的情况。用户代理应忽略Set-Cookie头字段或根据其cookie策略来处理它们。 本文还讨论了服务器和用户代理之间的角色，以及如何实现这些角色的最佳实践。例如，服务器应该尽量只生产安全的cookies，并且当多个cookies共享相同的名称、路径和域时，应该仅保留一次cookie。 本文还描述了用户的隐私考虑，包括第三者的cookies、cookie政策、用户控制等。此外，还有对安全性考虑，如环境权限、清空text、会话标识符、弱点保密性和完整性等问题。最后，本文还提到了IANA工作表中的cookie字段注册等内容。
- Diff: 本文档定义了HTTP Cookie和Set-Cookie头部字段。这些字段允许HTTP服务器将状态信息（称为cookies）发送给客户端HTTP用户代理，使服务器能够维持在几乎无状态的HTTP协议下的状态性会话。尽管简单的看起来很直观，但cookies有历史上的许多复杂性，例如服务器指示每个cookie的生命周期时向客户端代理发送它，生命周期指明客户端应在何时返回该cookie，以及哪些类型的连接中适用这个cookie。 为了最大范围的互操作性，服务器应遵循Section 4中的推荐行为，即在生成cookies时仅使用当前良好行为模式。而用户代理应实施Section 5中更宽松的处理规则，以最大限度地与现有不遵守良好行为模式的服务器兼容。 与旧版相比，本文的主要区别在于： 1. 使用了新的语法和语义定义，如Set-Cookie和Cookie等头字段的新语法。 2. 引入了一些新的概念，如域匹配、路径匹配、安全属性等。 3. 更详细的描述了各类型接口的差异，以及如何选择正确的实现。 4. 指出了某些现存软件对本文推荐协议的不同解读可能带来的影响。 总的来说，本文旨在提供一个基于实际使用的语法和语义来定义HTTP Cookie和Set-Cookie头部字段的方法，并指导开发者如何根据目标受众选择正确的行为模式。