Subject: Re: [Sidrops] 6486 bis

From: Martin Hoffmann <[email-masked]>
Date: Wed, 17 Jun 2020 10:55:37 +0200

Hello!

I am curious what the plan forward is with regards to 6486-bis? We are
looking into releasing a 1.0 version of Routinator soon-ish and would
like to have the revised manifest validation rules included since
they most definitely constitute breaking changes.

While we don’t necessarily need to wait for the final RFC, it would be
good to at least have a relatively stable I-D to build upon.

Kind regards,
Martin

---

From: "Job Snijders" <[email-masked]>
Date: Wed, 17 Jun 2020 09:13:04 +0000

Dear Martin, others,

To me the text that Stephen Kent shared with the group on May 8th is probably the 'relatively stable I-D', the text is here https://mailarchive.ietf.org/arch/msg/sidrops/04s5QYa_BdVNrfC6TH4Axr7izqs/

Someone needs to convert it to XML, it is not clear who the volunteer is. I can try to work on it, but if someone else is already on it that would be good to know. 

I started some XML in a similar direction https://tools.ietf.org/html/draft-spaghetti-sidrops-rpki-manifest-validation-00 but it seems that didn't receive support to progress.

Kind regards,

Job

On Wed, Jun 17, 2020, at 08:55, Martin Hoffmann wrote:
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops
>

---

From: Jay Borkenhagen <[email-masked]>
Date: Wed, 17 Jun 2020 07:44:40 -0400

Martin Hoffmann writes:
 > 
 > I am curious what the plan forward is with regards to 6486-bis? 

Hi Martin,

In addition to Job's comments, don't forget about the upcoming SIDROPS
Interim meeting, merely one week from today, which was specifically
called to discuss "some of the pending changes to RFC6486 which were
discussed at the last event."

https://mailarchive.ietf.org/arch/msg/sidrops/z9JmkXqDuvd31fLTtVzkQDT1-WI/

Hope to see you there!

						Jay B.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 17 Jun 2020 09:14:13 -0400

Martin,

I assume the interim meeting scheduled for next week is intended to 
resolve any outstanding issues. I plan to revise the most recent version 
of the text I posted based on that meeting.

Steve
> While we don???t necessarily need to wait for the final RFC, it would be

---

From: Stephen Kent <[email-masked]>
Date: Wed, 17 Jun 2020 09:15:16 -0400

Job,
> I started some XML in a similar direction https://tools.ietf.org/html/draft-spaghetti-sidrops-rpki-manifest-validation-00 but it seems that didn't receive support to progress.

I believe Randy has been generating an XML version of 6486-bis, but is 
waiting for the outcome of next week's interim meeting before proceeding.

Steve

---

From: "Job Snijders" <[email-masked]>
Date: Wed, 17 Jun 2020 13:26:56 +0000

> waiting for the outcome of next week's interim meeting before proceeding.

awesome, good to hear.

Kind regards,

Job

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 18 Jun 2020 12:35:04 -0400

> of the text I posted based on that meeting.

I hope to have some slideware out before monday for review and
preparation as well :)
Ideally it encapsulates the current state of the document  and we can
reach quick consensus there (and on-list)
in order to get the text published before the 108 meeting timeslot.

thanks for the folk who worked on the revised text so far, at least:
  stkent, randy, job, martin, jayb, timb, russ, smb
  (others I'm sure I missed along the way)
-chris
co-chairotorial.

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 23 Jun 2020 23:41:33 -0400

<cough> I am late, but there are slides now...</cough>

again, thanks for the folk that did the hard work... I'm just making a
summary and we(chairs) are hoping to guide the landing onto the
proposed text :)

See you all tomorrow!
-chris

---

From: Job Snijders <[email-masked]>
Date: Wed, 24 Jun 2020 11:39:00 +0000

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 [email-masked]. We share implementation reports in IDR, and often
this turns out to be a very valuable ritual.

Kind regards,

Job