Re: [lamps] LAMPS Re-charter

[Russ Housley <[e-mail]>]

Jonathan, we could say "enrollment and operational practices" for greater clarity.

Russ

> On Mar 26, 2021, at 9:44 AM, Jonathan Hammell <[e-mail]> wrote:
> 
> 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