Re: A different way to do key signing parties.

Phillip Hallam-Baker <hallam@gmail.com> Tue, 02 April 2019 12:58 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC771200A0 for <ietf@ietfa.amsl.com>; Tue, 2 Apr 2019 05:58:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 l7WXgvUrUh7V for <ietf@ietfa.amsl.com>; Tue, 2 Apr 2019 05:58:28 -0700 (PDT)
Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (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 8E1B21200F9 for <ietf@ietf.org>; Tue, 2 Apr 2019 05:58:28 -0700 (PDT)
Received: by mail-oi1-x233.google.com with SMTP id l203so9701872oia.3 for <ietf@ietf.org>; Tue, 02 Apr 2019 05:58:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QXlT/kqSbWccEkQw128XRoCJdBGGZqfQu/jp/n+kM7g=; b=WLagRxY64E29FvCbb7s+Mi8QPeTxnEvEicQPTuEzfcW3fW8jxuLpqrhYt2ypPQhO3Y X2pDzN8weoWWZVghOqA2sKIllyzOn95DXBqOGHN9JMELGPfy9Hw9AmffYIHRiCOaB72z JM8jKzgNaMRFg7W8ntdm69mQ4KiMTjnhfwolYZ38DASCS1fmud9X2XACI1QmqHn3VPqf bgP/F2eUDzp1ruqa6lg28bFx7Rbw/2krVlkhkJjTEDMGjHrhpntaqLZK0LXZkKsVsJ9d 3ApLMvnKd6OLY8a23tsrf419grHeLI+HPf2jdA3+fjkfj4U8gazKaPKQsyTX3mGp8SGm 7BZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QXlT/kqSbWccEkQw128XRoCJdBGGZqfQu/jp/n+kM7g=; b=T7BJnF0iCeK71yh/T9Hnh0gdWwkD59MZraWRW0Um6gdXoJc2MGhlMRdZPXwE3dpInM OARhYp7IIjfhZcoiYzTekySQ8JHqaON4FRjuqoiSfiWiMaJ4lRb8gdYgatL31wRgBblB Pa1qN9Uz1sRnjHtnfekeuicq7TyGi8hW/8G/jLc3wmcaZA1li0taOWQE3xT/L62SG/cJ THzbHtJ5yhv2+rMlJ+7nmk/KWcMPEbntCRN0CTvsQvatGIQwN32gGVpIWiMWp/MOQSl0 9rs2KSiEANtRNd+hCmOuZa5HnpI1C+8clTNAmtIJBwG2flMXg8ez6tJ2GuMc0UaAkKiV muIQ==
X-Gm-Message-State: APjAAAWy8VqgZEpoXn/jPdKeN6ychnksR/5XZuM/C0Tcx7fcucjD9Vwn 3Sk/bONDHfJWygXmy6aV3LnBiOq8X2ygOIXOadLSWKXn8SQ=
X-Google-Smtp-Source: APXvYqyyBN5Z03AGHVuTtcMG1ZaMDlATNoMuc3KlM6m0Rjr1UlR4Y3HAF5VGPhLvEsi5Jkif5Rxb+N2GJ1VgngBz13Q=
X-Received: by 2002:aca:5c55:: with SMTP id q82mr16798696oib.95.1554209907547; Tue, 02 Apr 2019 05:58:27 -0700 (PDT)
MIME-Version: 1.0
References: <3D4B80ED-B1AD-48D2-9551-A6E85B20D776@gmail.com> <28118.1554172437@localhost>
In-Reply-To: <28118.1554172437@localhost>
From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Tue, 02 Apr 2019 08:58:16 -0400
Message-ID: <CAMm+LwiGYcSBYGVpZSci_5xocnJcdV2TNiM2=8ET15SQARgTpg@mail.gmail.com>
Subject: Re: A different way to do key signing parties.
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007222c005858bb17b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/uA0nqf9xVJxJ86uZmtl1vSRgkZU>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2019 12:58:32 -0000

On Mon, Apr 1, 2019 at 10:33 PM Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> Phillip Hallam-Baker <hallam@gmail.com> wrote:
>     > Now imagine that this personal PKI is designed so that my personal
> root
>     > key need never expire. Or at least not until I do. So now let's take
> a
>     > fingerprint of that key. And let's imagine that I provide that
>     > fingerprint to the IETF during registration ‘somehow’ (add encryption
>     > to taste).
>
> Do we need to involve the IETF secretariat, or can we do this some other
> indirect way?  I can put any text on my badge that I like.
>

Not necessarily.

I think it very important that I can paint a 'zero-effort' scenario that
could be realized with minimal impact on the conference organizers. But as
far as IETF roll out goes, it doesn't need to be perfect on day one. It is
not a typical audience, people are likely to use a scheme in the hope of a
future version one day being viable.


    > So now my app is saying ‘do you want to pick up your IETF badge’ or
>     > whatever and I click yes and that causes the app to post my Mesh
>     > fingerprint to a URI indicated in the document and that causes the
> desk
>     > to get a note to look for phill’s badge and also tells my conference
>     > scheduling app to load the IETF material. [Quite possibly customized
> to
>     > include my Directorate etc. private events]
>
> That's interesting.
>

There is more info on the scheme here:
http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html

As always, there are multiple ideas. but one of the more interesting ones
is Encrypted Authenticated Resource Locators. Here is an example:

udf://example.com/ED3O-CIJB-M57X-LCGZ-RAIX-K4KK-2WIU-XE

This is simply a domain name with an encryption key bodged on the end.
Assume that we present this as a QR code and you scan it. The URI is now
handed off to the UDF application.

To resolve this URI we take the fingerprint of the key and present at twice
the precision of the key:

MAQJ-VVJB-TKX5-BNL6-7WPI-UEU4-QJVZ-GV2C-XUOJ-5QHC-YGBS-BKE7-76U3-RHNU

Now add the domain and DNS Web Service Discovery for the mmm-udf scheme and
we get:
https://example.com/.well-known/mmm-udf/MAQJ-VVJB-TKX5-BNL6-7WPI-UEU4-QJVZ-GV2C-XUOJ-5QHC-YGBS-BKE7-76U3-RHNU


The target data is encrypted under the key ED3O-CIJB-...

So here we have a scheme that provides us with a means of resolving compact
QR code to securely return a data object of any size.

We can use the QR code as a lightweight bearer token. Many business
processes are driven by movement of paper documentation for good reason -
the charts move round with the patient for example.

The basic scheme is 100% symmetric. So we could make it Quantum
Cryptanalysis Resistant by expanding the key from 140 bits to 240 or so.


    > Now imagine we have been doing this sort of thing for five years. At
>     > this point, we have a pretty solid binding of identity. It is not
>     > perfect but it has a very very high work factor and if the attacker
>     > hasn’t planned the attack in advance, they kinda need a time machine.
>
> Someone who has attended 15 IETF meetings (3*5) is probably whomever their
> badge says, regardless of who the government says they are ;-)


Precisely. The only concern is that if we then publish the data we need to
make note of the fact that no credentials were checked so that people don't
carelessly depend on it for authentication the way that people now
carelessly depend on domain validated certs for TLS transactions requiring
accountability as Tom mentioned.

This is obvious if the name is something like "Psychotic Wizard". Less
obvious if the name John Smith is used.

We can delegate the job of writing up processes for checking credentials to
CABForum. I don't think we need the credentials to be validated according
to process but we probably would for a professional or academic conference.
We would want to be able to use this for registering Continuing Education
Credits.

Let us imagine that we wanted to create a Wikipedia like scheme for an
academic specialty. We would face many of the problems we face in IETF, we
want to be open but not so open a wrecker can break the process. The
scientists don't want to end up debating flat earthers or paid climate
change denial trolls. A rule where you get to vote in the appeals process
if you have checked in at three conferences in the past five years becomes
useful.

-- 
Website: http://hallambaker.com/