Re: [lamps] Draft LAMPS Recharter

Phillip Hallam-Baker <> Thu, 03 May 2018 14:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E677612E047 for <>; Thu, 3 May 2018 07:00:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Status: No, score=-1.398 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q5eoAf4GT6yQ for <>; Thu, 3 May 2018 07:00:52 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c0f::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 67AD312E03E for <>; Thu, 3 May 2018 07:00:52 -0700 (PDT)
Received: by with SMTP id m11-v6so14559262otf.3 for <>; Thu, 03 May 2018 07:00:52 -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=kRlr6UAcs8q2B8DHUgOBTOfNEkkFStJfgd1lFZwURKQ=; b=Rtv9UYfUub7ztss63HI74h5c/OHooX7gv+ZNpMVPZQONtUrGram9dG7hQxavzf81xq 9HjT3hJlHOycXzqNO7u2z7RWxsdKd6LmaXiEfk7ZhKEuGlUYKv74R3MkXfPYdwQFlad+ JuTOfaLicfwLEtRW8IijCeyBz/VzRoQ9129nSB+VIEyFJRVJbkF34D/Yl3Unj+5aCduh OhzpQV6BSKGl4X+lxA3p3QSHzaY5Z7WX+MqRuDMqVzlzIAK9VaZW1hH13kyp7O4XM9C5 1NkhP/d+bFLYLHtVWR3Gei8moHMzwsTaitmmBn6J6vsEGS1vMzOySYFXU4pehH39ulSe T14g==
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=kRlr6UAcs8q2B8DHUgOBTOfNEkkFStJfgd1lFZwURKQ=; b=P2l8F6knAyahNrj08DtagRK23bT/VgrZJeIOKBT4uU97Asi/9fm9KRG4UZEH/blDZm 8InigjhQb1v2SbMxvfjA1HzfFISnde6Z+S5KwavcLLGwGXbKLJL8nQL02wlRYQjOjGvR fj0CY0TnQRjVBI2W2Wg/LAGcKfG2rHMUWGkI3FfPWbyAy9TLwDGmW3y2RJpTxEaV2UVx U+BxNNoVAJWhwrF3C6JUElGh0wuFAfQ5t/aDFSL6FyPebPXBD4d1BIOCABX5X8FWYg+j twnV57F3e4wlT8jnDfqWG21Q7nKKPke/EOPnrtEc2mctSYfesoZoScjnI756zy5p6cpY SBcQ==
X-Gm-Message-State: ALQs6tC98Fe+YJvRET4OfsWiyRgt1n2bwJNEznC/ssP9VaqwyECytQU7 84KYtzzIW98/MnOqZJCAtK4YWD+0wdd7+vCKDKY=
X-Google-Smtp-Source: AB8JxZoX1H+coOCmS8V+hlm5XPRK8JWwAriVi/l5EjKBH2gYbE+RBRaE5qiELFBY59xSNHiFXpdglrH2/FcBHVL2O68=
X-Received: by 2002:a9d:2083:: with SMTP id x3-v6mr509454ota.338.1525356051398; Thu, 03 May 2018 07:00:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:3283:0:0:0:0:0 with HTTP; Thu, 3 May 2018 07:00:50 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: Phillip Hallam-Baker <>
Date: Thu, 03 May 2018 10:00:50 -0400
X-Google-Sender-Auth: Yww1XkFJURpxpduJdx5zT7-lcd8
Message-ID: <>
To: Ryan Sleevi <>
Cc: LAMPS <>, Russ Housley <>, Yoav Nir <>
Content-Type: multipart/alternative; boundary="000000000000998618056b4da1f1"
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 14:00:55 -0000

On Thu, May 3, 2018 at 9:25 AM, Ryan Sleevi <> wrote:

> On Thu, May 3, 2018 at 7:47 AM Phillip Hallam-Baker <>
> 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.

> 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?
> It’s unclear: you read the draft and are disagreeing with it, or did you
> read me reply and weren’t aware I was referencing the draft? The mention of
> browsers leads me to believe the latter, because the message I was replying
> to identified this work was not for the Web PKI, but if the former, I’m
> hoping to bring a bit more clarity to the position.

​At this point in time, PKIX has established itself as a mechanism ​for
supporting server authentication. PKIX has not established itself as a
mechanism for user authentication. SAML has been vastly more successful in
that role. And I do not see that changing.

TLS Client auth is not very useful as a means of authenticating users in a
Web browser but it is very widely used as a means of authenticating
Services to other Services.

The distinction between 'client' and 'server' is not very useful here
because all a 'client' is, is the party that initiates a transaction. PKIX
is for authenticating services whether to users or to other services and
regardless of whether it is the initiator or responder in a transaction.

Of course we need to move to short lived certs for services because in the
modern deployment, a service typically lives on a particular host for a
matter of a few days or even hours. Generating keys valid for up to 2 years
and then churning them round a data center simply means that every machine
in that data center is a potential point of compromise.

An obvious control to help mitigate this problem is to limit cert validity
to the length of time we expect the service to remain on a particular
machine and to generate new keying material every time the service moves to
a new host.