【每日文稿】2024-12-10
今日共有14篇文稿更新，涉及5个area里的13个WG
ART
mailmaint
- Title: Registration of further IMAP/JMAP keywords and mailbox attribute names
- Authors: Neil Jenkins(neilj@fastmailteam.com), Daniel Eggert(deggert@apple.com)
- Summary: 本文定义了一些由Fastmail和Apple在一段时间内使用的关键词，这些关键词主要用于表示邮件的状态、用户行为等。它还注册了几个IMAP邮箱名称属性，例如Snoozed、Scheduled和Memos。文稿主要介绍了这些关键词和属性的定义、使用场景以及相关的安全性考虑。最后，指出了它们被注册到IMAP/JMAP关键字和邮箱属性注册表中的信息。 总的来说，本文为IMAP/JMAP协议提供了更多的关键词和属性支持，有助于提供更丰富和精准的服务体验。
- Diff: 该文档定义了新的IMAP/JMAP关键字和邮箱属性，并在IANA注册，以避免名称冲突。主要内容包括： 1. 新增了16个IMAP/JMAP关键词，包括$notify、$muted等，以及3个IMAP邮箱属性。 2. 注册了这些关键词到IMAP/JMAP关键字注册表中。 3. 定义了这16个关键词的含义，解释了它们的作用范围。 4. 对这些关键词进行了实施建议，说明如何在客户端或服务器端使用这些关键词。 5. 建议在客户机或服务器上清除这些关键词的状态。 6. 将这些关键词注册到了IMAP/JMAP关键字注册表中，以便后续操作。 7. 完整地遵循了BCP规范中的相关要求，确保了文档的准确性和可移植性。 总的来说，相比于旧版，新版增加了更多的关键词和邮箱属性，且对这些关键词进行了详细解释和指导，有助于更有效的管理和使用这些IMAP/JMAP协议中的关键信息。同时，也保证了这些新添加的信息能够得到适当的维护和更新。
OPS
dnsop
- Title: Parent-side authoritative DNS records for enhanced delegation
- Authors: Peter van Dijk(peter.van.dijk@powerdns.com), Petr Špaček(pspacek@isc.org)
- Summary: 本文提出了一个对现有的DS资源记录类型的扩展，使其可以被用于在父级上发布数据。这个范围包括值43（即DS类型）以及未来可能添加的新类型。新的规则要求解析器知道向父级查询时应询问父级。此外，还定义了如何防止降级攻击，并指出了zone验证和stub resolver变更。 总的来说，本文是关于对现有协议的一个改进，通过为未来的父级发布数据提供更好的支持，使得当前的DNS操作变得更加高效。然而，由于这个新规则的具体细节还在讨论阶段，所以没有具体的实现建议或时间表。
- Diff: 新版本的英文标准文稿主要增加了以下两点： 1. 预留了新的类型范围，这些类型包括在DS类型的处理规则中，并且可以用于增强子区的发布。 2. 指出了这些类型应该被权威服务器在父区侧发布，并且解析器需要知道如何询问父区侧的委托。 相比旧版本，主要有以下区别： 1. 新版定义了一个新的类型范围，而旧版没有。 2. 新版将这些类型与DS类型的行为相匹配，并允许它们在父区内发布。 3. 新版提出了对解析器进行更改以遵循新的行为的要求。 4. 新版引入了一种保护机制来防止降级攻击，即在解析器接收到证明不存在的标识符时使用DNSKEY字段来指示这种可能性。 总的来说，新版更详细地描述了处理过程和行为的变化，从而使得部署和实验更方便。
ippm
- Title: Simple Two-Way Active Measurement Protocol (STAMP) Extension for DSCP and ECN Traversal Measurement
- Authors: Greg White(g.white@cablelabs.com)
- Summary: 本文讨论了简单的双向主动测量协议(STAMP)扩展，允许中间件对两个STAMP主机之间的差分服务代码点(DSCP)字段进行操作，并且可以测量提供基于ECN(优先级标记)字段不同路径的差异流量。该扩展定义了一个新的STAMP TLV（Type 179），用于在传递数据包时记录TCP/UDP头部中的DSCP和ECN信息。这个TLV包括一个RP位来指示转发的路径，以及一个DSCP2位来保存反射器收到的数据包中的DSCP值。反射器接收STAMP测试包并将其复制到反射器中。当它收到反射包后，它将检查接收到的DSCP值与发送的DSCP值是否匹配，如果匹配则使用匹配的DSCP值，否则使用反射器的DSCP值。反射器将保持收到的反射包的信息以便将来分析。 总结来说，该扩展提供了两个方向上的差分服务代码点(DSCP)和ECN标识符的测量能力，有助于隔离ECN访问问题以实施适当的补救措施。同时，该扩展还支持计算具有特定ECN值的路由路径的特性，这对于发现和测量依赖于特定ECN值的流量特征至关重要。
RTG
roll
- Title: Supporting Asymmetric Links in Low Power Networks: AODV-RPL
- Authors: Charles E. Perkins(charliep@computer.org), S.V.R Anand(anand.svr@gmail.com), Satish Anamalamudi(satishnaidu80@gmail.com), Bing (Remy) Liu(remy.liubing@huawei.com)
- Summary: 本文主要介绍了Ad Hoc On-demand Distance Vector Routing（AODV）和Route Discovery Over Partially Storing （AODV-RPL）协议，用于低功耗、有损网络环境中的路由发现。AODV-RPL允许在不存储模式下发现短路径，并特别适用于发现不需要通过根节点或祖先节点的流量。它使用新定义的选项和新的多播组来支持双向不对称链路，并扩展了核心RPL功能以支持双向对称链路。文中还讨论了路由请求生成、接收与转发等操作过程以及各种场景下的操作。
- Diff: 新的标准文档详细描述了Ad Hoc On-demand Distance Vector Routing（AODV）基于RPL协议支持低功率和失联网络中的双向不对称链路路由的机制。 与旧版相比，主要内容有以下几点： 1. 更详细的介绍了AODV-RPL的工作原理，包括建立临时图根节点、形成Paired DODAG以及处理消息的方式等。 2. 引入了AODV-RPL特有的选项，如AODV-RPL RREQ Option用于指示是否需要向目标路由器发起请求；AODV-RPL RREP Option用于指示是否要响应目标路由器发送的信息等。 3. 对AODV-RPL的路由生成过程进行了详细说明，并提供了具体的操作步骤，比如如何接收和处理路由请求消息，以及如何进行路由回复等。 4. 描述了如何使用这些特定的选项来发现不同类型的路由，比如单向或双向不对称链路的路由，源路由或者目的路由等。 5. 提供了一些示例，展示了如何在不同的网络环境中使用这些功能。 总的来说，新的文档更加详尽地解释了AODV-RPL的实现细节，使得读者能够更好地理解和应用这个新型的路由协议。
savnet
- Title: General Source Address Validation Capabilities
- Authors: Mingqing(Michael) Huang(huangmq@mail.zgclab.edu.cn), Weiqiang Cheng(chengweiqiang@chinamobile.com), Dan Li(tolidan@tsinghua.edu.cn), Nan Geng(gengnan@huawei.com), Mingxing Liu(liumx90@gmail.com), Li Chen(lichen@zgclab.edu.cn), Changwang Lin(linchangwang.04414@h3c.com)
- Summary: 是一篇关于源地址验证(SAV)能力的文稿。该文稿主要介绍了四种验证模式：模式1（接口基...，模式4（接口块列表）。这些模式根据应用场景的不同而采取不同的策略，并且可以互斥使用。此外，还讨论了如何生成SAV规则以及相关的安全考虑。 总之，《General SAV Capabilities》是一篇详细介绍SAV能力和相关机制的技术文档，为网络防御提供了重要的参考和指导。
- Diff: 上述新版本的英文标准文稿是关于源地址验证（SAV）能力的一个草案，主要内容有以下几点： 1. 引言：介绍了源地址验证在路由器上的功能和作用。 2. 验证模式：提出了三种不同的验证模式：接口基模式、基于路由列表的接口模式以及基于接口允许/拒绝列表的模式。每种模式都有其适用场景和局限性。 3. 流量处理政策：给出了几种可以应用在已验证包上的流量处理策略，包括允许转发、直接丢弃、速率限制和定向转发等。这些政策可以根据需要灵活调整。 4. 安全考虑：详细讨论了源地址验证生成过程中可能遇到的安全问题，并指出安全措施可以在一定程度上应对这些问题。 5. IANA考虑：草案中未提及与IANA相关的问题。 6. 参考文献：列出了一些支持文档。
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: 本文主要描述了如何在可信执行环境（Trusted Execution Environment，TEE）产生的交易账本上使用可信数据结构验证（Verifiable Data Structure Verification, VDS）来提供更强的证据保证。通过定义新的可靠的数据结构类型，用于COSE签发的密勒树证明，特别是为由可信联盟框架（CCF）生成的交易账本提供增强的耐久性保证。本文还讨论了隐私和安全考虑，并提出了一些建议性的规范建议。 文稿概述了Cose凭证中的CFF加入证明包含的信息、特性以及对验证算法的要求。同时，也讨论了在COSE凭证中添加CCF加入证明时可能需要的一些细节和约束。最后，本文提出了一个标准格式和建议规范，以确保后续的应用程序能够正确处理这些类型的证书。 总的来说，本文旨在提供一种更加可靠的交易账本结构验证方法，从而保护敏感信息并提高系统审计能力。
- Diff: 该文档定义了一个新的可验证数据结构类型用于COSE签发的密置树证明，专为可信执行环境（TEE）产生的交易记录账本（如保密联盟框架，CCF）提供更强的篡改证据保证。与旧版的主要区别在于： 1. 新增加了CCF ledger的Verifiable Data Structure算法。 2. 增加了CCF Ledger Verifiable Data Structure的SHA256值。 3. 提供了CCF Inclusion Proof签名和Inclusion Proof验证算法。 4. 规定了CCF Ledger Verifiable Data Structure和CCF Ledger Verifiable Data Structure的保护和非保护头部信息。 总体而言，相较于旧版，此新版增加了CCF Verifiable Data Structure的支持，并提供了更丰富的功能，包括CCF Inclusion Proof签名和验证算法等，以增强对交易记录账本的安全性和审计能力。
keytrans
- Title: Key Transparency Protocol
- Authors: Brendan McMillion(brendanmcmillion@gmail.com), Felix Linker(linkerfelix@gmail.com)
- Summary: 本文主要介绍了一种名为“透明度树”的协议，用于确保不同用户对同一加密密钥的可见性。这种协议利用了Log和Prefix树的数据结构，并通过提供包括验证、审计等在内的多种功能来实现安全的传输。它使用一种称为“通配符”（Verifiable Random Function）的随机函数来生成密钥值，并在每个版本后将更新插入到一个记录中。当一个用户查看这个记录时，他们可以查询当前版本的值，并通过一系列步骤进行检查以确定该版本是否为正确的版本。 本文还讨论了如何监控和管理透明度树的状态，以及如何选择合适的Ciphersuite。此外，它还提供了关于如何处理不同类型的操作的信息，如搜索、更新和监视。最后，它讨论了与该协议相关的安全性考虑和可能的影响。总的来说，这篇文稿提出了一个既实用又强大的透明度树协议，旨在保护用户的隐私和数据完整性。
lake
- Title: Coordinating the Use of Application Profiles for Ephemeral Diffie-Hellman Over COSE (EDHOC)
- Authors: Marco Tiloca(marco.tiloca@ri.se), Rikard Höglund(rikard.hoglund@ri.se)
- Summary: 是IETF最新发布的一份标准文档，详细介绍了在运行EDHOC协议时如何协调应用层的分组认证信息。主要定义了以下关键概念： 1. 应用层ID：用于标识特定的应用层参数。 2. 应用层对象：定义了EDHOC应用程序所支持的分组认证信息，并提供了用于获取这些信息的方法和条件。 3. 带有标签的链接（web link）：允许通过提供特定参数来查找相关的EDHOC资源。 4. 指定的端点身份类型（endpoint identity type）：用于指定端点的身份类型。 5. 管道（transport）：用于运输EDHOC消息的方式。 6. EDHOC公共服务包（ECSP）：包括一组应用层参数，用于定义EDHOC应用程序的支持。 7. 通用加密库（CBCR）：描述了与EDHOC应用程序有关的一些参数。 8. EDHOC安全考虑：讨论了对EDHOC应用程序的建议安全性措施。 9. IANA注册指南：对于使用IANA注册的媒体类型、CoAP内容格式等进行了说明。 10. 编码规范：规定了EDHOC应用程序层参数应使用的编码方式。 总的来说，该文件定义了一系列用于协调EDHOC应用程序层参数的机制，为实现高效、可靠地利用这些参数奠定了基础。
lamps
- Title: Related Certificates for Use in Multiple Authentications within a Protocol
- Authors: Alison Becker(aebecke@uwe.nsa.gov), Rebecca Guthrie(rmguthr@uwe.nsa.gov), Michael J. Jenkins(mjjenki@cyber.nsa.gov)
- Summary: 本文主要定义了两个新的证书属性：relatedCertRequest和RelatedCertificate，以及它们在多认证协议中的使用。相关证书可以用来表示两个不同的证书是同一个实体的所有权，从而提供更安全的信任机制。此外，还讨论了CA组织可能遇到的一些考虑因素。 文稿首先简要介绍了这个设计的总体流程，包括获取、验证和应用相关信息来创建新的证书。然后详细描述了相关证书扩展（RelatedCertificate）和相关的CSR属性（relatedCertRequest），并说明了如何利用这些信息来创建新的证书。最后，文稿讨论了实现该方法时需要考虑的安全性问题，并提出了相应的建议。 总的来说，本文为实现非复合混合公钥机制提供了新的信任机制，同时也在实践中解决了一些具体的问题和挑战。
- Diff: 本文为一篇新的英文标准文稿，提出了一个名为“Related Certificates”的概念，用于在非复合混合公钥机制下，表示两个X.509（PKIX）实体证书是同一实体拥有。 与旧版不同之处： 1. 更多的使用场景：除了传统的CMS和SMIME协议外，还考虑了TLS和IKEv2等在线协议。 2. 引入了新的CSR和X.509v3相关的证书扩展，如relatedCertRequest、RelatedCertificate和ExtendedKeyUsage。 3. 定义了一个新的认证请求属性，相关证书请求，允许RA验证实体控制私钥，并提供附加保证信息。 4. 规定了端点协议多重认证处理流程，当偏好采用非复合混合认证模式时，由协议自身决定如何处理相关证书的关联性。 总的来说，该标准文稿旨在解决非复合混合公钥机制下，通过多个证书实现多重认证的问题。它提供了附加的实体控制信息，简化了认证过程，并优化了现有技术栈的兼容性。
mls
- Title: Paired MLS - PCS in Limited Modes
- Authors: Elsie Fondevik(elsie.fondevik@kongsberg.com), Britta Hale(britta.hale@nps.edu), Xisen Tian(xisen.tian1@nps.edu)
- Summary: 本文主要讨论了配对消息层安全(Paired Messaging Layer Security, PMLS)的扩展，即提高了针对无法自我更新或更新频率低的设备进行组内通信的安全性。PMLS通过使用密钥分发服务（Key Distribution Service, KDS）和密钥交换协议（Key Agreement Protocol, KAP）来增强安全性。它利用密钥库（Key Store）存储签名校验键，确保只有授权用户才能访问这些资源。同时，PMLS还支持隐藏模式，允许一组成员共享一个签名密钥，从而保护用户的隐私。 PMLS的安全特性包括： 1. 加密传输：防止网络攻击和限制传输的消息。 2. 安全性：确保消息完整性、机密性和不可抵赖性。 3. 防止被恶意设备欺骗：确保只有授权的设备可以参与活动并获取新信息。 4. 透明度：与其他设备保持一致的通讯。 总的来说，PMLS提供了一种提高组内通信安全性的方法，使得在一些情况下无法自我更新或更新频率较低的设备也能参与通信。它为用户提供了一个安全可靠的平台，同时保证了设备之间的交互不会被第三方监视。
- Diff: 该文档详细描述了Paired Messaging Layer Security (MLS) 的扩展，即配对MLS，它允许信任设备更新其他组成员的安全参数。MLS 框架是基于消息层安全（MLS）协议的一个增强版。 与旧版本相比，主要的区别在于： 1. 添加了两种新的操作模式：隐藏模式和常规模式。常规模式下，两个配对设备拥有各自的签名密钥；而隐藏模式下，一个配对设备可以使用另一个配对设备的签名密钥，从而实现隐蔽操作。 2. 引入了共享随机数的概念，并强调其重要性。只有在确保随机数被妥善存储的情况下，才能防止未经授权的第三方篡改通信状态。 3. 提出了附加的安全要求，如加密传输、验证和分发共享随机数的机制等。 总的来说，新版文档对MLS的扩展做了更深入的技术细节说明，并增加了额外的安全性和功能性要求，旨在提升配对MLS的保护能力和透明度。
ohai
- Title: Chunked Oblivious HTTP Messages
- Authors: Tommy Pauly(tpauly@apple.com), Martin Thomson(mt@lowentropy.net)
- Summary: 本文提出了一种新的无泄漏HTTP消息格式，名为chunked OHTTP。该格式允许在传输过程中对请求和响应部分进行加密，并且可以将它们分块处理以提高性能。这种格式可以在客户端和服务器之间使用，以及用于需要隐私保护但又需要逐步处理大文件或慢速接收信息的情况。 chunked OHTTP首先定义了两种媒体类型：message/ohttp-chunked-req（用于发送的分块请求）和message/ohttp-chunked-res（用于响应的分块响应）。这两种媒体类型的编码方式是二进制，允许客户在收到特定长度的子段后继续处理整个消息而不必等待完整数据。 此外，本文还讨论了使用chunked OHTTP可能带来的安全性和便利性问题，包括对客户端来说如何处理未完全接收的消息，以及在处理交互式消息时的风险等。 总之，chunked OHTTP为实现异步传输、节省网络带宽并简化处理复杂消息提供了新的方法。虽然它没有提供前向安全性，但可以与现有协议如Oblivious HTTP结合使用，以满足一些特定应用的需求。
- Diff: 这个新版本的英文标准文稿定义了Oblivious HTTP的变种，允许分段处理请求和响应。这是为了在性能上优化大消息或慢响应的情况下使用。新的编码格式为Chunked OHTTP，并定义了相应的媒体类型。旧版本没有定义这种编码格式，因此新的编码方式是创新性的。 总的来说，这个新版本的主要区别在于引入了支持增量处理的新编码格式，允许通过发送小块数据来提高系统的性能，同时保持安全性。此外，还定义了一些安全考虑，如消息截断、交互性和隐私等，以防止潜在的安全风险。
WIT
avtcore
- Title: Absolute Capture Timestamp RTP header extension
- Authors: Harald T. Alvestrand(harald@alvestrand.no)
- Summary: 这篇文档主要讨论了在多源媒体流传输时提供时间同步的一种机制。这种机制允许接收者通过估计NTP时钟偏移来推断来自捕获系统的NTP时钟，从而实现音频与视频之间的同步。它还描述了一个可能用于简化中间系统和混合器间数据转换的版本，这些系统通常处理不同来源的数据并希望从发送端获取准确的时间信息。 此外，它还提到了如何使用RTCP发送端报告中的RTT值来计算接收端和发送端之间的时钟偏移，并指出在考虑时钟偏差时的一些问题，如不平衡延迟等。最后，文档提出了一个建议的方法来减小网络延迟对音频与视频同步的影响，并强调了保存带宽的重要性以减少由于偶发事件（如跳变）而产生的额外通信。
- Diff: 本文档提供了一个新的RTP头部扩展，名为"绝对捕捉时间(RTP Header Extension for Absolute Capture Time)"，它用于在RTP包中记录媒体帧原始捕获的时间点信息，并允许接收者通过估计中间系统之间的时钟偏移来估算接收时钟相对于发送端时钟的偏移。这是音频视频传输核心维护工作组（AVT）正在考虑的一种技术方案。 与旧版相比，新版本的主要区别在于： 1. 新添加了更详细的数据布局细节，包括额外的字段和编码方式。 2. 增加了对安全性的讨论，强调可能暴露的信息较小，且加密的SSRC不会导致更多信息暴露。 3. 添加了对IANA注册的要求，明确表示如果决定标准化，应进行相应的注册工作。 总的来说，新版本引入了一些增强的安全性和实现上的改进，以提高协议的安全性并更好地适应现实场景的需求。
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. 具体描述了哪些条件可以作为通知的触发因素。 2. 提供了一些实现上的考虑，如如何处理动态的资源状态，以及如何确保服务器不会对某些通知请求做出不响应的回应等。 总的来说，这篇文稿为开发者提供了了解如何使用这些条件属性来定制和配置受限环境下的网络通信的方法。对于那些希望在受限环境下工作的开发者来说，这些属性是一个重要的工具。
- Diff: 该文档主要定义了Conditional Attributes用于控制CoRE观察请求中的通知和同步机制。这些条件可以用来决定如何获取资源的状态更新或满足特定的约束（如最小值、最大值），从而实现对机器设备状态的监控。 相较于旧版本，本文新增了以下几项重要变化： 1. 新增了Conditional Notification Attributes（条件通知属性）和Conditional Control Attributes（条件控制属性）。这些属性提供了更精细的通知和控制能力。 2. 提出了Notification Band（通知带宽）概念，允许在不同时刻不同条件下触发多个通知。例如，在监测温度时，当温度在正常范围内时只需要定期更新；但随着温度偏离正常范围，可能需要频繁更新。 3. 引入了Edge（边）概念，指示客户是否只关注资源状态的上升或下降边缘。这种边缘事件对于一些应用场景来说至关重要。 4. 在Notify（通知）部分，增加了Minimum Period（最小间隔期）、Maximum Period（最大间隔期）、Minimum Evaluation Period（最小评估周期）和Maximum Evaluation Period（最大评估周期）参数，以指导服务器何时进行新的评估。 以上变化使CoRE观察请求的灵活性更强，能更好地应对动态环境下的需求。
Unknown
Unknown
- Title: CoRIM profile for AMD SEV-SNP attestation report
- Authors: Dionna Glaze(dionnaglaze@google.com)
- Summary: 本文是关于AMD Secure Encrypted Virtualization with Secure Nested Pages (SEV-SNP) attestation report的CoRIM标准文档。文中详细介绍了SEV-SNP attestation报告的定义、测量值、证据转换成CoRIM内部表示的方式等细节。同时，也讨论了CoRIM对数据编码的要求和限制，并给出了相关的标签和媒体类型。最后还指出了在SEV-SNP认证过程中可能出现的问题和解决方案。总的来说，文稿提供了一个完整的SEV-SNP认证流程的框架，为后续政策引擎的构建提供了基础。 该标准文档规范了SEV-SNP认证报告的结构、内容以及如何将其转化为CoRIM内部表示的过程，使得开发者能够更方便地处理并评估SEV-SNP认证结果。同时，也指出了认证过程中的常见问题和解决方案，帮助开发者更好地理解SEV-SNP认证体系。对于期望进一步了解SEV-SNP认证相关知识的开发者来说，这篇文档是非常有用的参考资料。
- Diff: 新的文档（draft-deeglaze-amd-sev-snp-corim-profile-02）详细描述了AMD安全加密虚拟化（Secure Encrypted Virtualization, SEV）-安全嵌套页（Secure Nested Page, SNP）认证报告的信息元素，以及如何将这些信息转换为CoMID表示用于评估证据。它定义了AMD SEV-SNP参考值、声明和证据的规范表示，并且扩展了原始CoRIM基线 CDDL中的标记和字段。 与之前的草案相比，该文档的主要区别在于： 1. 新增了支持AMD产品提供SEV-SNP认证报告的能力。 2. 增加了对AMD SEV-SNP环境中特有的特殊标识符和信息元数据的支持。 3. 提供了基于可信任计算组（TCG）标准的增强性能测量功能，例如使用TPM事件日志进行辅助测量。 4. 支持额外的公钥证书类型，以便在不同环境之间共享关键。 5. 实现了针对SEV-SNP验证报告的评估逻辑，并允许用户根据需要添加额外的评估器。 总的来说，新的《远程验证》文档扩展了基础CoRIM CDDL，提供了更多的灵活性和可扩展性，以满足AMD产品提供的SEV-SNP认证报告需求。