Hi, > On 25 Nov 2015, at 21:19, Stephen Kent <[email protected]> wrote: > > None of those who believe that this draft is a good thing seem to have > addressed > an issue I raised a while ago; the proposed solution is ill-defined and, the > most > likely interpretation doesn't seem to work, in general. I'll try to explain > this > reasoning, again, and provide an example.
I believe the draft is being precise, but in the process has become difficult to parse. Let me attempt once more to explain the proposal in a different way: "When doing top-down validation of resource certificates in the RPKI we propose that rather than rejecting a certificate that has resources not held by the parent (but is valid on all other respects), we would accept the certificate but keep note of the actual resources we believe it can be authoritative for. I.e. the intersection of resources on this certificate and the resources accepted for the parent. The RP SHOULD however issue a warning in case certain resources are excluded because of this, so that the responsible CA can fix the situation. Please note that for ROAs there is a requirement that all ROA prefixes are included on the EE certificate of the (ROA) signed object CMS. This proposal does not change this. A ROA that has prefixes that were removed for whatever reason higher in the path would still become invalid using this algorithm. We would therefore RECOMMEND that CAs issue 1 ROA for each prefix, and avoid fate sharing. That way only ROAs for prefixes that were removed will be affected." Essentially that really is all there is to it. If this is easier to parse, and the co-chairs conclude that work should continue, then I am happy to use this line of explanation in a next version of the document. And no, I have no doubt that it will need more detail than above in an I-D - but it's the basic principle that I am trying to convey here. Tim _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
