<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
    <channel>
        <title>Recent RFCs</title>
        <link>https://www.rfc-editor.org</link>
        <description>Recently published RFCs</description>
        <lastBuildDate>Fri, 24 Jul 2026 16:26:01 GMT</lastBuildDate>
        <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
        <generator>https://www.npmjs.com/package/feed</generator>
        <language>en-us</language>
        <item>
            <title><![CDATA[RFC 10026: Operational Recommendations for DNSSEC Delegation Signer (DS) Automation]]></title>
            <link>https://www.rfc-editor.org/info/rfc10026/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc10026/</guid>
            <pubDate>Thu, 23 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Enabling support for automatic acceptance of DNSSEC Delegation Signer (DS) parameters from the Child DNS operator (via RFCs 7344, 8078, and 9615) requires the Parental Agent, often a registry or registrar, to make a number of technical decisions around acceptance checks, error and success reporting, and multi-party issues such as concurrent updates. This document describes recommendations about how these points are best addressed in practice.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9997: YANG-CBOR: Allocating SID Ranges for Private Enterprise Number (PEN) Holders]]></title>
            <link>https://www.rfc-editor.org/info/rfc9997/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9997/</guid>
            <pubDate>Thu, 23 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[<p>YANG-CBOR (RFC 9254, "Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR)") defines YANG Schema Item iDentifiers (YANG SIDs), globally unique 63-bit unsigned integers used to identify YANG items. RFC 9595 ("YANG Schema Item iDentifier (YANG SID)") defines ways to allocate these SIDs using IANA registries.</p><p>The present specification employs these SID allocation mechanisms to allocate ranges of 100 000 SIDs (representation size 64 bits) to each holder of an IANA Private Enterprise Number (PEN) of a value below 1 000 000. Holders of PENs of values smaller than 100 000 are also allocated ranges of 10 000 SIDs (representation size 32 bits).</p>]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 10004: Certificate Management over CMS (CMC): Compliance Requirements]]></title>
            <link>https://www.rfc-editor.org/info/rfc10004/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc10004/</guid>
            <pubDate>Fri, 17 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[<p>This document provides a set of compliance statements about the Certificate Management over CMS (CMC) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents (RFCs 10002 and 10003). This document provides the information needed to make a compliant version of CMC.</p><p>This document obsoletes RFCs 5274 and 6402.</p>]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 10003: Certificate Management over CMS (CMC): Transport Protocols]]></title>
            <link>https://www.rfc-editor.org/info/rfc10003/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc10003/</guid>
            <pubDate>Fri, 17 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[<p>This document defines a number of transport mechanisms that are used to move Certificate Management over CMS (CMC) messages. The transport mechanisms described in this document are HTTP, file, mail, and TCP.</p><p>This document obsoletes RFCs 5273 and 6402.</p>]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 10002: Certificate Management over CMS (CMC)]]></title>
            <link>https://www.rfc-editor.org/info/rfc10002/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc10002/</guid>
            <pubDate>Fri, 17 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[<p>This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community:</p><p>CMC also requires the use of the transport document (RFC 10003) and the requirements usage document (RFC 10004) along with this document for a full definition.</p><p>This document obsoletes RFCs 5272 and 6402.</p>]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 10015: Deprecating Obsolete Key Exchange Methods in TLS 1.2 and DTLS 1.2]]></title>
            <link>https://www.rfc-editor.org/info/rfc10015/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc10015/</guid>
            <pubDate>Thu, 16 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[<p>For (D)TLS 1.2, this document deprecates the use of two key exchanges, namely Diffie-Hellman (DH) over a finite field and RSA. It also discourages the use of static Elliptic Curve Diffie-Hellman (ECDH) cipher suites.</p><p>These prescriptions apply only to (D)TLS 1.2, since (D)TLS 1.0 and TLS 1.1 are deprecated by RFC 8996 and (D)TLS 1.3 either does not use the affected algorithms or does not share the relevant configuration options. (There is no DTLS version 1.1.)</p><p>This document updates RFCs 4162, 4279, 4346, 4785, 5246, 5288, 5289, 5469, 5487, 5932, 6209, 6347, 6367, 6655, 7905, 8422, and 9325 to either deprecate or discourage the use of cipher suites using the above key exchange methods in (D)TLS 1.2 connections.</p>]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9955: Hybrid Signature Spectrums]]></title>
            <link>https://www.rfc-editor.org/info/rfc9955/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9955/</guid>
            <pubDate>Thu, 16 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[This document describes classification of design goals and security considerations for hybrid digital signature schemes, including proof composability, non-separability of the component signatures given a hybrid signature, backwards and forwards compatibility, hybrid generality, and Simultaneous Verification (SV).]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9852: New Protocols Using TLS Must Require TLS 1.3]]></title>
            <link>https://www.rfc-editor.org/info/rfc9852/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9852/</guid>
            <pubDate>Thu, 16 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[<p>TLS 1.3 is widely used, has had comprehensive security proofs, and improves both security and privacy deficiencies in TLS 1.2. Therefore, new protocols that use TLS must require TLS 1.3. As DTLS 1.3 is not widely available or deployed, this prescription does not pertain to DTLS (in any DTLS version); it pertains to TLS only.</p><p>This document updates RFC 9325. It discusses post-quantum cryptography and the security and privacy improvements in TLS 1.3 as the rationale for the update.</p>]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9973: TLS 1.3 Extension for Using Certificates with an External Pre-Shared Key]]></title>
            <link>https://www.rfc-editor.org/info/rfc9973/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9973/</guid>
            <pubDate>Wed, 15 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[This document specifies a TLS 1.3 extension that allows TLS clients and servers to authenticate with certificates and provide confidentiality based on encryption with a symmetric key from the usual key agreement algorithm and an external pre-shared key (PSK). This Standards Track RFC obsoletes RFC 8773, which was an Experimental RFC.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9954: Hybrid Key Exchange in TLS 1.3]]></title>
            <link>https://www.rfc-editor.org/info/rfc9954/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9954/</guid>
            <pubDate>Wed, 15 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if a way is found to defeat the encryption for all but one of the component algorithms. It is motivated by the transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9933: Carrying SR-Algorithm in Path Computation Element Communication Protocol (PCEP)]]></title>
            <link>https://www.rfc-editor.org/info/rfc9933/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9933/</guid>
            <pubDate>Wed, 15 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) to enhance support for Segment Routing (SR) with a focus on the use of Segment Identifiers (SIDs) and SR-Algorithms in Traffic Engineering (TE). The SR-Algorithm associated with a SID defines the path computation algorithm used by Interior Gateway Protocols (IGPs). It introduces mechanisms for PCEP peers to signal the SR-Algorithm associated with SIDs by encoding this information in Explicit Route Object (ERO) and Record Route Object (RRO) subobjects, enables SR-Algorithm constraints for path computation, and defines new metric types for the METRIC object. This document updates RFC 8664 and RFC 9603 to allow such extensions.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9851: TLS 1.2 is in Feature Freeze]]></title>
            <link>https://www.rfc-editor.org/info/rfc9851/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9851/</guid>
            <pubDate>Wed, 15 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Use of TLS 1.3, which fixes some known deficiencies in TLS 1.2, is growing. This document specifies that no changes will be approved for TLS 1.2 outside of urgent security fixes (as determined by TLS Working Group consensus), new TLS Exporter Labels, and new Application-Layer Protocol Negotiation (ALPN) Protocol IDs. This applies to TLS only; it does not apply to DTLS (in any DTLS version).]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9850: The SSLKEYLOGFILE Format for TLS]]></title>
            <link>https://www.rfc-editor.org/info/rfc9850/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9850/</guid>
            <pubDate>Wed, 15 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[This document describes a format that supports logging information about the secrets used in a TLS connection. Recording secrets to a file in SSLKEYLOGFILE format allows diagnostic and logging tools that use this file to decrypt messages exchanged by TLS endpoints. This format is intended for use in systems where TLS only protects test data.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9999: Remote ATtestation procedureS (RATS) Conceptual Message Wrapper (CMW)]]></title>
            <link>https://www.rfc-editor.org/info/rfc9999/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9999/</guid>
            <pubDate>Tue, 14 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[<p>The conceptual messages introduced by the Remote ATtestation procedureS (RATS) architecture (RFC 9334) are protocol-agnostic data units that are conveyed between RATS roles during RATS interactions. Conceptual messages describe the meaning and function of such data units within RATS data flows without specifying a wire format, encoding, transport mechanism, or processing details. The initial set of conceptual messages is defined in Section 8 of RFC 9334 and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies.</p><p>This document introduces the Conceptual Message Wrapper (CMW) that provides a common structure to encapsulate these messages. It defines a dedicated Concise Binary Object Representation (CBOR) tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension.</p><p>Together, these mechanisms allow CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts such as X.509 certificates. Additionally, this document defines media types and CoAP Content-Formats that may be used to identify CMWs when transported over protocols such as HTTP, MIME, and CoAP.</p><p>The goal is to improve the interoperability and flexibility of remote attestation protocols. Introducing a shared message format such as CMW enables consistent support for different attestation message types, enables the evolution of message serialization formats without breaking compatibility, and avoids the need to redefine how messages are handled within each protocol.</p>]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9919: The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments]]></title>
            <link>https://www.rfc-editor.org/info/rfc9919/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9919/</guid>
            <pubDate>Tue, 14 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[<p>This specification defines a profile of the Online Certificate Status</p><p>Protocol (OCSP) that addresses the scalability issues inherent when</p><p>using OCSP in large scale (high volume) Public Key Infrastructure</p><p>(PKI) environments and/or in PKI environments that require a</p><p>lightweight solution to minimize communication bandwidth and client-</p><p>side processing.</p><p>This specification obsoletes RFC 5019.  The profile specified in RFC</p><p>5019 has been updated to allow and recommend the use of SHA-256 over</p><p>SHA-1.</p>]]></description>
        </item>
    </channel>
</rss>