[Sidrops] Implementation report for draft-ietf-sidrops-signed-tal-12

[Job Snijders <[e-mail]>]

Dear all,

I implemented draft-ietf-sidrops-signed-tal-12 in OpenBSD's RPKI
validator. More information about this RP implementation is available
at: https://www.rpki-client.org/

The 'Signed TAL' software implementation changeset can be found here:
https://marc.info/?l=openbsd-tech&m=166635746808783&w=2

Please add to Section 12 "Implementation Status":

   Responsible Organization: Job Snijders
   Location: https://marc.info/?l=openbsd-tech&m=166635746808783&w=2
   Description: A relying party implementation which can validate TAKs.
   Level of Maturity: Mature. Trust Anchor operators are encouraged to
      use rpki-client as part of smoke testing to help ensure high
      levels of standards compliance when introducing changes, and use
      rpki-client in a continuous monitoring fashion to help maintain
      high levels of operational excellence.
   Coverage: implementation includes all features except TAK acceptance
      timers.
   Contact information: Job Snijders <[e-mail]>

Feedback:

   Overall I found the document easy to read and straight-forward to
implement. Tom Harrison's testbed was very useful in producing the above
mentioned changeset. I very much appreciate the quick back-and-forths
which helped resolve bugs on either side.

Notes to the internet-draft authors:

1/ Section 10.2 "TA Compromise" makes no sense to me. I'd like to
   suggest to remove section 10.2 entirely. There is no such thing as an
   adversary 'temporarily' being in control of Trust Anchor private key
   material. Once a TA is discovered to be compromised, this discovery
   should be widely announced (NANOG, RIPE Routing-WG, SIDROPS, etc);
   and the community immediately should get to work to remove all TALs
   pointing to the compromised TA (both in RP implementations, as well
   in operating systems that bundle RPKI roots in a generic fashion such
   as Debian/Ubuntu/OpenBSD/etc). However, organisation of responses to
   TA compromise are out-of-scope for the signed-tal internet-draft.

2/ Section 10.3: s/can be complementary/are complementary/

3/ Section 11 lacks a Media Type registration. See RSC for an example:
   https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rsc#section-10.5

4/ Section 10.1 should also mention certified destruction of
   previously-current keypair materials.

5/ Section 9 states "can only be relied on once a majority of RPs
   support it". I don't believe concepts like 'herd immunity' apply in
   this case, for example in the case of OpenBSD or Debian (where RPKI
   roots are available to the system operator as non-RP-specific
   manner); only the packager of the RPKI roots needs to be able to
   support, and all Debian/OpenBSD users subsequently benefit from that
   support being downstream. In other words, there are benefits to TAK
   even if only a very small percentage of RPs support it.

Kind regards,

Job