Re: [sidr] WG adoption poll for draft-huston-rpki-validation-01

[Rob Austein <[e-mail]>]

Unfortunately, the binary adopt-or-not question is insufficiently
nuanced for a case like this.

I think the WG needs a work item to explore the issue of decoupling
RFC-3779-style[*] path validation from certificate validation.  It may
be that at the end of that process we will decide not to change the
base specification, but in addition to whatever sympathy the WG might
feel for CA operators near the root of the tree, I think there may be
some real issues lurking here with respect to out-of-order validation
problems and we need to explore them further.

I really do not know at this point whether the result of the work we
need to do on this will be a publishable document or not.

I do not support the addition of joins in the RPKI tree, full stop.

The WG chairs asked a couple of specific questions:

> You are asked to indicate if you think that this is work that the wg
> should be doing

Yes, with the proviso that the end result may be a decision to leave
well enough alone, in which case the only thing we might publish would
be a history of our decision not to change anything.

> and whether this draft is an acceptable starting point.

As a problem statement, yes.  With no intent to give offense, it's
nowhere near being suitable as an amended specification, but such a
document would be premature at this stage in any case.

Starting with a problem statement seems appropriate, so long as we
retain the option of keeping the current specification.  Yes, this
might end up meaning that, after years of work, the WG concludes that
we should not change the specification.  Sometimes you have to work on
something for a while before you know whether you should be doing it.

[*] "RFC-3779-style" because, if we change it, it won't be RFC 3779
    anymore.  It might well reuse all of RFC 3779's syntax and most of
    RFC 3779's semantics, but since there is deployed code that thinks
    it knows how to validate with the current semantics, at minimum I
    would want the hypothetical new thing to use different extnID OID
    values to flag the change.  So, strictly speaking, this would be a
    new set of X.509v3 extensions that just happen to look exactly
    like the ones from RFC 3779.