]> Cryptography Consulting LLC

nicholas.sullivan+ietf@gmail.com

General Internet-Draft This document describes a repeatable publication model for cryptographic work in the IETF. It separates cryptographic mechanism specifications requiring deep security justification from protocol-oriented specifications defining interoperability, wire formats, and registries. It describes a dedicated working group model for coordinating Standards Track deployment of CFRG mechanisms and recommends use of the CFRG Crypto Review Panel to help working groups strengthen their Security Considerations text. About This Document Status information for this document may be found at .

Introduction The CFRG and IETF have developed effective collaboration patterns for publishing cryptographic mechanisms in IETF protocols. MLS and HPKE, Privacy Pass and VOPRF, PPM and VDAF all follow a similar structure: the Crypto Forum Research Group (CFRG) publishes mechanism specifications on the IRTF stream as Informational RFCs, and IETF working groups publish Standards Track protocol integration that references those mechanisms. This document articulates a structured model, informed by those collaborations, for managing the boundary between CFRG mechanism development and IETF Standards Track deployment. It describes three elements: a two-lane publication model (mechanism specification vs. protocol integration), a dedicated working group template for coordinating Standards Track deployment of CFRG mechanisms across multiple protocols, and use of the CFRG Crypto Review Panel to help working groups strengthen their Security Considerations text. In 2025, the IETF chartered the HPKE Working Group to republish on the Standards Track and define post-quantum extensions. This document generalizes the HPKE WG approach into a repeatable pattern available for future mechanisms. These collaboration patterns work well when followed deliberately. Without deliberate coordination between lanes, two recurring problems arise.

Under-Justified Cryptographic Decisions Protocol working groups sometimes duplicate or redefine cryptographic algorithm parameters, encodings, or constructions without CFRG-level analysis. This happens when a WG perceives CFRG engagement as too slow or out-of-scope, leading to cryptographic design decisions in Standards Track documents without security proofs, test vectors, or independent review. A WG that defines a custom key derivation construction or novel nonce generation scheme has made a cryptographic design decision that warrants CFRG scrutiny, regardless of how "straightforward" the construction appears.

Late-Stage Security Surprises Protocol working groups sometimes discover at IETF Last Call or IESG review that a document needs CFRG review, when Security Considerations text is scrutinized and assumptions about threat models, key management, or algorithm properties diverge between cryptographic experts and protocol engineers. This applies across IETF areas, not just the Security Area: any working group using cryptographic mechanisms may encounter gaps between its protocol expertise and the cryptographic properties it depends on. A document that reaches IETF Last Call without crypto review may require Crypto Panel review late in the process, adding months to publication and forcing substantive design changes under time pressure. Working groups, area directors, and the Independent Submissions Editor retain full discretion over adoption. The normative keywords in this document describe recommended practice for those adopting this model. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology

Mechanism agreement:

The set of documents establishing that a cryptographic mechanism is suitable for IETF use. For CFRG-authored mechanisms, this is a mechanism specification (algorithm definition, security analysis, and test vectors) published on the IRTF stream. For externally specified mechanisms, this is the external specification plus a CFRG security considerations document validating the mechanism for IETF protocol contexts. See for the full definition of Lane 1.

Protocol profile:

A Standards Track document (also called "integration document") that defines wire formats, code points, and protocol-specific usage for a given mechanism. See for the full definition of Lane 2.

Two-Lane Publication Model The two-lane publication model separates cryptographic work into two tracks. This separation follows the principle of companion algorithm documents recommended in (BCP 201): base protocol specifications reference separate algorithm documents, allowing either to evolve independently.

Lane 1: Mechanism Agreement Lane 1 establishes that a cryptographic mechanism is suitable for IETF protocol use. Two paths through Lane 1 exist, depending on where the mechanism originates.

