[Sidrops] rpki-client implementation report (Was: 6486 bis)

[Job Snijders <[e-mail]>]

Dear group,

This is an implementation report based on my understanding of OpenBSD's
current rpki-client's behavior. We've worked hard in the last few months
to convince the community at large that there are important isues in how
some implementations treated untrusted data. Please verify this yourself
as well, I could be wrong!

Other RPKI cache implementers who care about security may want to copy
this template so we can more easily compare notes. <<< HOMEWORK >>>

The "OK" in the below table means that *I* think rpki-client's
understanding of the proposed internet-draft text is compliant with the
source code. The "OK" does not mean good/bad, in some cases there might
be reason to deviate from the specs (an implementation could be ahead of
its time). The normative terms are where the money is, so by mapping
normative terms to behavior we can more easily understand whether
consensus is emerging in this group.

The goal of this implementation report template is not to get as many
OKs as possible, but to see which implementers are tracking this effort
and where they currently stand. I know that routinator for instance will
check 'NOPE' for some of these normative terms, but they already have
plans to change that in the upcoming weeks.

An '??' can mean that I didn't have the time to figure it out, don't
understand the text, or don't understand the code. :-)

Report - 2020-06-23 OpenBSD rpki-client 6.7-current || Stephen Kent's text
 
....an RP MUST ignore the data associated with the publication point ......: rpki-client OK
....all signed objects associated with the CA instance MUST be ignored ....: rpki-client OK
...signed objects associated with the CA instance MUST be ignored, because : rpki-client OK
....an RP MUST perform a series of tests to determine which signed object .: rpki-client OK
..._All_ of the files referenced by the manifest MUST be located at the ...: rpki-client OK
...the same publication point, an RP MUST *???* ...........................: rpki-client ??
...A manifest SHOULD contain exactly one CRL (.crl) file and it MUST be ...: rpki-client OK
....and matches the CRLDP, the first one encountered MUST be used .........: rpki-client ??
...Any other .crl files MUST be ignored and a warning MUST be issued ......: rpki-client OK
..an RP SHOULD examine the most recent cached manifest ....................: rpki-client OK
...no access to a current manifest, processing stops and a warning MUST ...: rpki-client OK
...the RP SHOULD examine its cache to determine if these files ............: rpki-client OK
....the RP SHOULD use the cached files to replace those missing ...........: rpki-client OK
....then an RP SHOULD examine its local cache to determine ................: rpki-client OK
...The RP SHOULD use cached files to replace any ..........................: rpki-client OK
...then the out-of-scope entries MUST be disregarded ......................: rpki-client OK
...certificates (CA and EE) MUST be considered invalid ....................: rpki-client OK
..the RP MUST not try to acquire and validate _subordinate_ signed objects.: rpki-client OK

If you develop RP software, please produce a similar report and share it
with [e-mail]. We share implementation reports in IDR, and often
this turns out to be a very valuable ritual.

Kind regards,

Job