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

[Job Snijders <[e-mail]>]

Dear group, authors,

I've consulted with various subject matter experts, and at George's
request I again reconsidered. Unfortunately I could not arrive at a
different conclusion about the current RTA proposal, it is too
complicated for me to support. It appears I'm not the only one
questioning the current RTA approach:

Tim offered a very insightful and honest write-up [1], I'll cherry-pick
from what he and others wrote:

     "It is true that requiring single signing for RTAs simplifies the
     specification."

Stephen Kent states [2]:

    "Your characterization of the added complexity and validation
    failure possibilities is worrisome"

Fredrik Krosback says [3]:

    "we do not know the full extent of which software is out in the wild
    that may or may not need full refactors to handle this."

Rob Austin on RFC 6488 (August 2010) [4]:

    "As an implementor I really want to use a common code path to
    validate the common portions of all objects of this general form,
    and would really prefer a single specification of what that code
    should do. :)"

Richard L. Barnes (August 2010) [5]:

    "This document (red: RFC 6488) seems like a good approach to
    maintaining some sort of long-term architectural sanity in the RPKI,
    maybe even something that could simplify tool-building."

For rpki-client (and I suspect FORT and OctoRPKI too) the above
statements hold true: I think single-signer RTA can be implemented in a
relatively short span of time (repurposing existing code such as the ROA
codepaths). On the other hand multiple-signer requires significant
refactoring. As for the suggestion to just not support RTAs produced by
multiple-signers: I'm not comfortable with latent capabilities, this is
security orientedd software after all. Today's latent capability is
tomorrow's landmine.

So... if the authors wish to deviate from RFC 6488, are they willing to
do the real legwork and write 6488bis to change the below part?

    "Additionally, the SignerInfos set MUST contain only a single
    SingerInfo object"

If the authors really wish to continue RTA with the innate ability for
multiple signers within a single RTA object, I'll step out of the way.
Endless bickering does not help us here.

However, I hope there will be understanding if I spin up a 'competing'
draft to address a similar solution space as RTA covers, this time in
full compliance with RFC 6488. OIDs are cheap and the market usually
favors simplicity.

Kind regards,

Job

[1]: https://mailarchive.ietf.org/arch/msg/sidrops/pSIibdv-x7NgV1D9tDBx1HvYTTo/
[2]: https://mailarchive.ietf.org/arch/msg/sidrops/gx5SQI8DzRFnU2DZrZdH6rdW8Tc/
[3]: https://mailarchive.ietf.org/arch/msg/sidrops/hNKSvMFXIQzbH5TsiDgFqy-lqpE/
[4]: https://mailarchive.ietf.org/arch/msg/sidr/Zo3Hg1AwqqUi4tD1fWmd2aqTANU/
[5]: https://mailarchive.ietf.org/arch/msg/sidr/esWy85UvfjvO7N95pfZHBYQGOVY/