CFRG-Authored Specification When CFRG develops a mechanism, it publishes a mechanism specification on the IRTF stream as an Informational RFC. This document defines the cryptographic algorithm, construction, or primitive. It includes algorithm definition with complete mathematical description, security rationale with proofs or references to security analyses, test vectors for all specified operations, and implementation guidance covering known pitfalls. A mechanism specification does not include protocol wire formats or encodings, protocol-specific code point assignments (TLS SignatureScheme values, JOSE algorithm names, etc.), negotiation mechanisms, or integration with specific protocol frameworks. This boundary ensures the mechanism specification can serve multiple protocols without revision, and that protocol changes do not require cryptographic re-analysis. Example: defines EdDSA as a signature scheme over twisted Edwards curves. It includes the algorithm, security analysis, and test vectors. It does not define JOSE or PKIX encodings.

Externally Specified Mechanisms When a mechanism is specified through an external open process with extensive public cryptanalysis (e.g., NIST post-quantum competitions), CFRG does not need to respecify the algorithm. The external specification provides the unambiguous definition; CFRG validates security properties for IETF use cases. Lane 2 work may proceed in parallel with CFRG validation (see ). Two validation paths exist, depending on how many instantiations are under consideration:

CFRG security considerations document:

When multiple instantiations of a mechanism type are candidates for IETF use, CFRG may adopt the topic of that mechanism type's use in the requested setting. The resulting document studies the set of suitable instantiations, analyzing assumptions about key management, composition with other primitives, known limitations, and parameter guidance without duplicating the external specifications.

Crypto Panel review:

When a single instantiation is under consideration, Crypto Panel review () of the working group's profile document is sufficient. A full CFRG security considerations document is not required.

In some cases, CFRG adoption of the security considerations topic is sufficient for Lane 2 work to proceed; publication is not a prerequisite. Lane 2 authors coordinate with the evolving CFRG document on changes and test vectors.

Mechanism Registries Mechanism specifications SHOULD NOT create IANA registries. Two categories of registries exist, with different ownership models:

Mechanism-level registries:

Algorithm identifiers that must be consistent across all consuming protocols. Example: HPKE's KEM, KDF, and AEAD suite identifiers. These are unavoidable when the mechanism itself defines parameterized constructions.

Protocol-specific registries:

Code points within a particular protocol's namespace. Example: TLS SignatureScheme values, JOSE algorithm names, COSE algorithm identifiers. These belong in protocol profile documents, not mechanism specifications.

When mechanism-level registries exist, a dedicated WG or consuming protocol provides the long-term maintenance path on the Standards Track. See for guidance on registry ownership and errata resolution.

Lane 2: Protocol Profiles (IETF Stream) Lane 2 produces Standards Track documents that make a mechanism usable in IETF protocols. The choice depends on scope and novelty:

Lane 2 decision tree

"CFRG-reviewed" in includes both mechanisms that CFRG itself produced and externally specified algorithms that CFRG has validated for IETF use cases. For externally specified algorithms, CFRG validates security properties for IETF protocol contexts without respecifying the algorithm. See .

Existing WG Adoption When an existing working group is the primary consumer of a mechanism and cross-area coordination is minimal, that WG may adopt both the mechanism republication and its protocol profile. The WG requests Crypto Panel review to cover cryptographic aspects outside its core expertise. This avoids creating a new WG while keeping work within established IETF process.

Individual Submission When no existing working group covers the protocol domain, an individual submission produces a profile without forming a working group. Two paths exist depending on the target stream:

• AD-sponsored: The responsible AD sponsors a Standards Track profile through IESG review. The author requests CFRG Crypto Review Panel analysis.
• ISE: The Independent Submissions Editor sponsors an Informational profile on the Independent stream. This path is appropriate for regional or special-purpose profiles (e.g., regionally mandated algorithm suites) that do not target the Standards Track.

Independent submissions generally cannot create IANA registries; profiles on the Independent stream reference existing registry entries rather than creating new ones. This is the lightest-weight path for narrow-scope work.

