[Anima] draft-ietf-acme-star-delegation-05.txt and BRSKI-AE

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 21 February 2021 20:13 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7106B3A1086 for <anima@ietfa.amsl.com>; Sun, 21 Feb 2021 12:13:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 MEpYWPlqaHM0 for <anima@ietfa.amsl.com>; Sun, 21 Feb 2021 12:13:51 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF2DD3A108F for <anima@ietf.org>; Sun, 21 Feb 2021 12:13:50 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 55372389EB; Sun, 21 Feb 2021 15:17:50 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wDpLyDlL8xWC; Sun, 21 Feb 2021 15:17:49 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 53712389E5; Sun, 21 Feb 2021 15:17:49 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AACC1666; Sun, 21 Feb 2021 15:13:48 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: anima@ietf.org, Hendrik Brockhaus <hendrik.brockhaus@siemens.com>
In-Reply-To: <161393206518.11813.1416988663631870171@ietfa.amsl.com>
References: <161393206518.11813.1416988663631870171@ietfa.amsl.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sun, 21 Feb 2021 15:13:48 -0500
Message-ID: <23305.1613938428@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/be5UBbJLxO3IwoE8ROgG5l-5-PA>
Subject: [Anima] draft-ietf-acme-star-delegation-05.txt and BRSKI-AE
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Feb 2021 20:13:54 -0000

We have struggled with brski-ae to deal with how the pledge can pin a thing
from the pledge-agent to prove proximity.

It feels that something like either Delegated STAR could work well.
Or, if not that, and we are using TLS, then draft-ietf-tls-subcerts-10
Failing that, we need to create some kind of JWT, or CWT artifact which the
Registrar uses to bless the pledge-agent.

We have spoken about gathering the voucher-request artifact from the pledge
with the pledge-agent initiating the communication.  That is, the pledge
is passive for this, and the pledge-agent initiates.  Some would call
this PUSH, if they are thinking about things from the pledge point of view.
But, the pledge-agent has to PULL the voucher-request from the pledge,
and then PUSH the voucher-request to the RA...

So, I want to suggest that sections 5.1 and 5.2 be renamed.

I find the PULL/PUSH terminology confusing.  I recognize that the
directionality that is implied by the PULL/PUSH is based upon, I thought,
whether the RFC8366 voucher is retrieved by the pledge, or provided to the
pledge.  But, in section 5.1, I think that it's called PULL because the
communication with the RA?

I guess I am much more interested in the 5.2 interaction!
That it could support, for instance, smart-phone + NFC, is very interesting.
I believe that it should not be session based (i.e. object security, not TLS
or EDHOC).


internet-drafts@ietf.org wrote:
    >         Title : An ACME Profile for Generating Delegated STAR
    > Certificates Authors

    > Abstract: This memo proposes a profile of the ACME protocol that allows
    > the owner of an identifier (e.g., a domain name) to delegate to a third
    > party access to a certificate associated with said identifier.  A
    > primary use case is that of a CDN (the third party) terminating TLS
    > sessions on behalf of a content provider (the owner of a domain name).
    > The presented mechanism allows the owner of the identifier to retain
    > control over the delegation and revoke it at any time by cancelling the
    > associated STAR certificate renewal with the ACME CA.  Another key
    > property of this mechanism is it does not require any modification to
    > the deployed TLS ecosystem.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide