Re: [Sidrops] WG-ADOPTION - draft-michaelson-rpki-rta - Ends 12/10/2020 (Dec 10 2020)

Job Snijders <job@sobornost.net> Sat, 26 December 2020 16:26 UTC

Return-Path: <job@sobornost.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DADF3A09EF; Sat, 26 Dec 2020 08:26:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 QkKkX37xdfeX; Sat, 26 Dec 2020 08:26:43 -0800 (PST)
Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 302AD3A09F6; Sat, 26 Dec 2020 08:26:42 -0800 (PST)
Received: from smtp.freedom.nl (unknown [10.10.3.36]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 1196460896; Sat, 26 Dec 2020 16:26:39 +0000 (UTC)
Received: from smtp.freedom.nl (smtp.freedom.nl [116.202.65.211]) by soverin.net
Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id 268b599c; Sat, 26 Dec 2020 16:26:33 +0000 (UTC)
Date: Sat, 26 Dec 2020 16:26:33 +0000
From: Job Snijders <job@sobornost.net>
To: Christopher Morrow <christopher.morrow@gmail.com>
Cc: SIDR Operations WG <sidrops@ietf.org>, SIDROps Chairs <sidrops-chairs@ietf.org>, sidrops-ads@ietf.org
Message-ID: <X+dkOb22IBo6d8FA@bench.sobornost.net>
References: <CAL9jLaYALiw9wAbLx8j-RH5jPvtHV9MKXi=_3kj8A-NdZH0-gQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAL9jLaYALiw9wAbLx8j-RH5jPvtHV9MKXi=_3kj8A-NdZH0-gQ@mail.gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/9-5-D5zQtodDqYYnVQNGAiLg3J8>
Subject: Re: [Sidrops] WG-ADOPTION - draft-michaelson-rpki-rta - Ends 12/10/2020 (Dec 10 2020)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Dec 2020 16:26:46 -0000

Dear group,

On Thu, Nov 19, 2020 at 10:04:50AM -0500, Christopher Morrow wrote:
> Howdy WG Folks!
> During our last Face-to-Face meeting the authors of:
>   draft-michaelson-rpki-rta
> 
> presented their document and requested (in meeting and via email to
> the list) a call for Working Group Adoption. The abstract of the
> document is:
> 
>   "This document defines a Cryptographic Message Syntax (CMS) profile
>    for a general purpose Resource Tagged Attestation (RTA), for use with
>    the Resource Public Key Infrastructure (RPKI).  The objective is to
>    allow an attestation, in the form of an arbitrary digital object, to
>    be signed "with resources", and for validation to provide an outcome
>    of "valid with resources".  The profile is intended to provide for
>    the signing of an attestation with an arbitrary set of resources."
> 
> let's have a read-through, think about applicability to SIDR-OPS as it
> relates to the technology we build and operate (technology and
> business intersection), and provide feedback on the list before
> 10/12/2020 (Dec 10th).

I support adoption, and I am willing to try to create a validator
implementation based on OpenBSD's rpki-client. During implementation
feedback in the current document & questions can be shared with the
group, hopefully increasing the document's readability for future
implementers.

A particular use case stands out to me: the PeeringDB platform could use
RTAs to validate ownership of PeeringDB "IX" and "Network" objects,
greatly increasing reliability of its user-submitted database, while
further reducing friction in its onboarding processes.

I would like to recommend the authors to include a copy of the RFC 7942
section 2.1 boilerplate text in the draft (optionally to be removed by
the RFC Editor) to help track implementations. Please make it clear
the 'signer' and 'validator' components are implemented separately.

Congratulations to both APNIC and NLNetlabs for already having
implemented such an incredibly innovative application of the RPKI. I'm
certain RTAs will prove to be useful in a myriad of B2B processes.

Kind regards,

Job