Dedicated Working Groups When multiple protocols across areas need the mechanism, a dedicated working group coordinates Standards Track integration. The WG republishes the mechanism on the Standards Track, incorporating errata and implementation experience, and coordinates per-protocol profile documents that allocate code points in protocol-specific registries. A dedicated WG is typically warranted when three or more protocol domains need profiles (e.g., TLS, JOSE, COSE, PKIX), the scope is bounded with clear technical consensus, and cross-area coordination justifies a dedicated venue. Proponents may propose charters through existing dispatch mechanisms (, secdispatch). A BoF is not required if ADs and relevant WG chairs agree the work is uncontroversial and scope is well-defined. The responsible AD determines the appropriate path: a BoF for complex or controversial scope, dispatch through secdispatch, or direct charter sponsorship (). The charter MUST reference the specific mechanism specification being profiled and enumerate the protocol domains in scope (e.g., "TLS code points and PKIX encodings for X"). It MUST state explicit non-goals (e.g., "this WG will not redesign the cryptographic mechanism") and include a scope lock prohibiting expansion. The timeline SHOULD be aggressive: 12-18 months. The WG exists to publish, not to redesign. The charter may permit targeted changes based on implementation experience: resolving errata, removing unused features, aligning with IETF formatting requirements. The WG SHOULD maintain a registry of consuming WGs and their profile requirements to ensure complete coverage. The charter SHOULD include a sunset clause: the WG closes upon completing its enumerated deliverables.

Example: HPKE The HPKE Working Group, chartered in 2025 , serves as the first instance of this pattern. It was chartered without a BoF, with AD sponsorship, to republish on the Standards Track and define post-quantum algorithm suites. The WG uses the consolidated approach: a single Standards Track document that is both the mechanism republication and the registry definition for consuming protocols. The charter explicitly constrained scope, excluding redesign of the HPKE mechanism itself. See for a sample charter template.

Timing Models Regardless of which Lane 2 approach is used, two timing models exist for when profile work begins:

Post-publication:

The mechanism RFC exists before profile work starts. This avoids coordination risk and leads to tighter alignment between CFRG and IETF milestones, resulting in more predictable timelines.

Parallel:

Profile work begins while CFRG is still developing the mechanism. This carries coordination risk: if the mechanism changes, profile work may need revision. ADs considering parallel work should assess mechanism stability with CFRG chairs before proceeding. Profiles cannot publish until the mechanism RFC exists (normative reference), but can reach IESG review shortly after.

Profile Document Contents Regardless of which approach produces it, a protocol profile integrates the mechanism into a specific protocol context:

• Wire format definitions (byte layouts, ASN.1 modules, JSON structures)
• IANA code point assignments for that protocol's registries
• Negotiation and algorithm selection mechanisms
• Normative reference to the mechanism specification
• Protocol-specific security considerations

A protocol profile runs 5-15 pages. It normatively references the mechanism specification and focuses on interoperability within its protocol domain. Examples: defines JOSE encodings for EdDSA. defines PKIX encodings. Both reference and are Standards Track.

Entry Criteria Two situations trigger this coordination path, depending on whether the mechanism already exists.

Republication of an existing CFRG mechanism:

A published CFRG mechanism is a candidate for Standards Track promotion when it is referenced as a de facto standard by multiple IETF Standards Track protocols and has verified errata with security or functionality impact. When both conditions hold, Standards Track republication is warranted. When only the first holds, the Downref Registry may suffice. When only the second holds, a CFRG -bis revision may be more appropriate.

New mechanism requiring Standards Track integration:

When CFRG has adopted a mechanism topic and multiple protocols have expressed integration intent, the coordination path described here sequences parallel Lane 2 work. ADs considering parallel work should assess mechanism stability with CFRG chairs before proceeding.

Scope Scope depends on the mechanism's condition:

Clean mechanism (no blocking errata, ready for deployment):

The coordination effort produces Standards Track profiles and optionally republishes the mechanism for status alignment. Republication eliminates downref requirements but is not mandatory if profiles can reference the Informational RFC directly.

Mechanism with accumulated technical debt (unresolved errata,

ambiguities, implementation divergence):

The effort republishes the mechanism on the Standards Track with fixes, then produces updated profiles. The CFRG Crypto Review Panel validates that fixes preserve cryptographic properties. Consuming WGs coordinate reference updates.

Example: An EdDSA coordination effort could resolve 's cofactor ambiguity, incorporate held errata, and produce a Standards Track specification that consuming protocols reference. The scope MUST NOT permit new cryptographic modes or substantial algorithm modifications. Profile work may involve updating recommended code points in alignment with ongoing or completed CFRG work, or with Crypto Panel review. Protocol profiles may include design decisions specific to integration (parameter restrictions, serialization choices, negotiation strategies). These protocol-level design decisions are in scope; changes to the underlying cryptographic mechanism are not.

