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

Phillip Hallam-Baker <ietf@hallambaker.com> Tue, 07 July 2015 20:04 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: wpkops@ietfa.amsl.com
Delivered-To: wpkops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA27E1A8A1F for <wpkops@ietfa.amsl.com>; Tue, 7 Jul 2015 13:04:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFSyQ-Ov6AlN for <wpkops@ietfa.amsl.com>; Tue, 7 Jul 2015 13:04:17 -0700 (PDT)
Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B206C1A8A09 for <wpkops@ietf.org>; Tue, 7 Jul 2015 13:04:16 -0700 (PDT)
Received: by lagx9 with SMTP id x9so209696113lag.1 for <wpkops@ietf.org>; Tue, 07 Jul 2015 13:04:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.152.87.97 with SMTP id w1mr5666939laz.124.1436299455157; Tue, 07 Jul 2015 13:04:15 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.203.163 with HTTP; Tue, 7 Jul 2015 13:04:14 -0700 (PDT)
In-Reply-To: <8d66da4eb5d24bb89f8d6b934640ea61@EX2.corp.digicert.com>
References: <28D7CC3C-E21C-4D01-8F13-F2D661D82D71@vigilsec.com> <8d66da4eb5d24bb89f8d6b934640ea61@EX2.corp.digicert.com>
Date: Tue, 7 Jul 2015 16:04:14 -0400
X-Google-Sender-Auth: kDgBpiNzPI5KUmnaAQCX-kyBpwA
Message-ID: <CAMm+LwgBHoQfFqmQQcudQo_4_Fq6Np+=Hu6xEiEG3DAz-n_iig@mail.gmail.com>
From: Phillip Hallam-Baker <ietf@hallambaker.com>
To: Jeremy Rowley <jeremy.rowley@digicert.com>
Content-Type: multipart/alternative; boundary=001a11c33dded0ddac051a4e86cc
Archived-At: <http://mailarchive.ietf.org/arch/msg/wpkops/nPr6A2E1NLyJzznB0JaOUfVwLhU>
Cc: "wpkops@ietf.org" <wpkops@ietf.org>, Russ Housley <housley@vigilsec.com>
Subject: Re: [wpkops] draft-housley-web-pki-problems-00
X-BeenThere: wpkops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <wpkops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wpkops>, <mailto:wpkops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wpkops/>
List-Post: <mailto:wpkops@ietf.org>
List-Help: <mailto:wpkops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wpkops>, <mailto:wpkops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jul 2015 20:04:19 -0000

On Tue, Jul 7, 2015 at 3:36 PM, Jeremy Rowley <jeremy.rowley@digicert.com>
wrote:

> 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 (
> https://www.digicert.com/express-install/).  I have a similar complaint
> about the reference to acme where PHB has been proposing something similar
> for a LONG time (
> https://tools.ietf.org/html/draft-hallambaker-omnibroker-06).
>
> 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.