Re: [lamps] WG Action: Rechartered Limited Additional Mechanisms for PKIX and SMIME (lamps)

[Russ Housley <[e-mail]>]

Good news.  Over the next few weeks we will conduct calls for adoption for the documents that are now in scope.

Russ


> On Dec 6, 2019, at 12:54 PM, The IESG <[e-mail]> wrote:
> 
> The Limited Additional Mechanisms for PKIX and SMIME (lamps) WG in the
> Security Area of the IETF has been rechartered. For additional information,
> please contact the Area Directors or the WG Chairs.
> 
> 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.
> 
> 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:
> 
>  Nov 2019 - Adopt a draft for short-lived certificate conventions
> 
>  Dec 2019 - Adopt a draft for header protection conventions
> 
>  Dec 2019 - Adopt a draft for CMP updates
> 
>  Dec 2019 - Adopt a draft for Lightweight CMP profile
> 
>  Nov 2020 - Short-lived certificate conventions sent to IESG for BCP
>  publication
> 
>  Nov 2020 - CMP updates sent to IESG for  standards track publication
> 
>  Nov 2020 - Lightweight CMP profile sent to IESG for informational
>  publication
> 
>  Mar 2021 - Header protection conventions sent to IESG for standards track
>  publication
> 
>