Declan, I’d pay more attention to this statement you are quoting if and only if the justification for this statement made any sense. As far as I can tell the example used to build to this point is confused and imprecise, so its a leap of faith that I’m not perform to then hold the conclusions as valid.
I find it equally challenging to then reach the conclusion that you appear to be providing that that somehow all this is dependant on a draft relating to certificate mediated resource transfer. Again I see what appears to be another leap of faith going on here. Geoff > On 27 Nov 2015, at 12:33 AM, Declan Ma <[email protected]> wrote: > > Tim, > > Thanks for your explanations. > > Yet since the very draft keeps talking about Resource Transfer and deems it > as one of the “Operational Considerations” in Section 3, we might pay > attention to Steve’s statement as below: > > > So, when folks claim that this alg allows for transfers to not have to follow > a strict ordering of RPKI actions, that is only partly true. Issuing a new CA > cert with resources not yet transferred to the target can actually enable the > target to generate bogus ROAs that will validate, unless certain precautions > are taken. Every CA has to be sure that IF it issues a cert to a subordinate > because of an anticipated transfer, that this act does not enable the > subordinate > (or a child of the subordinate ...) to issue bogus ROAs! Right now we have no > agreed-upon resource transfer process for the RPKI, to ensure that this sort > of > vulnerability does not arise. Yet the suggestion is to change the validation > procedure before having such a process in place. Not such a good idea. > > > As Randy’s draft relating to Resource Transfer is still in progress, it would > be not wise to seek solutions to the so-called fragility in validating > certificates when we have no agreed-upon resource transfer process for the > RPKI. > > > Di > > >> 在 2015年11月26日，20:29，Tim Bruijnzeels <[email protected]> 写道： >> >> 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 > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
