Re: [Sidrops] feedback on draft-michaelson-rpki-rta
Job Snijders <job@sobornost.net> Tue, 29 December 2020 15:57 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 31B9A3A1450 for <sidrops@ietfa.amsl.com>; Tue, 29 Dec 2020 07:57:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 aC2WL4r7xfkr for <sidrops@ietfa.amsl.com>; Tue, 29 Dec 2020 07:57:12 -0800 (PST)
Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.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 E76C83A144F for <sidrops@ietf.org>; Tue, 29 Dec 2020 07:57:11 -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 2F298600E4 for <sidrops@ietf.org>; Tue, 29 Dec 2020 15:57:09 +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 72836234; Tue, 29 Dec 2020 15:57:07 +0000 (UTC)
Date: Tue, 29 Dec 2020 15:57:07 +0000
From: Job Snijders <job@sobornost.net>
To: sidrops@ietf.org
Message-ID: <X+tR06kF3aPZ4+18@bench.sobornost.net>
References: <X+d3+e5Rj/Q7Dchv@bench.sobornost.net> <20201229101412.GA56136@diehard.n-r-g.com> <X+scpsd6kDQ72nLa@bench.sobornost.net> <49a8e314-7b3f-0e8d-6e20-7d055fb1a076@verizon.net> <20201229151639.GD56136@diehard.n-r-g.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20201229151639.GD56136@diehard.n-r-g.com>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/9RLfEuxNg5sn5StGIrdR4XqdlAg>
Subject: Re: [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: Tue, 29 Dec 2020 15:57:15 -0000
On Tue, Dec 29, 2020 at 04:16:39PM +0100, Claudio Jeker wrote: > Up until now all objects only had a single EE cert and a single SID and > all the linking done with the SKI was a 1-to-1 mapping resulting in a > simple tree structure with the trust anchor as root. > This draft allows for multiple EE certs and so multiple paths up to the > trust anchors. This makes handling RTA a lot more complex than any other > object under RPKI. It also results in a lot more failure conditions since > there are more EE certs involved in the validation process. And even worse, the complexity doesn't appear to provide any benefits: as can be seen from my example [1], with a reduced RTA eContent profile the BYOIP / BYOAS use case doesn't require a set of SKIs in the eContent. If a signer wants to create a RTA for some multi-signer x509 pem encoded file (or their vacation photos), they are free to do so, what the hash in the RTA eContent represents is out of scope. I believe a RTA should conceptually be very similar to a single RFC 6486 'FileAndHash', except instead of associating the hash with a IA5String 'file', the hash is associated with one or more Resources delegated to the Resource holder. Optionally, the hash is associated with an arbitary digital object outside the RPKI, onlookers won't know if the hash in the RTA econtent is the message itself or a digest of another digtal object. A cool property! Further more (just like in manifests) we can encourage the use of one-time-use EE certificates. The CA MAY choose to sign only one RTA with each generated private key, and generate a new key pair for each new version of the RTA. After generating the RTA the keypair can be destroyed. The draft-michaelson-rpki-rta-02 itself describes the presence of these additional certificates as a 'burden' (section 10): """ RTA objects themselves may appear in repositories, and are constrained in size to the ASN.1 encoded burden of the set of certificates which are sufficient to describe the RFC3779 resources associated with the signatures. """ So, why not just remove it? :) It is possible the RTA authors forsee use cases where the 'multiple signatures' offers irreplaceable value, I'm not sure. If this is the case, perhaps a second effort can be spun up: 'A Simplified RTA Profile'. In this separate second effort a lot of code can be re-used from the original RTA implementation, making sure no coding efforts went to waste. Kind regards, Job [1]: https://mailarchive.ietf.org/arch/msg/sidrops/WCDklq3lOR0LX2ZZkziMlxyWTaU/
- [Sidrops] feedback on draft-michaelson-rpki-rta Job Snijders
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Claudio Jeker
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Job Snijders
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Stephen Kent
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Claudio Jeker
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Job Snijders
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Stephen Kent
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Ben Maddison
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Tim Bruijnzeels
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Korsback, Fredrik
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Tim Bruijnzeels
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Stephen Kent
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… George Michaelson
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Ben Maddison
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Martin Hoffmann
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Job Snijders
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… George Michaelson
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Job Snijders
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Job Snijders
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Martin Hoffmann
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Di Ma