North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
In message <[email protected]>, Randy Bush writes: > >>>> We are discussing how we can do subsidiary certificate services like >>>> this in APNIC but I think this goes outside of routing policy and >>>> into registry business practices which are unlikely to be common >>>> for all RIR and NIR in the ways that resource certificates *have* >>>> to be. >>> >>> if it is not common across registries, and if my certs do not >>> work across registries, then something is very very broken, >>> and a major pita at the isps', aka your members', expense. >> >> If you want to see member-certificates which gate access to >> RIR/NIR specific services common across all registries, I think >> you want to get that onto an RIR meeting agenda Randy. > >i have been whining about the problems of cross-registry operation >for over a decade, formally, informally, presos, ... i have had it >on every rir's meeting agenda (except lacnic) for many years. do i >need to iterate for every ort of service the registries provide? > >we are the registries' customers. many of us, especially the ones >who pay the registries the most, have to deal with multiple >registries. can the registries please get over the inter-registry >rivalry and make life more reasonable for us, the paying members? > >> We currently have no cross-certification activity in member identity. > >where as before i was merely inclined, this has just made me an >extremely strong proponent of the isp web of trust identity model. > I think the problem is both easier and harder than painted. First, you need a business agreement that you will accept each others' assertions of member identities, aka certificates. Second, you have to agree on a common format and meaning for certain fields, including thinks like CRLs. I'm not sure if I think the technical specs or the business agreement are the hard parts... --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
|