Re: [lamps] Potential Topics for LAMPS Recharter

Phillip Hallam-Baker <phill@hallambaker.com> Mon, 02 April 2018 14:51 UTC

Return-Path: <hallam@gmail.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 DEB0F12D7F7 for <spasm@ietfa.amsl.com>; Mon, 2 Apr 2018 07:51:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 gyCSGI1vkWjA for <spasm@ietfa.amsl.com>; Mon, 2 Apr 2018 07:51:43 -0700 (PDT)
Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7002712D80F for <spasm@ietf.org>; Mon, 2 Apr 2018 07:51:43 -0700 (PDT)
Received: by mail-oi0-x22c.google.com with SMTP id u141-v6so13054080oif.1 for <spasm@ietf.org>; Mon, 02 Apr 2018 07:51:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=pORZygJrKssZqCtrSQgOblvRV1dioofi8opmIeNmeNM=; b=raQQEreAr3q9Knn9loAb1LQxoFy+yJOZ0N58oxG3KX9s/wtfaXgphD/xFB9FQyoCwl rGOqf28oTfVCCyiSC9pAnWa4UjlpIXMlpxGbveSzD4m+pSf04Ovn9da7xh6oYydUCH8n YeLEJqwWThLTGu4K5DrCS0D4UUcekAdg2t4IOyyc8PgIyIzWgIOwvLv/L4f0lMqbczEC 2Qyi+5uaxTIiWoMVuqq9TiihkrPbiGoyY8USbm+e7H9WWxAKRcuiFMlPDwjn/0jJ6SYv wpsfpnQfffwRDrQVgmwyfuzLwP4ZUMaP4msBOHAd5kBJO9lwWB6pIsdJOLC+WBP7ZDHQ MMwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=pORZygJrKssZqCtrSQgOblvRV1dioofi8opmIeNmeNM=; b=MwepIFw83pt8o+U9QYHz98rY2b4smV6HaQqLZ1xmt4P4iU0WBSr81RtWjSg+KiA7y5 rjnte82AOGz3hawRy3QSKPuUFV6jNQMfbzYiRf3+FO5eLmxTwA2aHiZFXGKxWCjr2pOP FchEpeBMBGjma2cFICAsT1KZBFMfqMpaCnslHMpBSH9Q2ulR+f9VnZPiiOIiSF2CBuuc rCXmQFkOZ9767ZUK8oJBvo7ZhCcHQGnwiePGmy6Ckdloo6LJM47estBXZDUd6MprEi9v oYYdiCWSTe2IJdtGbKciwiNRUyyFEzAqdR6oWuD6clVC0S1VzPoGX+nB+nk9JQqcf2Gm 8uIQ==
X-Gm-Message-State: ALQs6tDVVsHmcN8OFTIBABgHohlrlhmcaC80Z49MXeIa8KsIsUrDpu+s m6yJzvjA//DYWOiIMeYkAXUpj7AI98pR193xHmk=
X-Google-Smtp-Source: AIpwx4/ehXG1Y1d7HJ3aj6Vp60Edxk2Bfdip4/eZDUmoBum6+o+x2lkDHV/3qWH8FYxa27zTyGS6o9E8VC5IAgp+7Uw=
X-Received: by 2002:aca:6243:: with SMTP id w64-v6mr1123335oib.26.1522680702575; Mon, 02 Apr 2018 07:51:42 -0700 (PDT)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 2002:a9d:233c:0:0:0:0:0 with HTTP; Mon, 2 Apr 2018 07:51:42 -0700 (PDT)
In-Reply-To: <d8b67f78-4e46-a85f-4bc7-2065aaf90c6c@cs.tcd.ie>
References: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> <d8b67f78-4e46-a85f-4bc7-2065aaf90c6c@cs.tcd.ie>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Mon, 02 Apr 2018 10:51:42 -0400
X-Google-Sender-Auth: QUb9PCZl1C3fg3nwUxija7iRBB4
Message-ID: <CAMm+Lwj6h+UGkPEokMW4v31xYziRQnHsnv1d0PJozFJvxtEbbA@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Russ Housley <housley@vigilsec.com>, LAMPS <spasm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000622a020568deba79"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/xNHtBqVI7RDieM5UGehBwqvj_iA>
Subject: Re: [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: Mon, 02 Apr 2018 14:51:52 -0000

On Mon, Apr 2, 2018 at 10:34 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie>
wrote:

>
>
> On 30/03/18 19:05, Russ Housley wrote:
> > 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.
>
> As I said at the mic in London, I support this work being done
> in the IETF, but I'm not sure LAMPS is a good choice. It's not
> a *terrible* choice, but doing this in LAMPS is a bit odd as I
> for one would argue that an experimental RFC could be the right
> target for this work and that seems like a mismatch with the
> LAMPS charter.
>
> Re-chartering LAMPS to allow for this kind of work also seems
> to me to risk hitting the PKIX problem where we end up with a
> WG that's a catch-all for anything related to PKI. I figure
> that'd be a bad plan, but others may disagree.
>
> In summary, I think maybe SUIT is a better match for hash-based
> sig work, given that s/w signing is the likely use-case for
> these schemes. That said, I'm not subscribed to SUIT so don't
> know if there's real interest from participants there either.
> I'd also be fine if the ADs spun up a new short-lived WG just
> for this work.
>
> FWIW, if the end result here is to do this work in LAMPS, I
> won't whine about that. (I may whine if this WG really starts
> turning into PKIX++ though:-)
>

‚ÄčI agree that PKIX became a problem. But a large part of the problem was
that PKIX became a brand in the industry and so implementing 'all of' PKIX
became an issue.

I don't see SUIT as a good fit. First, I don't think we are ready to use
these sigs for software signing, I think we would be using them for
authenticating roots of trust to be used in extremis. To go beyond that
narrow remit openeth up a very large problem space. We would have to go
through the whole issue of how to bootstrap QR crypto applications.

I do not think we need to go any further at this stage than to convince
ourselves that we tell people to create sufficient signing capacity to
support the ability to bootstrap.

The way I would like to containerize the problem is:

LAMPS: Itsy bitsy extension to certificate signing certs to embed QR
signature bootstrap
IRTF: Propose QRKI (Quantum Resistant Key Infrastructure) and bootstrap (a
five year mission)