Re: [lamps] LAMPS Re-charter

Russ Housley <housley@vigilsec.com> Wed, 31 March 2021 19:18 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 6261C3A3328 for <spasm@ietfa.amsl.com>; Wed, 31 Mar 2021 12:18:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 PToKbQaxZWL2 for <spasm@ietfa.amsl.com>; Wed, 31 Mar 2021 12:18:24 -0700 (PDT)
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 6AE093A2624 for <spasm@ietf.org>; Wed, 31 Mar 2021 12:18:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9D3D3300BBB for <spasm@ietf.org>; Wed, 31 Mar 2021 15:18:21 -0400 (EDT)
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 89azDMiM1p9L for <spasm@ietf.org>; Wed, 31 Mar 2021 15:18:19 -0400 (EDT)
Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 3271D300B0D for <spasm@ietf.org>; Wed, 31 Mar 2021 15:18:19 -0400 (EDT)
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, 31 Mar 2021 15:18:19 -0400
References: <5A22DF7B-BCA5-42F6-BB95-D4F70FDB1996@vigilsec.com> <951CAF0F-7461-4057-B95E-D1F6CAE61D02@vigilsec.com> <4c18a9982cc94df2952d7b2cbae89d99@cert.org> <7B82765F-9C7A-4C4D-B115-A2835B44E6D6@vigilsec.com> <b3fdb1ac051b4ae0ad748782daebead2@cert.org> <ACE141CD-B0B7-45D3-B54F-BE25275A0D25@vigilsec.com> <CALhKWgjB_RVGaQriPbero6eWTdaD4JaVqmHLjHHsqsjrBHUrFA@mail.gmail.com> <EF24C291-BE2D-40A6-8916-84F62DA78559@vigilsec.com> <EECA1CAC-54EA-4A19-931C-0383A28E9111@vigilsec.com>
To: LAMPS <spasm@ietf.org>
In-Reply-To: <EECA1CAC-54EA-4A19-931C-0383A28E9111@vigilsec.com>
Message-Id: <6381BB73-C84E-4191-BA71-77D65D63D53A@vigilsec.com>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/KJgOhutDZtfBcaI93ZvRa_qmf0s>
Subject: Re: [lamps] LAMPS Re-charter
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, 31 Mar 2021 19:18:30 -0000

I only heard positive responses, so I am now sending this to the SEC ADs for charter processing.  For the archive, the text is below.

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, enrollment, 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), one of the key
derivation functions in NIST SP 800-56C, or a key derivation
function vetted by the CFRG.

5.b.ii. The LAMPS WG will specify formats, identifiers, enrollment, 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