Carols,
As newly-added co-author of this document, I obviously share the concerns expressed in Section 3. Although it can be argued that these issues could be worked around by careful coordination among all involved CAs when any change is to be performed on resource sets included in CA certificates, these coordination steps are only viable when only few CAs are involved.
Section 3 addresses two distinct topics: errors by high tier CAs and INR xfers. The former, and arguably the more serious of the two topics, involves one CA making a mistake. The latter may involve 3 or more CAs. Let's try to be precise in our comments.
Moreover, I believe that in an escenario where the Internet comes to see any signficant deployment of the RPKI Provisioning Protocol this coordination becomes more and more difficult and the chances for possible brokenness in some limbs of the RPKI tree at a a particular point in time will be rather high.
This is a very vague comment.
This is clearly not acceptable, and I believe the SIDR standards need to be engineered for resiliency as much as for security.
Both are important.
In Section 4 two possible paths forward are proposed. The first option presents a simple, understandable and workable alternative that, as Tim has already mentioned, can be implemented by relying parties in a short period of time.
Section 4 conflates two related, but distinct, issues. A method for INR transfer, by itself, is not going to deal with errors by high tier CAs. Tim is one developer of RP software. We ought to hear from the other two RP software developers before judging how easy or hard it may be to adopt a change that is not fully specified yet. Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
