Re: [lamps] LAMPS Re-charter

[Jonathan Hammell <[e-mail]>]

Thanks Russ. Yes, that is more clear for me. I agree with this updated
charter text.

Jonathan


On Fri., Mar. 26, 2021, 10:00 a.m. Russ Housley, <[e-mail]>
wrote:

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