This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ncc-services-wg@ripe.net/
[ncc-services-wg] 2013-04 New Policy Proposal (Resource Certification for non-RIPE NCC Members)
- Previous message (by thread): [ncc-services-wg] 2013-04 New Policy Proposal (Resource Certification for non-RIPE NCC Members)
- Next message (by thread): [ncc-services-wg] Updated Draft Agenda NCC Services WG - RIPE 66
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Sander Steffann
sander at steffann.nl
Mon May 20 22:34:06 CEST 2013
Hi, > A realistic solution to this issue is not to have to move the NCC (except in really extreme circumstances), a solution could be to have a distributed trust-root (maybe the other RIRs, maybe trusted 3rd parties or a combination thereof). An operator can then choose to trust some, but not other, roots or accept a majority decision). The important feature is that there is no single point where an attack succeeds. This avoids the fatal flaw that a single trust-root implementation represents and, to an extent, preserves the distributed nature of the DFZ. Indeed, this would remove my *only* point of contention. How would other parties get the certainty that they are issuing the certificates to the correct holder? The RIPE NCC is the single root of the address space managed by them. The NCC has contractual relationships with the holders etc. How would a third party be able to reliably certify that? Cheers, Sander
- Previous message (by thread): [ncc-services-wg] 2013-04 New Policy Proposal (Resource Certification for non-RIPE NCC Members)
- Next message (by thread): [ncc-services-wg] Updated Draft Agenda NCC Services WG - RIPE 66
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]