[therightkey] Using composite PKIs

Phillip Hallam-Baker <phill@hallambaker.com> Mon, 27 July 2015 15:03 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: therightkey@ietfa.amsl.com
Delivered-To: therightkey@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621931B2E68; Mon, 27 Jul 2015 08:03:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.423
X-Spam-Level: *
X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 W6JPPif3KBB2; Mon, 27 Jul 2015 08:02:59 -0700 (PDT)
Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (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 400641B2E66; Mon, 27 Jul 2015 08:02:58 -0700 (PDT)
Received: by lblf12 with SMTP id f12so55446519lbl.2; Mon, 27 Jul 2015 08:02:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=bsGt2pWZQfB36Ye2jJ0b83oYi0Qrl1agbnWlT000qvk=; b=p+lFYJTQga38NgYAbxfVYiPjoZxqVZfQNy11MtoMbu/77AJkhvzOYbshVNPQcp7MvA kbYqmoYGZA6PUngIytRw5hBm2G5SzmRg+BtF3QXk02PS13sFZAM/F8VyxDopmCQopLCb 0lBUnJFGEAUJG1C+9Q4NzEROGNuuNdE/F6zf9uff1uVJNQ8Uihvxw5IOLfrG6tbouBeb ulrymgpX5OYPF/FHtOv3IcPIoPoJtKZbbT58th2CbfJA1bKEwM1HXkX1EPhPl4v2PaFc ExJtnOrUofJh28lJdhiIH0HcpVFzQ6ewr5zvuehRioAhpsa9vpGU6RcYF+7lCn1JNpd7 QN0w==
MIME-Version: 1.0
X-Received: by 10.112.167.202 with SMTP id zq10mr26883850lbb.118.1438009376670; Mon, 27 Jul 2015 08:02:56 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.203.163 with HTTP; Mon, 27 Jul 2015 08:02:56 -0700 (PDT)
Date: Mon, 27 Jul 2015 11:02:56 -0400
X-Google-Sender-Auth: QqitSSf4Sy6cupiISgMnZKA_hvc
Message-ID: <CAMm+LwiGH9Oxg9s95ewaw1oqqn3YYR2nxZh9V2-B0X1FTKJP8w@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: "therightkey@ietf.org" <therightkey@ietf.org>, IETF OpenPGP <openpgp@ietf.org>, "dane@ietf.org" <dane@ietf.org>, smime@ietf.org
Content-Type: multipart/alternative; boundary="001a11c269c2148aae051bdca6ef"
Archived-At: <http://mailarchive.ietf.org/arch/msg/therightkey/-LX3HLJtnYSuIH7LTU4oUpI0XAA>
Subject: [therightkey] Using composite PKIs
X-BeenThere: therightkey@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <therightkey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/therightkey>, <mailto:therightkey-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/therightkey/>
List-Post: <mailto:therightkey@ietf.org>
List-Help: <mailto:therightkey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/therightkey>, <mailto:therightkey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jul 2015 15:03:01 -0000

[Followups on therightkey please]

Thinking about the discussion of the OpenPGP/DANE draft in OpenPGP in my
car, I came up with a metaphor for how to approach joining different PKIs.
In particular, Werner's comment that Web of Trust doesn't scale. The CA
model does scale but it isn't actually much better when trying to identify
private individuals rather than employees of a company since the only thing
I can validate economically is an email address and that isn't a person.

We can approach the problem mathematically by considering the work factor
(in US$) for causing a breach.

Combining Web of Trust with CA approaches and interning the assertions in
an immutable blockchain like log does provide an approach that scales. The
blockchain makes the workfactor time dependent. If the workfactor is $100
before an assertion is enrolled, it will be $trillions after.

Combining Web of Trust and CA trust is like building a dalek out of
fiberglass: Individually, the glass fiber and the epoxy are weak. But using
the two in combination locks the strands of glass fibre creating a
lightweight shell that can support the weight of a small truck. This part
is already written up:

https://datatracker.ietf.org/doc/draft-hallambaker-prismproof-trust/


The question we are facing now is how we make sense of that type of data.
Which is where the car trip comes in.

I am using GPS to navigate a part of the city I don't know very well. There
are multiple resources at my disposal:

1) My own knowledge of the area
2) Signposts on the road
3) The GPS maps in the car
4) Offline maps via my cell phone

Any one of these guides can be fallible. The GPS maps are pre big-dig (no
CANBUS modem car for me) so they are out of date. Offline maps are more
likely to be up to date but a malicious provider can direct specific
individuals to the wrong place.

The fact that there is a human in the loop actually keeps the mapping
service providers accountable. Even if 99% of drivers don't know where they
are going. The fact that there are roadsigns and the fact that a few do
know where they are going means that if the service defects, they are
likely to be caught.

Using a pure online mapping service like Google Maps and a thin client
means that I am always up to date but exposes all my movements to them. It
also breaks if I am in Prague on a crappy AT&T data plan costing $20/Mb for
international roaming. [Do the AT&T execs consider the semiotics of sending
their customers a text message saying 'we are going to try to steal from
you now' every time they cross an international border.

Using a pure offline map like the DVDRom based system in the Honda means
that nobody can track me by my use of a mapping service. It also means that
the maps are ten years out of date as I don't plan on replacing the van
till the child whose car seat it was built to fit has learned to drive and
won't trash the transmission.

The best map I have is actually an application on the phone that has
downloadable maps for the whole of Europe and North America. The mapping
service obviously preprocesses the maps so that the phone has as little
work to do as possible. So it is a 'thick client' but not as thick as it
might be.


I think the key to making a composite PKI work is to approach the problem
in a similar fashion. In the short term we want to be using the 'thin
client' as this allows us to change how we analyze data and add new
formats. When trying to develop a new protocol, agility is key. But the
medium term goal is to have a thick-ish client.