Re: What ASN.1 got right

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 03 March 2021 18:32 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 165463A1812 for <ietf@ietfa.amsl.com>; Wed, 3 Mar 2021 10:32:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 taEU7SiPf0oZ for <ietf@ietfa.amsl.com>; Wed, 3 Mar 2021 10:32:19 -0800 (PST)
Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com [209.85.219.173]) (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 71E313A1811 for <ietf@ietf.org>; Wed, 3 Mar 2021 10:32:19 -0800 (PST)
Received: by mail-yb1-f173.google.com with SMTP id 133so25596569ybd.5 for <ietf@ietf.org>; Wed, 03 Mar 2021 10:32:19 -0800 (PST)
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=tZCEa+a/RsNWqnTQnL3o/i+769AWbbmOhLO1FfzxHBs=; b=YfX8qjU1Gbi0043X0IqTpM6xC9+t6S3p8v7iz5p8OBCy9mVwcTFCCmP1eNvphmsl0S 4vzLG7JQO7sp/9UaGMSV3z3GuMmfTC+abRaEi5TWKMZnNqgmYLjQqyqhQZnQWLSrwtk5 +7H1FYP0xb67xEE6FEH9bxH75IBPAxqP3mxs1OaCCo8QFfKTuQPXxsZr7PIMhbkmsCH8 O4zU3hBvRPK8ABEQpgkUIozbJ+MzCz0XE0/gjZ0OCOh6318Csq17+wTbw/EawwDzrFZt bKbg42RdAqy0Km6mtSEr/4UVhhbfCGH+pc6Z1qXO9rBkz/m/Hr0TLH4TotE8HYd0yzkY 77Kw==
X-Gm-Message-State: AOAM5314i8yxJXKeO8QdsXanUXNn7gBztS5IHoSk8Q1Wh8b9jQwTw0Yu Njho4AZ4PciqSYtjPqlyaL90tMCINdwnyRPTUkoUoBs73o4=
X-Google-Smtp-Source: ABdhPJzOYLrm2YWYYeS8+Sjm5VRJf1i340Qqq+KOGxCMCt0DvzcGxIP3l3RUFjsT1Mb7bPG/QskjwOpSv3q0EZ62TRw=
X-Received: by 2002:a25:ad67:: with SMTP id l39mr990888ybe.172.1614796338546; Wed, 03 Mar 2021 10:32:18 -0800 (PST)
MIME-Version: 1.0
References: <CAMm+LwifpPg-Sg9cXLpWvjmExt8KfuYq6oRZd4D1L0ZBR3nRFg@mail.gmail.com> <1631e20d-9d8a-b8c2-9d5e-6c7f4defa72d@mtcc.com> <20210302234928.GX30153@localhost> <cb4960e2-05a1-9d28-f17b-9f610ac378c9@mtcc.com> <20210303002330.GZ30153@localhost> <7d70044c-88e8-0165-5ce3-4c8612965f16@mtcc.com> <20210303005136.GB30153@localhost> <8e4d3b84-0357-524e-b8f5-b8f7290adf2b@mtcc.com> <20210303022234.GE30153@localhost> <b87a101d-dcad-1f75-aeec-a2d19022ce35@mtcc.com> <20210303033555.GG30153@localhost> <370a2bd4-46b2-aad2-3ae2-31e92888a8a3@mtcc.com>
In-Reply-To: <370a2bd4-46b2-aad2-3ae2-31e92888a8a3@mtcc.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Wed, 3 Mar 2021 13:32:08 -0500
Message-ID: <CAMm+Lwi-BsXZvykudzeQcyhovk0VT5Pkx3ZnQmRa-7RoKx0AsA@mail.gmail.com>
Subject: Re: What ASN.1 got right
To: Michael Thomas <mike@mtcc.com>
Cc: Nico Williams <nico@cryptonector.com>, IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000024cc3b05bca612da"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/jo3PHeue7WITnl9spKJe_QoPekY>
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: Wed, 03 Mar 2021 18:32:21 -0000

On Wed, Mar 3, 2021 at 12:50 PM Michael Thomas <mike@mtcc.com> wrote:

> Or you just expect online and not worry about any of this.
>
> I'm not even sure why you'd want to use certs in your use case. You're
> just reinventing Kerberos.
>
> Mike
>

It really isn't useful to discuss how PKIX makes use of client certs, it
failed to achieve ubiquitous use, the management of private keys is
horrible and revocation doesn't do what you want.

Something I learned in the past few days is that revocation is not part of
authentication at all. It is exclusively a part of authorization. The
device has been authenticated to the key even if the certificate was
revoked.


What enterprises want for revocation of user credentials is a scheme that
allows all use of the credential to be disabled within 30 minutes. The
objective being that during the time Mallet is getting his termination
interview in Alice's office, every open session Mallet has established is
disconnected and he is prevented from creating any new ones.

I just don't see OCSP or any other PKIX technology doing that. And neither
does the Mesh currently.

And it isn't just Mallet that is the issue here, it's also Alice's phone
which Mallet swipes during the termination interview, that has to be
disabled the minute Alice realizes it is gone.


Coincidentally, I am just working on that exact bit of the Mesh
architecture. I think we can reuse the 'heartbeat' capability required in
any presence protocol. If Alice can get messages on a device, it has to be
telling the service where it can be reached.

So Alice's cell phone is going to be pinging Alice's MSP with a UDP packet
once a minute or so. And that allows the device to send out updates
whenever one of the catalogs that device is subscribed to is updated. It
also allows Alice to be told of an incoming call, etc. etc.

We can do the exact same thing when Alice uses her credential to connect to
a service. The relying service takes out a subscription to the credential
source and gets a notification when it is revoked.

The exact same code path can be used when there is a change in Alice's
authorization status while a device is connected. And that can go up as
well as down.