Re: [Sidrops] HTTPS in TALs

> On 23 Jul 2017, at 20:47, Rob Austein <sra@hactrn.net> wrote:
> 
> I think we should move from rsync to HTTPS for fetching TALs, yes, so
> I think the WG should be doing something of this general nature.

At this point agreeing on the direction is the most important point to me.

> How many stages...I think at this point I would be most comfortable
> with making HTTPS mandatory and rsync optional.

That said, I can’t help myself ;)

Why? If HTTPS is mandatory to implement for both CAs and RPs, what operational concern is addressed by allowing optional rsync in the same TAL in addition?

Again, I sympathise that CAs and RPs (including ours) need to time to move, but to me it’s much simpler to address that by having RFC7730 and 7730-bis (HTTPS only) TALs defined, and agreeing on a strategy to allow the use of -bis by CAs, support them in RPs, and once the 5 RIR TAs and 3 RPs have moved, discontinuing 7730 (rsync only). Guiding this process in subsequent RFC updates seems like unnecessary overhead to me. Still, I would rather have that, and progress, if I am alone in this.. To me the end goal is what counts here.

> My own RP implementation has supported both schemes for years (albeit
> only on a development branch until about a year ago).  I don't know
> the status of the other RP implementations, but the authors of those
> can speak for themselves.

We don’t yet support in production I believe, but I think we had code on a development branch when working on RRDP - in any case this will be trivial to add for us.

(And beneficial even because it will make automated scenario testing easier of our CA code publishing with our Publication Server, and RP validating and expecting specific results - without the need for rsync)

> Regarding Job's request that we change format to JSON or XML or ...,
> I must respectfully disagree.  The current format was deliberately
> chosen to be as simple as possible, no presentation-layer-du-jour
> parsing library required.  ASN.1 is enough fun for somebody who has to
> implement an RP in an embedded environment, but that is required,
> because all of the objects being validated are ASN.1.  Let's please
> not add a requirement for another whole parser just for TALs when the
> trivial line-oriented thing we have now will suffice.

While I would have been happier with JSON or XML in the first place I don’t see a need to change the general format now.

We already know how to parse the current TALs - the only change is in the scheme used in URIs - leaving the format as-is will be least intrusive for existing deployment at this point.

> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops
> 