Summary

  • The IETF rechartered LAMPS to maintain PKIX and S/MIME mechanisms and pursue post-quantum work including hybrid key establishment, dual signatures and streamlined certificate processing.
  • A charter creates agenda authority. It does not adopt a draft, finish an RFC, assign every identifier, ship an implementation, install a trust anchor or prove that a certificate population migrated.

The unsigned certificate is not the trust decision

The most revealing line in the new charter is not a named algorithm. It is an example of a certificate without a signature.

Post-quantum signatures are large. On a constrained device, carrying a self-signature on an X.509 trust-anchor certificate can consume bandwidth and processing for information that the device may already receive through a trusted configuration channel. The charter therefore permits work on streamlined exchanges and mentions an unsigned X.509 certificate used to convey subject information.

The word “unsigned” can sound like the removal of security. In this context, it exposes where the relevant authority already lives. A relying party does not trust a root merely because the root signed itself. RFC 5280 treats trust-anchor information as an input to certification-path validation, obtained through a trustworthy out-of-band procedure. RFC 5914 defines a separate TrustAnchorInfo representation.

A lighter container can therefore omit a self-signature without automatically changing the local trust decision. The hard questions move to the installation channel: who authorized this anchor, how was the object protected, what local name and key were pinned, which constraints were attached, what replaced the previous anchor and how can the change be rolled back?

This is an illustrative authority case, not a deployed LAMPS mechanism or reported incident. The charter has opened a work area. It has not standardized that unsigned container.

Rechartering changed the agenda on 21 August

At 20:40 UTC on 21 August 2026, the IETF announced that the Limited Additional Mechanisms for PKIX and SMIME Working Group had been rechartered. Datatracker shows LAMPS as active and its current charter as revision 08, approved.

The charter gives the group two connected responsibilities. It can maintain documents inherited from the closed PKIX and S/MIME working groups, including mechanisms around CMP, CMC, EST, S/MIME and PKIX. It can also prepare those ecosystems for public-key algorithms that may replace or accompany RSA, Diffie-Hellman, ECDSA, ECDH and EdDSA in a post-quantum transition.

This is not an unlimited invitation to redesign public-key infrastructure. The charter says work should have a known constituency interested in real deployment and at least one sufficiently specified approach that the group can sensibly evaluate for adoption.

Those conditions are filters on agenda authority. They are not findings that an approach works. A known constituency can still disagree about failure policy. A detailed proposal can still contain a security flaw. A working group can still decline adoption, revise the design or fail to reach consensus.

NIST standards begin another integration problem

The charter refers to quantum-resistant algorithms standardized by NIST and to possible algorithms vetted by the CFRG. NIST has published FIPS 203 for ML-KEM, FIPS 204 for ML-DSA and FIPS 205 for SLH-DSA.

Those publications answer essential algorithm questions. They do not by themselves specify every place the algorithms must fit in PKIX certificates, CMS objects, enrollment exchanges or S/MIME applications. Integration needs exact identifiers and encodings. It needs parameter policy, certificate profiles, validation behavior, error rules, test vectors and implementation support.

The charter says specifications will use object identifiers assigned by NIST or IANA. An OID makes an algorithm or construction nameable in a structured object. It does not make an implementation available or a relying party willing to accept it.

This creates a useful evidence chain: algorithm standard, protocol profile, identifier allocation, RFC state, code path, configured policy, produced object, accepted object and observed service. Collapsing those states into “PQC ready” manufactures completion.

A hybrid result needs a combination rule

LAMPS is now chartered to specify formats, identifiers, enrollment and operational practice for hybrid key establishment. The stated design combines shared-secret values from one or more traditional algorithms with one or more eligible post-quantum algorithms.

Combining does not mean concatenating two impressive names. Both contributions need an unambiguous encoding and a derivation rule. The charter names HKDF, a method from NIST SP 800-56C or a function vetted by the CFRG as candidate combination machinery.

RFC 5869 separates extraction from expansion. That structure matters because a combined secret must be converted into keying material under explicit salt, context and length rules. The security claim also needs a precise failure model: does the construction remain secure when one component is later broken, incorrectly implemented, substituted or omitted?

The current composite-KEM work is still an Active Internet-Draft at the evidence freeze. Its existence proves active specification work. It does not prove that products agree on a final encoding, enrollment workflow, rejection rule or operational transition.

Two signatures create more than one acceptance state

The charter separately calls for dual signatures combining one or more traditional algorithms with one or more eligible post-quantum signature algorithms. The current composite-signature document is likewise an Active Internet-Draft.

Any combined signature design has to say what a verifier does with its components. Must every component validate? Can policy temporarily accept one? How are algorithm identifiers bound to keys and signatures? What happens when a library understands the outer object but not one component? Can a downgrade turn a transitional hedge into traditional-only authority?

The answers cannot be inferred from the word “composite.” A signer, certificate authority, CMS producer, S/MIME client and relying application can each support different portions of the construction. The operational state is the intersection of those capabilities and their policies.

This is also why inventory by certificate count is inadequate. A certificate can contain new material while the mail client ignores it. A CMS library can parse a new identifier while a policy engine rejects the signer. A producer can emit both components while an intermediary rewrites or strips an unsupported structure. Migration is a path property.

The milestone is a clock, not a certificate

The recharter announcement lists October 2026 for Composite Signatures in PKIX and CMS, November for Composite KEM in PKIX and CMS, and December for CAA Security.

These are work-plan milestones. They help chairs, authors and participants see sequencing and slippage. They are not delivery warranties. A month in a charter does not establish working-group last call, IETF Last Call, IESG approval, normative-reference closure, RFC publication, code release or fleet deployment.

A missed milestone can reveal complexity, contention or insufficient review capacity. It is not itself evidence that the underlying cryptography failed. Conversely, meeting a document milestone does not prove that constrained devices can carry the resulting objects or that enterprise trust stores have a safe migration path.

Leadership reporting should preserve both meanings. Track the institutional schedule to understand coordination risk. Track implementation and relying-party evidence to understand operational risk.

The charter's authority stops at the work boundary

An IETF working-group charter determines what a group is expected and permitted to work on. It can make neglected compatibility problems visible, attract reviewers and give document adoption a coherent home. Those are consequential powers.

They do not convert the working group into a certificate authority, an algorithm regulator or a remote administrator of trust stores. NIST controls its algorithm standards. IANA and other designated authorities assign identifiers under their rules. The IETF process determines document status. Vendors write and ship code. Operators and product owners configure which objects their systems accept.

The boundary protects both sides. A charter without implementation is not deployment. A vendor implementation outside the charter does not become an IETF standard through use alone. A locally installed trust anchor remains a local grant even when its representation follows an RFC.

For each work item, preserve the charter revision, problem statement, known deployment constituency, draft revision, adoption record, unresolved objections, consensus state, security analysis, standards review, dependency state, identifier assignments, test vectors, independent implementations, enrollment support, relying-party configuration, fallback behavior and measured exchange result.

Sources