Re: [lamps] Draft LAMPS Recharter

Phillip Hallam-Baker <> Thu, 03 May 2018 11:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2FA1812D875 for <>; Thu, 3 May 2018 04:47:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f48ozifLGQ2y for <>; Thu, 3 May 2018 04:47:05 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 027BA124E15 for <>; Thu, 3 May 2018 04:47:05 -0700 (PDT)
Received: by with SMTP id t27-v6so15776590oij.9 for <>; Thu, 03 May 2018 04:47:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=S1DksWtnDF6KuWFEtHkBcFSzeu6cIm63HAL9imhsMV0=; b=OuYl1vtKiB35Qoqfmzy/tMgj9S70pRflr0LKSxXT2IgI94kzTYw+v+Mn+N/WO09dXx gg/x8Bz7uqAcZbc8n5S/Sga1xFntmzMHwNYmZmnWNOOd8tMUpnMVSePu6PZ898huEapc GqqBGkpXnRgJ00nD/EIGkofhxJMe1yuAN4hSIQlfY/cH0ryqaApQc7vfMsafnJFeWPGW 9uyDqKJZCqoma4kUXB4eeMYYGmBt0MQIl/qSrwon/8hyryLh0Te5AXI5CrsRvTIcnRm3 QmRD92sBmlggO5iTcnEsD/uxqOfh+YmP6oJFAIpNM8dHw27i3N2czOfaj14iOkUT95T7 cTqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=S1DksWtnDF6KuWFEtHkBcFSzeu6cIm63HAL9imhsMV0=; b=Ak8XVVQumltAVzQ9YauKXZDXidtOPKbrDgVfNpT+j/8PZJqHgr3sF/vkNqPP5WSD9f eQ+izYID5+KFKo0eAwvv/AuTafkt+KQn8XHga1xAKoM8Qgh7p0WzInIJFN8xn6KNOdjR 1gh93rgz35cNNU6C/6Y9boNEUvZXhhqmgKjwrQNaXse27bF3P9G3him2lbbjvBiSnfEO 4BIJ+2X6i69FtOaE4S+G/SPt5oJZ6XW66azgzfmlSftJY6FzS0VmezbleIBl1E1ZdGnM ByMCz6D+dXW4VkFxMQFb3vGsiA6ZpJ0Mn4g7e3fIGxbVJaDm9vaaRHNA2bWlC0Xa4Cpe stgw==
X-Gm-Message-State: ALQs6tB1ODTR3RTG+sR2EUU1S6QqqgSI6Ifzvfa78zlUDpOMkUFy6ais M/rq5Ay+w1pD+gJhyUbff5ihsv1S/rsaod6q8oU=
X-Google-Smtp-Source: AB8JxZrH7msDeEib1EQqp7HJZPhayPrd9y5DsG/xBaab9BaZyLxVzNsVL6IEL+OT4T4TNq7mfmVj54tc5cV385rr+io=
X-Received: by 2002:aca:6257:: with SMTP id w84-v6mr2789331oib.26.1525348024239; Thu, 03 May 2018 04:47:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:3283:0:0:0:0:0 with HTTP; Thu, 3 May 2018 04:47:03 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Phillip Hallam-Baker <>
Date: Thu, 03 May 2018 07:47:03 -0400
X-Google-Sender-Auth: RGys-LLgZ5J_rLf0jMGWvJcv8G4
Message-ID: <>
To: Ryan Sleevi <>
Cc: Yoav Nir <>, LAMPS <>, Russ Housley <>
Content-Type: multipart/alternative; boundary="00000000000024cc06056b4bc3ca"
Archived-At: <>
Subject: Re: [lamps] Draft LAMPS Recharter
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 May 2018 11:47:08 -0000

On Wed, May 2, 2018 at 10:19 PM, Ryan Sleevi <> wrote:

> On Wed, May 2, 2018 at 5:20 PM Yoav Nir <> wrote:
>> On 3 May 2018, at 0:06, Ryan Sleevi <> wrote:
>> On Wed, May 2, 2018 at 10:41 AM, Russ Housley <>
>> 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.
>> As a practical matter, the draft acknowledges an alternative design
>> (namely, OCSP stapling), but its two objections to this work do not hold.
>> As a consequence, I have concerns about the motivations for and the
>> alternatives considered, and thus don't think LAMPS needs to consider such
>> work in scope at this time.
>> Hi, Ryan.
>> The main motivation for me is things other than the Web PKI. There is
>> nothing in the draft that makes it not work for the Web PKI, but I would
>> like to leave it to the group to decide whether the Web PKI is explicitly
>> excluded.
>> There is a short-term certificate document that *is* for the Web PKI. It
>> is in the ACME working group.
> <>
>> Despite having some authors in common, the use cases are different.
> I’m curious to understand more of these use cases, as to understand the
> presumed implementors for the running code. I’m guessing that, given the
> goal just presented, these are going to be locally managed CAs and/or for
> server-to-server mutual auth scenarios?
> My biggest qualm is that the draft seems predicated on two statements
> about why existing technology is insufficient:
> 1) OCSP Stapling requires servers to support Stapling
> 2) Client certs cannot staple
> There doesn’t seem to be any explanation as to why #1 doesn’t equally
> apply (if not moreso?) to this use case, given the need to replace the
> certificates frequently due to their short lifetime. The efforts towards
> ACME-STAR are illustrative of exactly that - a need for new management
> capabilities.
> With regard to #2, I’m trying to understand how this compares to TLS1.3’s
> restructuring of the Certificate message, which seems like it will have a
> significantly broader adoption and a lower barrier to adoption, especially
> in the case of client certs.
> While presented as specific examples, I think they more generally speak to
> a lack of definition as to the problem space or audience within the current
> draft, thus making it difficult to see how adoption, implementation, or
> consensus will emerge. While personally skeptical of the idea, I fully
> accept that there may be some non-WebPKI use cases for this that could
> benefit from this work, but it seems like nailing those down and
> identifying them should be encouraged as a prerequisite for adoption. In
> particular, it seems like fleshing how this is meaningfully different in
> use case or deployment from existing technologies such as OCSP Stapling
> seems good, so as to prevent an unnecessarily proliferation of ways to
> solve the same basic problem..

​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.

With a short lived cert:

* The server has to update its cert every days.
* The client has to process the cert.

I do not understand where client certificates come into the argument.
Obviously, the same approach may be applied to client certs but why would
anyone bother when the browser UI for client auth is so utterly useless?

I don't want to get into business models but I will observe that my
employer is making good money by adding back features some folk have dissed
over the years.