[lamps] Potential Topics for LAMPS Recharter

Russ Housley <housley@vigilsec.com> Fri, 30 March 2018 18:05 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 27CA3126C2F for <spasm@ietfa.amsl.com>; Fri, 30 Mar 2018 11:05:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id p8slPU5VWCaS for <spasm@ietfa.amsl.com>; Fri, 30 Mar 2018 11:05:02 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C23312420B for <spasm@ietf.org>; Fri, 30 Mar 2018 11:05:02 -0700 (PDT)
Received: from localhost (localhost []) by mail.smeinc.net (Postfix) with ESMTP id C76C0300548 for <spasm@ietf.org>; Fri, 30 Mar 2018 14:04:59 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([]) by localhost (mail.smeinc.net []) (amavisd-new, port 10026) with ESMTP id T_LaHuO2ernW for <spasm@ietf.org>; Fri, 30 Mar 2018 14:04:58 -0400 (EDT)
Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net []) by mail.smeinc.net (Postfix) with ESMTPSA id B7B133004AA for <spasm@ietf.org>; Fri, 30 Mar 2018 14:04:58 -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 10.3 \(3273\))
Message-Id: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com>
Date: Fri, 30 Mar 2018 14:05:10 -0400
To: LAMPS <spasm@ietf.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/o7aDwt5VMXCyL5UeLHrZxrdQjaA>
Subject: [lamps] Potential Topics for LAMPS Recharter
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 30 Mar 2018 18:05:04 -0000

Several things have come up over the last few weeks that might be added to the LAMPS charter.

First, two Iinternet-Drafts were directed to LAMPS during the SECDISPATCH session at IETF 101 in London:

   1) draft-nir-saag-star: SECDISPATCH suggested that the LAMPS WG take on short-lived certificates as an additional work item.

   2) draft-housley-cms-mts-hash-sig: SECDISPATCH suggested that the LAMPS WG take on hash-based signatures for CMS as an additional work item.

Second, at the end of the LAMPS session at IETF 101 in London, three topics were raised as possible new work items:

   3) <no-draft>: the need for revocation request format.

   4) draft-truskovsky-lamps-pq-hybrid-x509: certificate extensions for quantum resistant keys and signatures.

   5) draft-housley-cms-mix-with-psk: a way to mix a pre-shared key with traditional key transport and key agreement algorithms.

Third, the Security ADs have asked that we consider a document that was headed for the independent stream:

   6) draft-housley-hash-of-root-key-cert-extn: a way to manage key rollover for a root CA.

The current charter give some guidelines for the work items that belong in LAMPS:

   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.

Which of these potential work items have a "known constituency" and are likely to see "real deployment"?