Re: [lamps] Draft LAMPS Recharter
Ryan Sleevi <ryan-ietf@sleevi.com> Thu, 03 May 2018 13:34 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 7A4C9124C27 for <spasm@ietfa.amsl.com>; Thu, 3 May 2018 06:34:35 -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 y5mdtQ7yEUak for <spasm@ietfa.amsl.com>; Thu, 3 May 2018 06:34:33 -0700 (PDT)
Received: from homiemail-a86.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 96971120454 for <spasm@ietf.org>; Thu, 3 May 2018 06:34:33 -0700 (PDT)
Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 06A839000C3F for <spasm@ietf.org>; Thu, 3 May 2018 06:34:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=ae2NvR/uaoojfOt3VrDeFb3kMk4=; b= goz5nm3UiCvOjELD696WYZRunlixGKu34eo3PYlcD/1CXIuxZW1zslngf7TeiI+W /A1BCsqQzDrefmDNYXZ6l4y+EasYG2P9PkHXbsWBHtbfce4eD9W14C5THMQaEnqh eM9wYLF0DBPwZ1u0h+MDI/hbBoUrTnxMqS8mwI4mWpI=
Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id BC2B59000C3B for <spasm@ietf.org>; Thu, 3 May 2018 06:34:32 -0700 (PDT)
Received: by mail-io0-f169.google.com with SMTP id e20-v6so21636026iof.4 for <spasm@ietf.org>; Thu, 03 May 2018 06:34:32 -0700 (PDT)
X-Gm-Message-State: ALQs6tDMOv2hRp/MtFuQT42HtBvnWUTtX8vPeEnFxPpGuu3qtdQsdkAx KjPjtH1QOmU8FW9c7qNHaiiFXJWSbx48XhZ0Q94=
X-Google-Smtp-Source: AB8JxZq2fURjySCzfIEu95LVRzsgRz5Y6cL9BOKmkBuNaA5ob8ZnoYi8A3IbNTI/NmMR0r4ygxHNtwSKtN6pV8uhxG4=
X-Received: by 2002:a6b:1248:: with SMTP id a69-v6mr26227906ioj.159.1525354471768; Thu, 03 May 2018 06:34:31 -0700 (PDT)
MIME-Version: 1.0
References: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com> <CAErg=HF40T1CLuu=5GebtsvFMphtSRyK+O5TpTn0pTz1v9jMgQ@mail.gmail.com> <CABcZeBOfYRO+GB28c-kNBepxMDm6c_2bAzqWh5aPpJwO702G-w@mail.gmail.com>
In-Reply-To: <CABcZeBOfYRO+GB28c-kNBepxMDm6c_2bAzqWh5aPpJwO702G-w@mail.gmail.com>
From: Ryan Sleevi <ryan-ietf@sleevi.com>
Date: Thu, 03 May 2018 13:34:21 +0000
X-Gmail-Original-Message-ID: <CAErg=HHa91n11EaU9G5Y3A9cqaCA8gTYOdK-ZKP8qz=_i9cx2A@mail.gmail.com>
Message-ID: <CAErg=HHa91n11EaU9G5Y3A9cqaCA8gTYOdK-ZKP8qz=_i9cx2A@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: LAMPS <spasm@ietf.org>, Russ Housley <housley@vigilsec.com>, Ryan Sleevi <ryan-ietf@sleevi.com>
Content-Type: multipart/alternative; boundary="000000000000725c9c056b4d4334"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/ftZd0_Czn2vtopJbX86jPuzncIU>
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 13:34:35 -0000
On Thu, May 3, 2018 at 8:50 AM Eric Rescorla <ekr@rtfm.com> wrote: > On Wed, May 2, 2018 at 2:06 PM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote: > >> >> >> On Wed, May 2, 2018 at 10:41 AM, Russ Housley <housley@vigilsec.com> >> wrote: >> >>> Based on the discussion in London and the "Potential Topics for LAMPS >>> Recharter" mail thread. We propose the attached charter text. Please >>> review and comment. >>> >>> Russ & Tim >>> >>> = = = = = = = = = >>> >>> 3. 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 them pointless. >>> >> >> I didn't see much discussion on the list in support for this, but >> apologies, I missed the discussion in SECDISPATCH when this draft was >> discussed. >> >> Is this being envisioned for the use in the PKI typically called the "Web >> PKI", or is this being seen as a draft for private use cases? I have read >> the draft, and do not feel this was clearly and unambiguously answered. >> >> I ask because, for various policy reasons, I would expect that >> undertaking this work may result in policies that explicitly prohibit it >> from being deployed on the Web PKI. >> > > Ryan, > > Do you think you could elaborate on this point? > It seems a bit less germane to discuss potential root store policy here in the IETF, but there are already policies around lifetimes - such as maximum certificate lifetimes or minimum OCSP response validity durations. Despite being technically capable of issuance, I fully anticipate minimum lifetimes being required for certificate validity. Validity merely externalizes cost to PKI participants - too long a validity, for example, carries greater risk of both key compromise and information staleness. Models such as revocation try to remediate that, but shift more burden onto relying parties. Actions such as too short validity also shifts burden onto clients and the ecosystem - notably in terms of client clock issues, by increasing the precision and accuracy necessary. As it relates to the draft, however, it has further flaws in the design assumptions, similar to these concerns. For example, suggesting that CAs would be able to use shorter-lived certificates to no longer keep track of what they issue is fundamentally incompatible with a Web PKI in which every CA is accountable for what it issues: presently, for between five to seven years from issuance. This is orthogonal to things like Certificate Transparency, and is about operational requirements. I expect the floor for certificates to bottom out at around 21-30 days for publicly trusted certificates for the next decade, which potentially would be mandated by requirements on issuance policy. >
- 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