|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
From: William Pitcock <nenolod@systeminplace.net> To: Nathan Eisenberg <nathan@atlasnetworks.us> In-Reply-To: <8C26A4FDAE599041A13EB499117D3C281647E30E@ex-mb-1.corp.atlasnetworks.us> Date: Fri, 13 Aug 2010 13:59:14 -0500 Cc: "nanog@nanog.org" <nanog@nanog.org> Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org On Fri, 2010-08-13 at 18:49 +0000, Nathan Eisenberg wrote: > > Isn't this a little bit like an SSL daemon? no. > One which refuses to process a revocation list on the basis of the > function of the certificate is useless. no, it's not. ssl as a form of identity assurance itself is what is useless. > The revocation list only has authority if the agent asks for and > processes it. most don't do this, because: - most SSL daemons don't serve the revocation lists; - most SSL agents don't know how to download the revocation lists from another source. see previous note about SSL being worthless for identity assurance. > Would you use this SSL daemon, knowing that it had this bug? i wouldn't care - see above points. > I would consider a transit provider who subverted an ARIN revocation > to be disreputable, and seek other sources of transit. how do you know if the ARIN revocation is proper? with the IPv4 exhaustion becoming very close to happening now, it is possible that ARIN could "go rogue." following a corporation (yes, ARIN is a corporation) as if you were a sheep will empower them to do precisely this in the future. william
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |