Re: [lamps] LAMPS Re-charter

[Jonathan Hammell <[e-mail]>]

I'm in favour of LAMPS working on the PQC items described in 5.*.

Will the changes to PKIX certificates to support hybrid key
establishment (5.b.i) and dual signatures (5.b.ii) also require
modifications to CMP or CMC/EST to support requesting such
certificates from CAs?  The text in 5.b.i and 5.b.ii includes that
LAMPS will specify "operational practices" to support hybrid/dual.  Is
that text intended to cover those aspects?

Jonathan

On Wed, Mar 17, 2021 at 6:26 PM Russ Housley <[e-mail]> wrote:
>
> After listening to the LAMPS re-charter comments, I think this captures a way forward.  The PQC milestones do not have a "send to the IESG" part.  The idea is that we would add those when NIST winners get announced.
>
> Thoughts?
>
> 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, 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) or a key derivation
> function vetted by the CFRG.
>
> 5.b.ii. The LAMPS WG will specify formats, identifiers, 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