Re: [lamps] Draft LAMPS Recharter
Ryan Sleevi <ryan-ietf@sleevi.com> Thu, 03 May 2018 14:41 UTC
Return-Path: <ryan-ietf@sleevi.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 9E19E12E89C for <spasm@ietfa.amsl.com>; Thu, 3 May 2018 07:41:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 f_xwVXgzfMGB for <spasm@ietfa.amsl.com>; Thu, 3 May 2018 07:41:26 -0700 (PDT)
Received: from homiemail-a89.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68A0612E8A0 for <spasm@ietf.org>; Thu, 3 May 2018 07:41:26 -0700 (PDT)
Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id B96154000100C for <spasm@ietf.org>; Thu, 3 May 2018 07:41:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=rH2kSdxTKp5aG0y2ry0tKeqau3E=; b= RLOnVZUYMDFjl2XhcQRm+Jg0czZL8Sg0ewWEz/XhAaokZNO9U+tcndL8Il8NUJNl iGtiBc4Yy+AKHza5hSfN5/C1JdQBu+MRk67IhzlDkw2Lsk/z6Tz05DeQJHLdRHoc Yg54u/Mwwu8WN2MYH38SNo/6I05v3KU4LBHEtbauktw=
Received: from mail-it0-f46.google.com (mail-it0-f46.google.com [209.85.214.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id D742940001008 for <spasm@ietf.org>; Thu, 3 May 2018 07:41:24 -0700 (PDT)
Received: by mail-it0-f46.google.com with SMTP id f65-v6so18121123itd.3 for <spasm@ietf.org>; Thu, 03 May 2018 07:41:24 -0700 (PDT)
X-Gm-Message-State: ALQs6tA7ui6JNyPCTLcoQxnZb2qlYIYwirJ9072GXmYfxbLWMS+GQLUl kSu/p0pIUg6QCuBXPoqs4w+8iYN15kWXp28257s=
X-Google-Smtp-Source: AB8JxZrHMmkc6BMKkg09nFAayfg1WoMAfGRbvO8tmy+fVZ/5z3E3TOA7TMsIGbnWJfKH2c1VDQ+ZKbUXp19JcasC3xo=
X-Received: by 2002:a24:d88b:: with SMTP id b133-v6mr23839815itg.119.1525358484281; Thu, 03 May 2018 07:41:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a02:985a:0:0:0:0:0 with HTTP; Thu, 3 May 2018 07:41:23 -0700 (PDT)
In-Reply-To: <CAMm+LwjSTBfV32NT66_vA=EX4OPnx5qxYjbHG92NVzJpCwq8nw@mail.gmail.com>
References: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com> <CAErg=HF40T1CLuu=5GebtsvFMphtSRyK+O5TpTn0pTz1v9jMgQ@mail.gmail.com> <64CD1067-8639-4C2C-A8EC-ED5FBC14F633@gmail.com> <CAErg=HHXj4tVoQ06Z_ZNJKnCF9efd64DOx5Hf_sLaqATX6+OWQ@mail.gmail.com> <CAMm+LwhkugUvtd_rmbXYDXCzBhKD=fc7gbxpWeSzzasmGFDFZw@mail.gmail.com> <CAErg=HF89sRyUrYcqcG=_onnW_NnsyNN2CKWQ8ty=Xb_v8nOkw@mail.gmail.com> <CAMm+LwjSTBfV32NT66_vA=EX4OPnx5qxYjbHG92NVzJpCwq8nw@mail.gmail.com>
From: Ryan Sleevi <ryan-ietf@sleevi.com>
Date: Thu, 03 May 2018 10:41:23 -0400
X-Gmail-Original-Message-ID: <CAErg=HFaS1g-S2zu04sCXZ_58OUPJ26Tg0RzS1V4UkTWejfO9Q@mail.gmail.com>
Message-ID: <CAErg=HFaS1g-S2zu04sCXZ_58OUPJ26Tg0RzS1V4UkTWejfO9Q@mail.gmail.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>
Cc: Ryan Sleevi <ryan-ietf@sleevi.com>, LAMPS <spasm@ietf.org>, Russ Housley <housley@vigilsec.com>, Yoav Nir <ynir.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000009c62b4056b4e3245"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/paYqxqRL1LEEPgwOuGmUVB8V6lE>
Subject: Re: [lamps] Draft 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: Thu, 03 May 2018 14:41:29 -0000
On Thu, May 3, 2018 at 10:00 AM, Phillip Hallam-Baker <phill@hallambaker.com > wrote: > > > On Thu, May 3, 2018 at 9:25 AM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote: > >> >> On Thu, May 3, 2018 at 7:47 AM Phillip Hallam-Baker < >> phill@hallambaker.com> wrote: >> >>> >>> The reason to move to short term certs is simple and has nothing to do >>> with insufficiency: It is simply more efficient. >>> >>> Once you automate the process of certificate management, the move to >>> short lived certs is inevitable and obvious because then the server only >>> needs to cope with a single data object rather than two equivalent data >>> objects. >>> >>> With a long lived cert plus OCSP: >>> >>> * The server has to update its cert every X days and update its OCSP >>> token, a different code path, every day. >>> * The client has to process the cert and then process the OCSP token, >>> each of which has a separate trust path. >>> >> >> To make sure I understand this claim: Is the view that adding yet another >> method, which is not as expressive and with a host of trade offs, will >> somehow payoff at some point in the future in which clients and servers no >> longer have to implement or care about revocation data? >> > > Short lived certs are exactly as expressive as long term plus OCSP with > pre-generated validity tokens. > > While the intent of the original OCSP proposal (which I wrote the draft > for and can thus speak with authority) was to enable insurance of > individual transactions, I am not aware of any use of OCSP for that > purpose. Nor do I expect any such use to arrive in the future as we > subsequently developed the TAXI (Trust Assertion XML Infrastructure) for > that purpose which is now known as SAML. > > I would rather like to think “the spec is prettier if we do it this way” >> is a poor justification for taking on work, so I was hoping a bit more >> substance to a reply. >> > > Simpler is better. > > Changing practice in the browser world is certainly possible but has a > long payback time as it takes quite a while for browsers to update. > > Instituting best practice for Web Services is a totally different matter > as there are new services being deployed every day and those that exist are > often kept up to date very aggressively. > While we may disagree as to whether this work is simpler - the draft I think demonstrates that it's not, in practice, for any party involved (relying party, CA, or service operator). However, I think there's something to your point here which gets to the heart of whether LAMPS should be undertaking this work. This is now the second message that you've referenced the "browser world". While the initial replies suggested non-browser/non-WebPKI case, which may be perfectly reasonable, I'm trying to fully understand your position: Is it that this work is intended for the browser case? If browsers explicitly prohibit the use of such work, or reject implementation, does that undermine or devalue the work and implementation experience? Because I do not see this being supported in browsers, and I think it's extremely likely of being explicitly forbidden. I highlight this in order to make sure there's consensus on what the draft is for - since the draft itself leaves it ambiguous - and whether or not there's a representative sample of implementors for that target use case. The nature of this question is what plagued PKIX, and if we're trying to ensure that LAMPS does not succumb to the overbroad, unadopted, zombie effort that WGs can succumb to, then my $.02 we should make sure that the goal and uses are as crisp as possible before adopting that work as a WG. We can (and should) work out the "How" as a WG document, but the "Why" seems like it should be addressed before adopting and incorporating into the charter.
- Re: [lamps] Potential Topics for LAMPS Recharter Russ Housley
- Re: [lamps] Draft LAMPS Recharter Erik Andersen
- [lamps] Potential Topics for LAMPS Recharter Russ Housley
- Re: [lamps] Potential Topics for LAMPS Recharter Tim Hollebeek
- Re: [lamps] Potential Topics for LAMPS Recharter Stephen Farrell
- Re: [lamps] Potential Topics for LAMPS Recharter Erik Andersen
- Re: [lamps] Potential Topics for LAMPS Recharter Phillip Hallam-Baker
- Re: [lamps] Potential Topics for LAMPS Recharter Panos Kampanakis (pkampana)
- Re: [lamps] Potential Topics for LAMPS Recharter Tim Hollebeek
- Re: [lamps] Potential Topics for LAMPS Recharter Russ Housley
- [lamps] Draft LAMPS Recharter Russ Housley
- Re: [lamps] Draft LAMPS Recharter Panos Kampanakis (pkampana)
- Re: [lamps] Draft LAMPS Recharter Russ Housley
- Re: [lamps] Draft LAMPS Recharter Ryan Sleevi
- Re: [lamps] Draft LAMPS Recharter Russ Housley
- Re: [lamps] Draft LAMPS Recharter Yoav Nir
- Re: [lamps] Draft LAMPS Recharter Ryan Sleevi
- Re: [lamps] Draft LAMPS Recharter Phillip Hallam-Baker
- Re: [lamps] Draft LAMPS Recharter Eric Rescorla
- Re: [lamps] Draft LAMPS Recharter Ryan Sleevi
- Re: [lamps] Draft LAMPS Recharter Ryan Sleevi
- Re: [lamps] Draft LAMPS Recharter Phillip Hallam-Baker
- Re: [lamps] Draft LAMPS Recharter Ryan Sleevi
- Re: [lamps] Draft LAMPS Recharter Stephen Farrell
- Re: [lamps] Draft LAMPS Recharter Tim Hollebeek
- Re: [lamps] Draft LAMPS Recharter Russ Housley
- Re: [lamps] Draft LAMPS Recharter Jim Schaad
- Re: [lamps] Draft LAMPS Recharter Salz, Rich
- Re: [lamps] Draft LAMPS Recharter Daniel Van Geest
- Re: [lamps] Draft LAMPS Recharter Russ Housley
- Re: [lamps] Draft LAMPS Recharter Daniel Van Geest
- Re: [lamps] Draft LAMPS Recharter Russ Housley
- Re: [lamps] Draft LAMPS Recharter Daniel Van Geest