Coordination Between Lanes The two-lane model requires a coordination point between CFRG (upstream mechanism owner) and the protocols that consume the mechanism (downstream integrators). For a dedicated working group, the WG fills this role. For existing WG adoption, that WG does. For an individual submission, the author and sponsoring AD coordinate directly.

Upstream coordination with CFRG:

The coordination point is the single contact for errata resolution, ambiguity clarification, and mechanism updates. CFRG addresses technical questions once rather than responding to N consuming protocols independently.

Downstream coordination with consumers:

Protocols that need code points or profiles register those needs with the coordination point, which sequences work: mechanism republication first, then profiles in parallel. This aligns timelines so consumers can plan milestones around the mechanism's Standards Track availability rather than managing independent downref approvals.

Coordination mechanisms include cross-posted review requests, cross-area review discussions, and inviting chairs or designees of consuming WGs to participate. The two-lane separation also raises practical questions about normative references, registry ownership, errata resolution, and change control. The following subsections address these.

Normative Reference Rules Protocol profiles normatively reference mechanism specifications. When the mechanism specification is Informational or Experimental (IRTF stream), this creates a downward reference (downref) as defined in . The IETF maintains a Downref Registry and established IESG procedures that handle individual downrefs adequately. A side-effect of the two-lane model is reducing the number of downref exceptions. When a mechanism is republished on the Standards Track, subsequent protocol profiles reference the Standards Track version with no downref required. This is not a driving motivation for the model, but a measurable signal that it reduces coordination overhead. Two resolution paths exist:

• Approved downref: The IESG approves the downref and adds it to the Downref Registry. This is appropriate when the mechanism is stable, widely reviewed, and referenced by few Standards Track documents.
• Standards Track republication: A dedicated WG () republishes the mechanism on the Standards Track, eliminating the downref for all current and future consumers. This is appropriate when the mechanism is widely referenced as a de facto standard.

IANA Considerations Placement

Registry Ownership While IRTF documents can create IANA registries, CFRG is not well-positioned for long-term document maintenance. CFRG's value is cryptographic analysis: security proofs, parameter validation, construction review. Registry administration is not. Protocol-specific registries belong in profile documents, not mechanism specifications. Registry ownership depends on the publication approach. A dedicated WG may consolidate all registries (mechanism-level and protocol code points) in a single Standards Track document, or coordinate separate profile documents where each consuming protocol maintains its own registry allocations. When mechanism-level registries exist in CFRG documents, a dedicated WG or consuming protocol provides the maintenance path on the Standards Track. The mechanics of transferring registry ownership from an IRTF document to a Standards Track document should be confirmed with IANA; the HPKE WG provides an example. See for charter guidance.

Errata and Maintenance Informational RFCs accumulate errata marked "Hold for Document Update" . CFRG can publish -bis revisions as Informational to address these. The Standards Track path provides an alternative with additional benefits: clear document ownership, established IETF maintenance procedures, and elimination of downref requirements for consuming protocols. The model provides a decision framework for when each path is appropriate. A mechanism that is referenced as a de facto standard by multiple IETF Standards Track protocols and has verified errata with security or functionality impact is a candidate for Standards Track promotion. See for entry criteria. (HPKE) and (LMS) are CFRG documents that created IANA registries. HPKE is now being retrofitted: the HPKE WG is republishing it on the Standards Track, taking over registry ownership and providing a clear home for code point allocation as post-quantum suites are added.

Change Control Boundaries When a mechanism is republished on the Standards Track, the IETF owns the resulting document and any subsequent revisions. CFRG retains cryptographic review authority: substantive changes to the algorithm or security properties require CFRG Crypto Review Panel analysis before IETF publication. This division places document maintenance (errata resolution, bis revisions) within IETF process while ensuring cryptographic expertise guides substantive changes. Protocol working groups own protocol profile evolution: code point assignments, wire format changes, and integration updates. Cryptographic expertise stays with CFRG. Protocol-specific details stay with domain experts.

