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

[Job Snijders <[e-mail]>]

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/