On 09/06/2010, at 5:41 AM, Rob Austein wrote: > At Mon, 7 Jun 2010 17:35:23 -0700, Terry Manderson wrote: >> >> Before I lend my support to either the simpler format or the current >> compound TA format I'd like to see a pros/cons list comparing the two >> approaches. >> >> While I find myself liking simple approaches but I also wonder if it >> has any downfalls in use. > > Terry, > > As far as I know the simple approach has no downside. We've been > using something semantically identical to this in our testbed since > last July, and the new syntax was a trivial drop-in replacement. The > self-signed RPKI certificates change weekly as we get new data, > validator keeps humming along. > > Other than simplicity for its own sake, the main advantage I see with > the simple approach is that in some respects it is technically more > robust, precisely because there are fewer moving parts, therefore > fewer things to go wrong. This is not meant as a slam at the other > mechanism, it's just that X.509 and CMS have a lot of options, each > with multiple settings. The set of allowed options is much smaller > than the set of possible options. Unchecked options can potentially > trigger weird behavior in the underlying X.509 and CMS > implementations, so all of the options must be checked. All this work > makes no progress towards the real goal (verifying RPKI certificates), > it's essentially busywork that one is stuck with doing because of the > choice of trust anchor wrapper format. The simpler approach eschews > most of this, and has very little to check beyond the checks that one > has to do anyway for the self-signed RPKI certificate itself. > > So, to me, the simple approach adds exactly what we need beyond the > base RPKI mechanism, and no more, while the other mechanism adds a lot > of stuff that accomplishes the same purpose but takes more effort to > get right. I freely grant that there are many other parts of this > system which are also complicated and easy to get wrong, but that, in > and of itself, seems insufficient reason to add another one. > > So, to me, at least in this case, simplicity is not just an esthetic > virtue, it's a form of engineering robustness. > > YMMV.
Firstly, I'd like to point out that the approach described in this draft, namely that of public key plus URL and a self signed RPKI certificate) is the approach described in draft-ietf-sidr-res-certs-06.txt through to draft-ietf-sidr-res-certs-11.txt. The terminology was altered slightly across that sequence of drafts in response to inputs from Steve Kent, but the concept of using a very simple approach of using the public key plus URL was what was originally envisaged for the RPKI back in 2007-2008 when those versions of the draft were submitted to the drafts repository. The changes made in version 12 of that draft were made in response to messages from Steve Kent and Russ Housley, which pointed out what they believed to be specific weaknesses in this key plus URL approach to the TA that implied that in their opinion this was not a viable approach to the TA. If they are still of the opinion that this approach is not viable then I guess that they should say so once more and present their arguments in support of that view, this time to the WG. Geoff _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