CFRG Crypto Review Panel The CFRG maintains a Crypto Review Panel that provides expert cryptographic analysis for documents across the IETF and IRTF. The panel's members are primarily external cryptographic experts who bring independent analytical capability. While primarily used by Security Area working groups, the panel is available to any WG whose documents include cryptographic mechanisms. To request review, an AD, WG chair, or author contacts the CFRG chairs, who assign a panel reviewer based on the document's cryptographic content. The ISE may also request review for independent submissions. Panel findings do not bind the WG or responsible AD, who decide how to address them. The responsible AD determines whether Crypto Panel review is needed before IESG approval, based on cryptographic complexity. If the panel demonstrates consistent value under increased use, the community may explore further organizational support (such as published membership rosters, documented review procedures, or datatracker integration) to sustain review capacity.

What Is Reviewed The panel focuses on cryptographic correctness and appropriateness, not general protocol design. Review areas include:

• Cryptographic justification for algorithm choices
• Security Considerations text covering algorithm-specific risks
• Correctness of algorithm usage (modes, parameters, contexts)
• Parameter choices (key sizes, nonce handling, iteration counts)
• Composition of primitives (KDF chains, AEAD usage, etc.)
• Externally specified algorithms proposed for IETF use: validating that security claims hold in IETF protocol contexts

The panel does not duplicate Security Area Directorate review. Working groups may request targeted reviews of specific cryptographic usage (e.g., "review our use of HKDF in this context") without requiring a full document review.

Requesting Review Review is warranted when a draft defines cryptographic behavior beyond what existing CFRG specifications cover: novel constructions, non-standard parameter choices, or security claims that rely on unanalyzed cryptographic properties. Review is generally not needed when a draft uses CFRG-published mechanisms as specified, defining only wire formats, code points, or protocol integration. Working groups SHOULD request review before WG Last Call, ideally when the Security Considerations section nears completion. The panel targets 2-4 weeks for review completion. WGs introducing novel cryptographic constructions should consult the panel during design, not after. provides a complete pre-WG-Last-Call checklist. The WG documents the disposition of each finding (accepted, rejected with rationale, or overtaken by design changes). The Crypto Panel may recommend routing a document through CFRG if the work involves novel mechanisms requiring deeper research community review.

National Cryptography The two-lane model applies to all cryptographic mechanisms. This section addresses algorithms that have not undergone broad open international review and whose adoption is primarily driven by regulatory compliance.

Definition This section uses the term "national cryptography" as shorthand for algorithms where:

• Public cryptanalysis and independent review are limited relative to algorithms selected through open international processes
• Adoption is driven by regulatory compliance in a specific jurisdiction rather than broad cryptographic community consensus

Algorithms that have undergone extensive public review enter IETF protocols through the main flowchart path (). The guardrails below apply to algorithms that have not.

Risks and Challenges Algorithms in this category create tension between regional regulatory compliance and global protocol interoperability. When a regulator mandates algorithm X for domestic deployments, the IETF must decide whether and how to accommodate X without fragmenting the global protocol baseline. Incorporating such algorithms without sufficient safeguards produces four problems. First, regulatory mandates create compliance pressure that overrides global interoperability, fragmenting protocols into regional variants. Second, algorithms without extensive public cryptanalysis carry higher risk of undiscovered weaknesses. Third, algorithms with limited global deployment inflate IANA registries and increase implementation complexity for marginal benefit. Fourth, algorithms perceived as government-controlled raise concerns about backdoors regardless of technical merit. These risks motivate the guardrails below.

Guardrails and Best Practices The following practices manage the risks above while preserving regional extensibility. These guardrails are process-based: they apply to any algorithm that has not undergone broad open international review, regardless of origin. Algorithms that have undergone extensive public review enter through the main path (). Algorithms without such review appear in separate optional profile documents that reference the algorithm's authoritative specification (whether a national standard, an Informational RFC, or an independent submission). They do not modify core protocol specifications or base mechanism documents.

Optional profiles:

Algorithms without broad international review SHOULD be specified in separate optional profile documents, not embedded in core protocol specifications. This preserves a globally interoperable baseline while allowing regional extensions. is an example of this pattern for TLS 1.3 .

