Re: [lamps] LAMPS Re-charter

[Roman Danyliw <[e-mail]>]

Hi!

I have added this new text and milestones as a draft charter -- https://datatracker.ietf.org/doc/charter-ietf-lamps/.  My plan is to add it to next week's IESG telechat for initial  review.

Roman

> -----Original Message-----
> From: Spasm <[e-mail]> On Behalf Of Russ Housley
> Sent: Wednesday, March 31, 2021 3:18 PM
> To: LAMPS <[e-mail]>
> Subject: Re: [lamps] LAMPS Re-charter
> 
> I only heard positive responses, so I am now sending this to the SEC ADs for
> charter processing.  For the archive, the text is below.
> 
> Russ
> 
> = = = = = = = =
> 
> 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. 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
> 
> Task 1:
> Jul 2021 	Adopt a draft for short-lived certificate conventions
> Mar 2022 	Short-lived certificate conventions sent to IESG for BCP
> publication
> 
> Task 2:
> DONE     	Adopt a draft for header protection conventions
> Nov 2021 	Header protection conventions sent to IESG for standards track
> publication
> 
> Task 3:
> DONE     	Adopt a draft for CMP updates
> DONE     	Adopt a draft for CMP algorithm
> DONE     	Adopt a draft for Lightweight CMP profile
> Dec 2021 	CMP updates sent to IESG for standards track publication
> Dec 2021 	CMP algorithms sent to IESG for standards track publication
> Dec 2021 	Lightweight CMP profile sent to IESG for informational
> publication
> 
> Task 4:
> May 2021    Adopt a draft for end-to-end email user agent guidance
> Jul 2022    End-to-end email user agent guidance sent to IESG for informational
> publication
> 
> Task 5.a:
> Aug 2021    Adopt draft for PQC KEM public keys in PKIX certificates
> Aug 2021    Adopt draft for PQC KEM algorithms in CMS
> Sep 2021    Adopt draft for PQC signatures in PKIX certificates
> Sep 2021    Adopt draft for PQC signatures in CMS
> 
> Task 5.b.i:
> Sep 2021    Adopt draft for public keys for hybrid key establishment in PKIX
> certificates
> Sep 2021    Adopt draft for hybrid key establishment in CMS
> 
> Task 5.b.ii:
> Sep 2021    Adopt draft for dual signatures in PKIX certificates
> Sep 2021    Adopt draft for dual signature in CMS
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm