On Mon, Aug 13, 2012 at 12:56 AM, Byron Ellacott <[email protected]> wrote: > Hi Chris, > > On 11/08/2012, at 12:00 AM, Christopher Morrow wrote: > >> On Fri, Aug 10, 2012 at 1:18 AM, Byron Ellacott <[email protected]> wrote: >>> (But this is sort of my point, the RPKI system's verification of right of >>> use breaks down if you start certifying multiple people as having a >>> simultaneous right to use resources :-) >> >> but that model has to exist as you have many situations today with a >> single prefix and multiple ASN for origin... there's a commentor on >> this thread who proposed (and got through the IESG) such a draft/rfc, >> in the GROW wg I believe. > > Sorry, I wasn't very clear there - I don't mean to suggest that an operator > should not be able to issue multiple ROAs, I mean to suggest that a CA should > not certify multiple entities as the current, unique holder of resources, as > per RFC 6484, and that it is the trust model that breaks down when you > violate the CP document, not the operational verifiability of the bits and > bytes. >
ah! i agree that a CA shouldn't, ideally, certify more than 1 entity as 'owning' a resource. I think this gets at part of terry's concern(s) as well? > I have objected to adoption because it seems to me that the intent of the > draft is to create a practice of certifying two entities at once, > indefinitely; I do not object to solving a real operational problem, so I > would withdraw my objection if the draft's intent is for a strictly > transitional process, with revocation of C to be addressed somehow. > I think the point of the doc is to fix broken downstreams... I suppose a step to de-register/de-certify could be put in the middle between 'oh crap, vzb disappeared as a business' and 'oh, johnny-vzb-customer can no longer be seen in the routing system, quick issue him a replacement cert!'. Objecting to the draft because of a missing step seems draconian... > I consider this an objection to adoption because the intent is not clear. > The intent can be clarified without updating the document's content, though a > content update would be necessary to express the intent, down the line. > if the content isn't clear then we need to rev the draft with the 'right' content, right? In principle the problem (oops, ISP12 disappeared as a business) shows up 'often' in the real world, we ought to have a documented solution to that problem, and this draft seems to aim us in that direction... sure it has some rough edges to smooth out, I'm sure the authors would welcome text for their grindstone. > Byron > Still speaking for myself, of course. me too! (though if I try speaking for others my lips still move, I'm a horrible ventriloquist) -chris _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