Recommendation marking:

Where IANA registries include a "Recommended" column, working groups MAY choose to only recommend algorithms that have CFRG approval. See for an example.

Registry policy:

Registries for cryptographic algorithms SHOULD maintain "RFC Required" or "Specification Required" policies with designated expert review. Early allocation and private use ranges mitigate pressure for premature standardization.

Crypto Panel review required:

Algorithms entering through this path MUST receive Crypto Panel review. Lack of public cryptanalysis is grounds for rejection or marking as Not Recommended.

Code point coordination:

Algorithms appearing in multiple protocols SHOULD coordinate all registrations together to avoid redundant or conflicting identifiers.

Example: NIST Post-Quantum Algorithms Algorithms selected through open international competitions with extensive public cryptanalysis illustrate the main-path model for well-reviewed external algorithms. Such algorithms enter IETF protocols through the main flowchart path (): externally specified, CFRG-reviewed via security considerations documents, then working groups write protocol profiles. The guardrails in this section do not apply because these algorithms have undergone extensive public review.

Neutral Language Documents involving algorithms in this category MUST use neutral, technical language focused on interoperability and security properties. Political or geopolitical framing is inappropriate. Factual statements about algorithm provenance, standardization body, and public analysis status are acceptable and encouraged for transparency.

Security Considerations This document defines processes and best practices; it does not specify protocols or cryptographic algorithms directly. The two-lane model is designed to improve security outcomes by routing cryptographic mechanisms through focused expert review in CFRG while protocol integration receives appropriate review in working groups. Separating these concerns is intended to reduce the risk of cryptographic errors during protocol design and provide a structured path for applying CFRG Crypto Review Panel expertise to documents across the IETF and IRTF. Concentrating cryptographic review in a small panel creates process risks: reviewer availability can bottleneck publication, and a narrow reviewer pool may develop blind spots. Mitigations include maintaining diverse panel membership, publishing review criteria, and preserving AD discretion to proceed when panel review is unavailable or disputed.

IANA Considerations This document has no IANA actions.

References Normative References Many IETF protocols use cryptographic algorithms to provide confidentiality, integrity, authentication, or digital signature. Communicating peers must support a common set of cryptographic algorithms for these mechanisms to work properly. This memo provides guidelines to ensure that protocols have the ability to migrate from one mandatory-to-implement algorithm suite to another over time. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. IETF procedures generally require that a standards track RFC may not have a normative reference to another standards track document at a lower maturity level or to a non standards track specification (other than specifications from other standards bodies). For example, a standards track document may not have a normative reference to an informational RFC. Exceptions to this rule are sometimes needed as the IETF uses informational RFCs to describe non-IETF standards or IETF-specific modes of use of such standards. This document clarifies and updates the procedure used in these circumstances. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JSON Object Signing and Encryption (JOSE). This document specifies algorithm identifiers and ASN.1 encoding formats for elliptic curve constructs using the curve25519 and curve448 curves. The signature algorithms covered are Ed25519 and Ed448. The key agreement algorithms covered are X25519 and X448. The encoding for public key, private key, and Edwards-curve Digital Signature Algorithm (EdDSA) structures is provided. This note describes a digital-signature system based on cryptographic hash functions, following the seminal work in this area of Lamport, Diffie, Winternitz, and Merkle, as adapted by Leighton and Micali in 1995. It specifies a one-time signature scheme and a general signature scheme. These systems provide asymmetric authentication without using large integer mathematics and can achieve a high security level. They are suitable for compact implementations, are relatively simple to implement, and are naturally resistant to side-channel attacks. Unlike many other signature systems, hash-based signatures would still be secure even if it proves feasible for an attacker to build a quantum computer. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This has been reviewed by many researchers, both in the research group and outside of it. The Acknowledgements section lists many of them. This document specifies how to use the ShangMi (SM) cryptographic algorithms with Transport Layer Security (TLS) protocol version 1.3. The use of these algorithms with TLS 1.3 is not endorsed by the IETF. The SM algorithms are becoming mandatory in China, so this document provides a description of how to use the SM algorithms with TLS 1.3 and specifies a profile of TLS 1.3 so that implementers can produce interworking implementations. The purpose of this document is to make the Russian cryptographic standards available to the Internet community for their implementation in the Transport Layer Security (TLS) Protocol Version 1.3. This document defines the cipher suites, signature schemes, and key exchange mechanisms for using Russian cryptographic standards, called GOST algorithms, with TLS Version 1.3. Additionally, this document specifies a profile of TLS 1.3 with GOST algorithms to facilitate interoperable implementations. The IETF has not endorsed the cipher suites, signature schemes, or key exchange mechanisms described in this document. RFC 5727 defined several processes for the former Real-time Applications and Infrastructure (RAI) area. These processes include the evolution of the Session Initiation Protocol (SIP) and related protocols, as well as the operation of the DISPATCH and SIPCORE working groups. This document updates RFC 5727 to allow flexibility for the area and working group structure, while preserving the SIP change processes. It also generalizes the DISPATCH working group processes so that they can be easily adopted by other working groups. This memo provides a charter for the Internet Engineering Steering Group (IESG), a management function of the Internet Engineering Task Force (IETF). It is meant to document the charter of the IESG as it is presently understood. This memo provides information for the Internet community. This document discusses tactics and strategy for hosting a successful IETF Birds-of-a-Feather (BOF) session, especially one oriented at the formation of an IETF Working Group. It is based on the experiences of having participated in numerous BOFs, both successful and unsuccessful. [STANDARDS-TRACK] This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. RFC Production Center RFC Production Center This document describes the current web-based process for handling the submission, verification, and posting of errata for the RFC Series. The main concepts behind this process are (1) distributing the responsibility for verification to the appropriate organization or person for each RFC stream, and (2) using a Web portal to automate the processing of erratum reports. This system was launched in November 2007. This draft documents the existing system as a means to facilitate discussion to revamp how errata are reported, reviewed, and publicized.

