Stephen, (snipping for brevity)
On 8/5/14, 6:11 PM, Stephen Kent wrote: > Carlos, > >> Hello, >> >> wrong and this discussion indeed took place. I'd appreciate any pointers. > 3779 was developed for the RPKI context (when S-BGP was the encompassing > term); > that's why it was adopted by SIDR. The extension was developed by folks > with > considerable PKI expertise, as a way to make minimal changes to standard > PKI > path validation., Given that S-BGP failed to gain any traction and most people outside the IETF have never heard of it, I don´t think it sets a particularly encouraging precedent. There is nothing wrong with the extension, nor with the rules per-se. Some of us believe that 3779 rules are not a good match for this particular problem. They may very well be for other, related, problem domains (whole network transfers come to mind now). > But, then, so are IPv4 and v6 address prefixes. Do you propose creating > separate PKIs > for IPv4 and IPv6 addresses? Definitely not. Again, S-BGP is not a particularly good data point. I propose to *unbundle* the analysis of resource types when validating certs. I believe that is clear from my earlier email and from our draft. On the other hand, if you believe that unbundling introduces any new threat, please do comment on that. >> - Managing mistakes within the same resource type: Should a mistake in >> one IPv4 prefix invalidate the whole cert and down below for *all* >> prefixes? Discuss #2! > Should revocation of a cert with a set of prefixes invalidate all > the certs below? (hint, the answer is yes.) The examples cited by > you and your fellow authors focus only on errors in 3779 extensions, > but why are revocation errors not equally important to address? The ability of not being able to correct 1 issue out of 2 doesn´t seem to be a good argument for leaving the 2 unfixed. In addition, revocation errors are way less probable than transient registry inaccuracies. I actually don´t see how we would revoke a cert by mistake, although I´m not saying it cannot happen. If I had to put probabilities to it, I would say 99% of problems will come from registry inaccuracies vs 1% revocation errors. So, if 2 weeks of work (Tim says 1 day, but given he's a particularly gifted coder we´ll give everyone else 14 times as much) can solve 99% (or 90%, or even 80%) of issues and remove a large roadblock for the continuing adoption of OV and RPKI, it seems like a no brainer. The intent of our draft is not to say that RFC 3779 is in error, it just goes to say that the validation model it proposes will possibly create difficult scenarios in real-world RPKI deployments, scenarios that will undermine the trust in the overall solution. regards Carlos _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
