Re: [wpkops] draft-housley-web-pki-problems-00

Phillip Hallam-Baker <> Tue, 07 July 2015 20:04 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EA27E1A8A1F for <>; Tue, 7 Jul 2015 13:04:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tFSyQ-Ov6AlN for <>; Tue, 7 Jul 2015 13:04:17 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B206C1A8A09 for <>; Tue, 7 Jul 2015 13:04:16 -0700 (PDT)
Received: by lagx9 with SMTP id x9so209696113lag.1 for <>; Tue, 07 Jul 2015 13:04:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=rYdkso5YSE8Y+uxPM4QOJh0KnbZOvgZDzjbevhXLQQI=; b=AIHUxqpNKjvu05E7laYS3hs+7xaE8USo3jDDwcV3Ci2mfXAXBXPvQSA7cO+uZQZkWx zRUmAkFHWsKZxi4DAKovGBpiNH9TVr1KtZAoXQiemLnYWBcZPXLed+q8nlxBST2K74hw 2qIkHkqGsPqGajZvdt3JAWHtWUXajYLpbss2P8EpnkK56B5W2Jx9c86kNaxFpv1rfZgT 4YbSX+9j69v1veklQ6M5qi4nYkx1TAHkWgpgK5S6kqqGDVrcsUe3f37qhnFquDH6r0Y9 Ux33xcTQUGxF4i3JrFSlYAVGGF7zj6r0LMuSiI13zmhPU9YMwtrYzwXS3VqpTLhjkt1n kdNQ==
MIME-Version: 1.0
X-Received: by with SMTP id w1mr5666939laz.124.1436299455157; Tue, 07 Jul 2015 13:04:15 -0700 (PDT)
Received: by with HTTP; Tue, 7 Jul 2015 13:04:14 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Tue, 7 Jul 2015 16:04:14 -0400
X-Google-Sender-Auth: kDgBpiNzPI5KUmnaAQCX-kyBpwA
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Jeremy Rowley <>
Content-Type: multipart/alternative; boundary=001a11c33dded0ddac051a4e86cc
Archived-At: <>
Cc: "" <>, Russ Housley <>
Subject: Re: [wpkops] draft-housley-web-pki-problems-00
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 Jul 2015 20:04:19 -0000

On Tue, Jul 7, 2015 at 3:36 PM, Jeremy Rowley <>

> This paper sounds like a wish list of select issues taken from the Mozilla
> forums.  I don't see why it would be published as informational RFC? Is the
> goal to make a list of issues that community members feel need to be
> discussed? I don't get it.
> The conclusions seem to be 1) Have a CAB Forum that is more transparent
> (which is out of scope of the IEFT - I'm not sure I've ever seen an IETF
> paper specifically call out to another industry body requesting a change in
> its membership?) and 2) Use Let's Encrypt - one specific member of the CA
> community.  Many CAs already offer free tools to automate issuance, making
> the call out to Let's Encrypt very odd in an IETF document, especially
> where the touted feature - new automated tools - already exist (
>  I have a similar complaint
> about the reference to acme where PHB has been proposing something similar
> for a LONG time (
> I'm also not sure why you selected the specific issues for inclusion in
> the paper. For example, the paper doesn't mention inconsistencies in
> validation levels, which (imo) is a bigger issue than the "too big to fail"
> scenario. Cost also is a weird issue to include in the document since it's
> always relative.  It's also very difficult to discuss without running afoul
> of anti-trust laws.

I have a slightly different concern about the mention of CABForum.

CABForum was originally started to develop industry standards for
Organizational Validation certs which turned into EV certs over time. As
such I always regarded it as a successor in spirit to the ABA group that
Michael Baum used to run.

CABForum is not set up as a governance body. It does not manage a trust
store or decide on inclusion of trust roots. It isn't an industry
association either, there is a separate body that has that role.

I think that the problem the paper identifies is actually a more
fundamental issue with the WebPKI, the fact that browser providers are not
ideally placed to act as curators of trust stores because they have two
conflicting concerns: security and interoperability.

While browsers do their best to achieve a balance between those concerns,
they can't be expected to provide customized tradeoffs for different
purposes. It is inevitably one size fits all.

One of the ways I am looking to address this in the mesh is to provide a
mechanism that allows individual users more control of their network
environment by defining a custom network profile that can be easily
transferred from one device to another.

In ordinary circumstances, it is not practical for a user to manage a
custom set of WebPKI roots on each of their machines or for that matter to
delegate that configuration to a trusted party.