[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [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 4F45A602C8 for <sidrops@ietf.org>; Sat, 26 Dec 2020 17:50:52 +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 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,

Job

---------------------

OLD:
    Intended status: Experimental
NEW:
    Intended status: Standards Track

---------------------

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

NEW:
   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'.

----------------------

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

NEW:
    Section 9.1 OID
    The IANA is requested to reference the '1.2.840.113549.1.9.16.1.36'
    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>
--------------------------