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 <t...@ripe.net> 写道： > > Hi, > >> On 25 Nov 2015, at 21:19, Stephen Kent <k...@bbn.com> 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 > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
