I think that Rob makes an excellent point. I have no problem with making this draft the focal point of discussions about changing RPKI path validation. Indeed, I greatly appreciate the effort that Geoff and George have put into articulating the operational concern with RFCs 3779 and 6487. There is clearly a CA operational concern here and I think it is good for the working group to take these types of concerns seriously.
However, I am not yet sold that the solution outlined in this draft is necessary (or is the best way of addressing the problem). I think it is possible that the cost [in complexity, risk, changes to deployed code] of the proposed solution is not worth the benefit. At this point in time, I think it is important to prematurely commit to a solution. (Indeed, based on discussions on the list, I think there was - even quite recently -- some confusion about the problem that needs to be solved.) Personally, I don't think it is especially important whether or not we adopt the draft, as long as adopting the draft isn't interpreted as consensus that the particular solution specified in the draft is definitely the best way forward. That is, Adoption is generally a commitment by the working group to spend time working on a particular topic and a transfer of change control to the working group. Both of these I am comfortable with. - Matt Lepinski On Tue, Apr 29, 2014 at 6:01 PM, Rob Austein <s...@hactrn.net> wrote: > 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. > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
