[Sidrops] feedback on draft-michaelson-rpki-rta

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

Return-Path: <job@sobornost.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5EA3B3A0B8F for <sidrops@ietfa.amsl.com>; Sat, 26 Dec 2020 09:50:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id g37cxkC8m5Gg for <sidrops@ietfa.amsl.com>; Sat, 26 Dec 2020 09:50:56 -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 6BA253A0A81 for <sidrops@ietf.org>; Sat, 26 Dec 2020 09:50:55 -0800 (PST)
Received: from smtp.freedom.nl (unknown []) (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 4F45A602C8 for <sidrops@ietf.org>; Sat, 26 Dec 2020 17:50:52 +0000 (UTC)
Received: from smtp.freedom.nl (smtp.freedom.nl []) by soverin.net
Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id 173bb77b; Sat, 26 Dec 2020 17:50:49 +0000 (UTC)
Date: Sat, 26 Dec 2020 17:50:49 +0000
From: Job Snijders <job@sobornost.net>
To: sidrops@ietf.org
Message-ID: <X+d3+e5Rj/Q7Dchv@bench.sobornost.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/3jzvsqP_8L3Js39tGXujIyUPR7E>
Subject: [Sidrops] feedback on draft-michaelson-rpki-rta
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 17:50:59 -0000

Dear group,

Reading draft-michaelson-rpki-rta-02 while writing some work-in-progress
code, I have some suggestions that hopefully improve the ease of use
of RTAs. WIP: http://sobornost.net/~job/rpki-client-rta.patch.txt

While it is useful property of RTAs they can be exchanged via email or
webforms (aka 'private B2B'), I also envision use cases where RTA
objects are best distributed through a publication protocol (public INR
holder statements). I forsee increased interoperability if the document
specifies some constraints on how to publish RTAs via RSYNC/RRDP, if the
Resource Holder chooses to use that path. Some suggestions for text are
included below.

Of course, from a cryptographic validation and 'permissionless
innovation' point-of-view the 'standalone' use of RTAs (without IANA
actions) is perfectly valid and applicable, however from an
interopability point-of-view I would encourage the group to also go
through the motions on describing how to publicly publish RTAs, and thus
target Standards Track.

Kind regards,



    Intended status: Experimental
    Intended status: Standards Track


Section 8
   An RTA and its associated EE certificates MAY appear on an RPKI
   Manifest and MAY be published in a repository.

   An RTA and its associated EE certificates MAY appear on an RPKI
   Manifest and MAY be published in a repository. If an RTA appears
   on an RPKI Manifest, the RTA's file extension MUST be '.rta'.


    Section 9
    IANA is entirely off the hook on this one.

    Section 9.1 OID
    The IANA is requested to reference the '1.2.840.113549.'
    OID as Resource Tagged Attestations in the RPKI Signed Objects
    registry created by [RFC6488].

    Section 9.2 File Extension
    IANA is requested to an item for the Ghostbusters Record file
    extension to the "RPKI Repository Name Scheme" created by [RFC6481]
    as follows: '.rta', 'Resource Tagged Attestation', ref: [draft-michaelson-rpki-rta]

    Section 9.3 Media Type
    The IANA is requested to register the media type application/rpki-rta as follows:

    Type name: application
    Subtype name: rpki-resourcetaggedattestations
    Required parameters: None
    Optional parameters: None
    Encoding considerations: binary
    Security considerations: Carries an Resource Tagged Attestation [draft-michaelson-rpki-rta]
    Applications that use this media type: RPKI users.
    Additional information:
     Content: This media type is a signed object, as defined
         in [draft-michaelson-rpki-rta], which contains an arbitary
         canonicalized payload as defined above in this document.
     Magic number(s): None
     File extension(s): .rta
    Person & email address to contact for further information:
     George Michaelson <ggm@apnic.net>
    Intended usage: COMMON
    Restrictions on usage: None
    Author: George Michaelson <ggm@apnic.net>
    Change controller: George Michaelson <ggm@apnic.net>