I would be interested in seeing the issue below resolved in definitive language (maybe someplace stronger than the CP template).
While I think the spirit of this draft was to show techniques that could be useful during incremental/partial deployment, there are some folks highly concerned about the potential for unwanted manipulation of the RPKI by outside influences on the allocation hierarchy. This draft has become the cook-book for their arguments of how this could be done. I.e., grandparents issues certs and ROAs that conflict with, or invalidate the CERT/allocation hierarchy beneath them. I see enough FUD in this space, that I think the issue should be addressed in SIDR somehow. dougm -- Doug Montgomery Mgr. Internet & Scalable Systems Research / ITL / NIST On 8/5/12 9:25 PM, "Byron Ellacott" <[email protected]> wrote: >Hi Alexey and list, > >I oppose this acceptance call. The draft makes no reference to the >conflict with the CP draft (6484) [1] with respect to the requirement >that certificates issued by a CA conform to the record of current >holdings. If a grandchild is not listed in the record of current >holdings, a 6484 compliant CA must not issue certificates in their name; >if the grandchild is listed the record of current holdings, then they are >no longer a grandchild, and there is no need for a grandparenting process. > > Byron > >[1] http://tools.ietf.org/html/rfc6484 sections 1.1, 1.4, and 4.2.2. > >On 05/08/2012, at 4:12 AM, Alexey Melnikov wrote: > >> Hi, >> On behalf of SIDR WG chairs I would like to initiate 2 weeks acceptance >>call for draft-ymbk-rpki-grandparenting starting from today, August 4th. >>Please send your positive or negative feedback to the mailing list or >>directly to chairs. >> >> Thank you, >> Alexey >> >> _______________________________________________ >> sidr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