Charter Template The following sample template is provided for area directors chartering dedicated working groups that deploy CFRG cryptographic mechanisms. Text in brackets should be replaced with context-specific content.

Pre-Last-Call Crypto Checklist Working groups introducing cryptographic mechanisms should address these items before WG Last Call. This checklist complements formal review processes.

1. Stable algorithm specification exists:

   Does a published or imminent RFC specify the cryptographic mechanism in full detail, including security analysis? Or does this draft invent new cryptography?

2. Crypto Panel review completed:

   Has the CFRG Crypto Review Panel reviewed this document? If not, has a review request been filed with the CFRG chairs?

3. Security Considerations drafted:

   Does the Security Considerations section address algorithm- specific risks (key size, parameter choices, known attacks) in addition to protocol-level concerns?

4. IANA code points identified:

   Have algorithm identifiers, code points, or OIDs been requested in appropriate registries? Is the registration policy appropriate for cryptographic algorithms?

5. No duplicate work elsewhere:

   Have you confirmed that another WG or SDO is not standardizing the same algorithm integration? Check related WG charters and recent IETF Last Calls.

6. Backward compatibility considered:

   If extending an existing protocol, how do implementations negotiate the new algorithm? What happens when one peer does not support it?

7. Performance impact assessed:

   What is the computational cost compared to existing alternatives? Are there environments (IoT, constrained devices) where performance is prohibitive?

8. Recommended vs optional status decided:

   Should this algorithm be marked "Recommended" in IANA registries, or is it a special-purpose or regional algorithm? What is the justification?

9. Test vectors included or referenced:

   Are there test vectors for implementation validation? If in a separate mechanism spec, is that document normatively referenced?

10. Algorithm agility preserved:

    Does the design follow algorithm agility principles ? Can the algorithm be replaced or deprecated without redesigning the protocol?

Summary for ADs and Chairs Three elements for IETF cryptographic standardization:

Two-Lane Model (Mechanism + Profiles) Separate cryptographic mechanism specifications (CFRG Informational RFCs with full algorithm details and security analysis) from protocol profile specifications (Standards Track RFCs defining integration into specific protocols). Profiles normatively reference mechanism specs rather than duplicating algorithm text. This avoids duplication, ensures consistent security analysis, and lets one mechanism serve multiple protocols.

