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

[Roman Danyliw <[e-mail]>]

Hi!

Please note that this released version of the charter text has minor editorial changes and a few delayed a milestones in response to IESG feedback.  As always, the actual dates for milestones are negotiable.

Roman 

-----Original Message-----
From: Spasm <[e-mail]> On Behalf Of The IESG
Sent: Wednesday, May 5, 2021 9:30 AM
To: IETF-Announce <[e-mail]>
Cc: [e-mail]
Subject: [lamps] WG Review: Limited Additional Mechanisms for PKIX and SMIME (lamps)

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 2021-05-15.

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

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

Assigned Area Director:
  Roman Danyliw <[e-mail]>

Security Area Directors:
  Benjamin Kaduk <[e-mail]>
  Roman Danyliw <[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:

1. Specify the use of short-lived X.509 certificates for which no revocation information is made available by the Certification Authority.
Short-lived certificates have a lifespan that is shorter than the time needed to detect, report, and distribute revocation information.  As a result, revoking short-lived certificates is unnecessary and pointless.

2. Update the specification for the cryptographic protection of email headers -- both for signatures and encryption -- to improve the implementation situation with respect to privacy, security, usability and interoperability in cryptographically-protected electronic mail.
Most current implementations of cryptographically-protected electronic mail protect only the body of the message, which leaves significant room for attacks against otherwise-protected messages.

3. The Certificate Management Protocol (CMP) is specified in RFC 4210, and it offers a vast range of certificate management options.  CMP is currently being used in many different industrial environments, but it needs to be tailored to the specific needs of such machine-to-machine scenarios and communication among PKI management entities.  The LAMPS WG will develop a "lightweight" profile of CMP to more efficiently support of these environments and better facilitate interoperable implementation, while preserving cryptographic algorithm agility.  In addition, necessary updates and clarifications to CMP will be specified in a separate document.  This work will be coordinated with the LWIG WG.

4. Provide concrete guidance for implementers of email user agents to promote interoperability of end-to-end cryptographic protection of email messages.  This may include guidance about the generation, interpretation, and handling of protected messages; management of the relevant certificates; documentation of how to avoid common failure modes; strategies for deployment in a mixed environment; as well as test vectors and examples that can be used by implementers and interoperability testing.  The resulting robust consensus among email user agent implementers is expected to provide more usable and useful cryptographic security for email users.

5. Recent progress in the development of quantum computers pose 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.

5.a. The US National Institute of Standards and Technology (NIST) has a Post-Quantum Cryptography (PQC) effort to produce one or more quantum-resistant public-key cryptographic algorithm standards.
The LAMPS WG will specify the use of these new 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.

5.b. NIST and other organizations are developing standards for post-quantum cryptographic (PQC) algorithms that that will be secure even if large-scale quantum computers are ever developed.
However, 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.

5.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.

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

In addition, the LAMPS WG may investigate other updates to documents produced by the PKIX and S/MIME WG. The LAMPS WG may produce clarifications where needed, but the LAMPS WG shall not adopt anything beyond clarifications without rechartering.

Milestones:

  May 2021 - Adopt a draft for end-to-end email user agent guidance

  Jul 2021 - Adopt a draft for short-lived certificate conventions

  Oct 2021 - Adopt draft for PQC KEM public keys in PKIX certificates

  Oct 2021 - Adopt draft for PQC KEM algorithms in CMS

  Nov 2021 - Header protection conventions sent to IESG for standards track
  publication

  Dec 2021 - CMP updates sent to IESG for  standards track publication

  Dec 2021 - Lightweight CMP profile sent to IESG for informational
  publication

  Dec 2021 - Adopt draft for PQC signatures in PKIX certificates

  Dec 2021 - Adopt draft for PQC signatures in CMS

  Dec 2021 - Adopt draft for public keys for hybrid key establishment in PKIX
  certificates

  Dec 2021 - Adopt draft for hybrid key establishment in CMS

  Dec 2021 - Adopt draft for dual signatures in PKIX certificates

  Dec 2021 - Adopt draft for dual signature in CMS

  Dec 2021 - CMP algorithms sent to IESG for standards track publication

  Mar 2022 - Short-lived certificate conventions sent to IESG for BCP
  publication

  Jul 2022 - End-to-end email user agent guidance sent to IESG for
  informational publication



_______________________________________________
Spasm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/spasm