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 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-Level: 
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 ([4.31.198.44])
 by localhost (ietfa.amsl.com [127.0.0.1]) (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 [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 0C23312420B
 for <spasm@ietf.org>; Fri, 30 Mar 2018 11:05:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
 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 ([127.0.0.1])
 by localhost (mail.smeinc.net [127.0.0.1]) (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
 [108.45.101.150])
 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=20=

   Group is chartered to make updates where there is a known =
constituency=20
   interested in real deployment and there is at least one sufficiently=20=

   well specified approach to the update so that the working group can=20=

   sensibly evaluate whether to adopt a proposal.

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

Russ