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

[Claudio Jeker <[e-mail]>]

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