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

Claudio Jeker <cjeker@diehard.n-r-g.com> Tue, 29 December 2020 15:16 UTC

Return-Path: <cjeker@diehard.n-r-g.com>
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 631723A1439 for <sidrops@ietfa.amsl.com>; Tue, 29 Dec 2020 07:16:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 3tKr1oSuqISj for <sidrops@ietfa.amsl.com>; Tue, 29 Dec 2020 07:16:44 -0800 (PST)
Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDBDE3A1438 for <sidrops@ietf.org>; Tue, 29 Dec 2020 07:16:41 -0800 (PST)
Received: (qmail 22960 invoked by uid 1000); 29 Dec 2020 15:16:39 -0000
Date: Tue, 29 Dec 2020 16:16:39 +0100
From: Claudio Jeker <cjeker@diehard.n-r-g.com>
To: Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>
Cc: sidrops@ietf.org
Message-ID: <20201229151639.GD56136@diehard.n-r-g.com>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <49a8e314-7b3f-0e8d-6e20-7d055fb1a076@verizon.net>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/LoaWBU1YA4RQhO5dRObnw6J49Nc>
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:16:45 -0000

On Tue, Dec 29, 2020 at 07:58:29AM -0500, Stephen Kent wrote:
> Claudio & Job,
> 
> RFC 6488 (2.1.6.2) requires use of the SKI in the sid for all "signed
> objects" in the RPKI.
> 
> Is the proposal to not use an SKI in the RTA format compatible with this?

No that is not what I was after.  The usage of SKI as per RFC 6488
(2.1.6.2) is absolutly fine.  My problem with the RTA draft are these
points of the draft (section 3):

   The differences between this RTA profile and the profile specified by
   the RPKI Digitally Signed Object template are as follows:

   o  Section 2.1 of [RFC6488] specifies a single SignerInfo object.  An
      RTA MAY contain more than one SignerInfo object.

   o  Section 2.1.4, and Section 3 of [RFC6488] specify that the
      certificates field contains a single EE certificate.  The
      certificates field of an RTA contains precisely the same number of
      EE certificates as there are SignerInfo objects in the RTA, where
      each EE certificate is needed to validate the signature in each
      SignerInfo.  In addition, the certificates field MAY contain a
      collection of CA certificates that would allow a RP to validate
      the EE certificates.

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.

-- 
:wq Claudio