[lamps] Proposed recharter text
Russ Housley <housley@vigilsec.com> Wed, 10 February 2021 20:22 UTC
Return-Path: <housley@vigilsec.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2693A14F0 for <spasm@ietfa.amsl.com>; Wed, 10 Feb 2021 12:22:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zm9jlo52LJlm for <spasm@ietfa.amsl.com>; Wed, 10 Feb 2021 12:22:11 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5922F3A1524 for <spasm@ietf.org>; Wed, 10 Feb 2021 12:22:05 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id EE01D300BD0 for <spasm@ietf.org>; Wed, 10 Feb 2021 15:22:02 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fgPuU3uOjdLx for <spasm@ietf.org>; Wed, 10 Feb 2021 15:22:00 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id C0B20300B68 for <spasm@ietf.org>; Wed, 10 Feb 2021 15:22:00 -0500 (EST)
From: Russ Housley <housley@vigilsec.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Date: Wed, 10 Feb 2021 15:22:02 -0500
References: <DM6PR11MB43808FA7D74229A5997965649FBA9@DM6PR11MB4380.namprd11.prod.outlook.com>
To: LAMPS <spasm@ietf.org>
In-Reply-To: <DM6PR11MB43808FA7D74229A5997965649FBA9@DM6PR11MB4380.namprd11.prod.outlook.com>
Message-Id: <9D01B155-6BB8-4438-8FAA-149686B69B64@vigilsec.com>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/wf148GFEMZlM-1M2AYaM8AFnEig>
Subject: [lamps] Proposed recharter text
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Feb 2021 20:22:20 -0000
I propose the attached recharter text. Tasks 1-3 are unchanged from the current charter, Task 4 is a slightly edited version of the text proposed by DKG after IETF 109. Task 5 is the text that came out of the discussion that followed the virtual interim at the end of last month. Task 6 was raised in the discussion that followed the virtual interim at the end of last month. In my view, it is too early to work on advancement of RFC 8550 and RFC 8551, but putting it in the charter now will allow us to tackle them when they are well deployed. 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. As a result, there are efforts to develop standards for post-quantum cryptosystem (PQC) algorithms that that will be secure if large-scale quantum computers are ever developed. a. Specify the use of PQC public key algorithms with the PKIX certificates and the Cryptographic Message Syntax (CMS). b. Develop specifications to facilitate a lengthy transition from today's public key algorithms to PQC public key algorithms. Unlike previous algorithm transitions, time will be needed before there is full confidence in the PQC public key algorithms. Therefore, transition mechanisms that combine traditional algorithms with PQC algorithms will be needed for "hybrid key establishment" and "dual signatures". NIST defines "hybrid key establishment" as any key establishment scheme that is a combination of two or more components that are themselves cryptographic key-establishment schemes. NIST defines "dual signatures" as any signature scheme that consists of two or more signatures on a common message. The specifications developed will enable PKIX and S/MIME protocols to support hybrid key establishment and dual signature mechanisms. 6. Progress RFC 5280, RFC 6960, RFC 8550, and RFC 8551 to Internet Standard status. 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.
- [lamps] Proposed re-charter text for hybrid and d… Mike Ounsworth
- Re: [lamps] Proposed re-charter text for hybrid a… Sean Turner
- Re: [lamps] [EXTERNAL] Re: Proposed re-charter te… Mike Ounsworth
- Re: [lamps] Proposed re-charter text for hybrid a… Russ Housley
- Re: [lamps] Proposed re-charter text for hybrid a… Michael Richardson
- Re: [lamps] Proposed re-charter text for hybrid a… Michael Jenkins
- Re: [lamps] Proposed re-charter text for hybrid a… Michael Richardson
- Re: [lamps] Proposed re-charter text for hybrid a… Russ Housley
- [lamps] Proposed recharter text Russ Housley
- Re: [lamps] Proposed recharter text Salz, Rich
- Re: [lamps] Proposed recharter text Russ Housley
- Re: [lamps] Proposed recharter text Salz, Rich
- Re: [lamps] Proposed recharter text Ryan Sleevi
- Re: [lamps] Proposed recharter text Salz, Rich
- Re: [lamps] Proposed recharter text Brockhaus, Hendrik
- Re: [lamps] Proposed recharter text Ryan Sleevi
- Re: [lamps] Proposed recharter text Russ Housley
- Re: [lamps] Proposed recharter text Russ Housley
- Re: [lamps] Proposed recharter text Ryan Sleevi
- Re: [lamps] Proposed recharter text Michael Richardson
- Re: [lamps] Proposed recharter text Michael Richardson
- Re: [lamps] Proposed recharter text Tadahiko Ito
- Re: [lamps] Proposed recharter text Ryan Sleevi
- Re: [lamps] Proposed recharter text Michael Richardson
- Re: [lamps] Proposed recharter text Russ Housley
- Re: [lamps] [EXTERNAL] Proposed recharter text Mike Ounsworth
- Re: [lamps] [EXTERNAL] Proposed recharter text Russ Housley
- Re: [lamps] [EXTERNAL] Proposed recharter text Mike Ounsworth
- Re: [lamps] Proposed recharter text Panos Kampanakis (pkampana)
- Re: [lamps] [EXTERNAL] Proposed recharter text Brockhaus, Hendrik
- Re: [lamps] Proposed recharter text Russ Housley
- Re: [lamps] Proposed recharter text Panos Kampanakis (pkampana)
- Re: [lamps] Proposed recharter text Mike Ounsworth
- Re: [lamps] Proposed recharter text Russ Housley
- Re: [lamps] Proposed recharter text Russ Housley
- Re: [lamps] Proposed recharter text Roman Danyliw
- Re: [lamps] Proposed recharter text Mike Ounsworth
- Re: [lamps] Proposed recharter text Roman Danyliw
- Re: [lamps] Proposed recharter text Mike Ounsworth
- Re: [lamps] Proposed recharter text Salz, Rich
- Re: [lamps] Proposed recharter text Benjamin Kaduk
- Re: [lamps] Proposed recharter text Michael Richardson
- Re: [lamps] Proposed recharter text Roman Danyliw
- Re: [lamps] Proposed recharter text Mike Ounsworth
- Re: [lamps] Proposed recharter text Roman Danyliw