WG Review: Limited Additional Mechanisms for PKIX and SMIME (lamps)

[The IESG <[e-mail]>]

The Limited Additional Mechanisms for PKIX and SMIME (lamps) WG in the
Security Area of the IETF is undergoing rechartering. The IESG has not made
any determination yet. The following draft charter was submitted, and is
provided for informational purposes only. Please send your comments to the
IESG mailing list ([e-mail]) by 2026-08-16.

Limited Additional Mechanisms for PKIX and SMIME (lamps)
-----------------------------------------------------------------------
Current status: Active WG

Chairs:
  Russ Housley <[e-mail]>
  Tim Hollebeek <[e-mail]>

Assigned Area Director:
  Deb Cooley <[e-mail]>

Security Area Directors:
  Deb Cooley <[e-mail]>
  Christopher Inacio <[e-mail]>

Mailing list:
  Address: [e-mail]
  To subscribe: https://www.ietf.org/mailman/listinfo/spasm
  Archive: https://mailarchive.ietf.org/arch/browse/spasm/

Group page: https://datatracker.ietf.org/group/lamps/

Charter: https://datatracker.ietf.org/doc/charter-ietf-lamps/

The PKIX and S/MIME Working Groups have been closed for some time. Some
updates have been proposed to the X.509 certificate documents produced by the
PKIX Working Group and the electronic mail security documents produced by the
S/MIME Working Group.

The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working Group is
chartered to make updates where there is a known constituency interested in
real deployment and there is at least one sufficiently well specified
approach to the update so that the working group can sensibly evaluate
whether to adopt a proposal.

The LAMPS WG is now tackling these topics which will be published as
Standards Track, BCP, or Informational:

1. The LAMPS WG may investigate updates to documents produced by the PKIX and
S/MIME WGs. This work will follow the guidelines listed above (real
deployment, known constituency, etc). This includes maintenance of protocols
such as Certificate Management Protocol (CMP), Certificate Management over
Cryptographic Message Syntax (CMS) (CMC), Enrollment over Secure Transport
(EST), S/MIME protocols, and PKIX protocols. These protocols continue to be
used in many different environments and they continue to evolve.

2. Recent progress in the development of quantum computers poses a threat to
widely deployed public key algorithms. As a result, there is a need to
prepare for a day when cryptosystems such as RSA, Diffie-Hellman, ECDSA,
ECDH, and EdDSA cannot be depended upon in the PKIX and S/MIME protocols.

2.a. The US National Institute of Standards and Technology (NIST) has
produced quantum-resistant public-key cryptographic algorithm standards. In
addition, CFRG may vet other quantum-resistant public key cryptographic
algorithms. The LAMPS WG will specify the use of these new Post Quantum
Cryptography (PQC) public key algorithms with the PKIX certificates and the
Cryptographic Message Syntax (CMS). These specifications will use object
identifiers for the new algorithms that are assigned by NIST or by IANA.

 2.b. A lengthy transition from today's public key algorithms to PQC public
 key algorithms is expected. Time will be needed to gain full confidence in
 the new PQC public key algorithms.

 * 2.b.i. The LAMPS WG will specify formats, identifiers, enrollment, and
 operational practices for "hybrid key establishment" that combines the
 shared secret values one or more traditional key-establishment algorithm and
 one or more NIST PQC key-establishment algorithm or a PQC key-establishment
 algorithm vetted by the CFRG. The shared secret values will be combined
 using HKDF (see RFC 5869), one of the key derivation functions in NIST SP
 800-56C, or a key derivation function vetted by the CFRG.

 * 2.b.ii. The LAMPS WG will specify formats, identifiers, enrollment, and
 operational practices for "dual signatures" that combines one or more
 traditional signature algorithm with one or more NIST PQC signature
 algorithm or a PQC algorithm vetted by the CFRG.

 2.c. Specify the use of techniques that allow streamlined processing for PQC
 certificates and exchanges. One example of such use is unsigned X.509
 Certificates to convey information about the subject. Currently, Trust
 Anchors use self-signed certificates for this purpose, using bandwidth that
 could prohibit constrained devices from being able to utilize the larger
 signature sized quantum resistant algorithms.

Milestones:

  Jan 2026 - Composite KEM in PKIX and CMS (Standards Track RFCs)

  Mar 2026 - Composite Signatures in PKIX and CMS (Standards Track RFCs)

  Jun 2026 - Adopt drafts for PQC KEM public keys in PKIX certificates
  (Standards Track RFCs)

  Jun 2026 - Adopt drafts for PQC KEM algorithms in CMS (Standards Track RFCs)

  Jun 2026 - CAA Security (Standards Track RFC)