Coordination Path A coordination model for moving CFRG mechanisms to the Standards Track, applicable to any Lane 2 vehicle: existing WG adoption, individual submission, or a dedicated working group. The model establishes a single coordination point between CFRG (upstream) and consuming protocols (downstream). Two timing models apply: post-publication (mechanism RFC exists) and parallel (work begins while CFRG is still developing the mechanism, with the AD assessing stability). When three or more protocol domains need profiles, a dedicated WG provides cross-area coordination. Scope prohibits new cryptographic modes or algorithm modifications, though profile work may update recommended code points in alignment with CFRG work or Crypto Panel review.

CFRG Crypto Review Panel An optional resource to help working groups strengthen their Security Considerations text. To request review, an AD, WG chair, or author contacts the panel. This applies cryptographic expertise consistently, catches algorithm usage errors, and identifies when work should route to CFRG.

Example: EdDSA The Edwards-curve Digital Signature Algorithm (EdDSA) predates this document. It did not follow the two-lane model deliberately, but its history illustrates both the accidental benefits of separation and the costs of insufficient CFRG vetting.

What Happened CFRG published (EdDSA) as an Informational RFC in January 2017. Three Standards Track profiles followed independently: (TLS 1.3 code points), (JOSE identifier), and (PKIX OIDs). served as a Lane 1 mechanism specification; the three Standards Track RFCs served as Lane 2 profiles, each normatively referencing without duplicating algorithm text.

What Went Wrong 's publication revealed gaps that additional structured review might have caught. These gaps illustrate why this document recommends more rigorous review for mechanism specifications. Consequences:

Cofactor ambiguity:

underspecifies validation of public key and signature components, causing implementation divergence in whether small-order elements are accepted. documents this incompatibility across deployed implementations.

Errata backlog:

Contributors filed multiple errata against . Several are held for a document update that has no publication path: CFRG cannot publish Standards Track revisions and no IETF WG owns the document.

Missing security theorem:

The document provides security discussion but no precise theorem statement or citation to the relevant Schnorr-family reduction. A mechanism specification under the two-lane model should cite or reproduce the formal security argument.

No coordinated profile timing:

The JOSE profile () appeared simultaneously with in January 2017, but the PKIX profile () took until August 2018. The Curve25519 key agreement function predated by a year, causing sequencing confusion about which curves were ready for which protocols.

How the Two-Lane Model Applies Under the two-lane model, CFRG would resolve the cofactor ambiguity and produce formal security arguments before publication. A dedicated WG would then republish the vetted mechanism on the Standards Track, coordinate profile documents, and sequence work so consuming WGs can plan their milestones. The Crypto Review Panel would review profiles for correct algorithm usage: cofactor handling, context strings, cross-protocol attack prevention.

EdDSA as Pilot The two-lane model also applies retroactively. EdDSA is a candidate for testing whether this coordination model is repeatable: it meets both decision criteria (de facto standard referenced by multiple Standards Track protocols; verified errata with security and functionality impact), it is well-understood, and it is not on the post-quantum transition hot path. A charter for EdDSA would illustrate the model without interfering with higher-priority work. EdDSA remains widely deployed and its errata affect current implementations regardless of post-quantum timelines. Six confirmed errata, some highlighting deployment and interoperability hazards, warrant resolution independent of the post-quantum transition. A charter might be scoped as follows:

Charter scope:

Produce a Standards Track EdDSA specification that resolves the cofactor ambiguity by specifying explicit validation criteria for public keys and signature components. Incorporate held errata. Add a formal security theorem statement or normative citation to the Schnorr-family reduction. The resulting document supersedes as the normative algorithm reference.

Profile updates:

Coordinate with TLS, JOSE, and PKIX working groups to update their normative references from to the new Standards Track document. Existing code points and wire formats remain unchanged; only the reference target changes.

Crypto Panel review:

The Crypto Review Panel reviews the new specification's resolution of the cofactor ambiguity, confirms the security argument is complete, and verifies that validation criteria produce consistent behavior across implementations.

Success or failure of this pilot informs how the model applies to higher-stakes mechanisms during the post-quantum transition.