On Wed, 2009-09-23 at 17:48 +0200, Andrei Robachevsky wrote: > First of all, validation is performed by a relying party, for instance > an ISP. Secondly, the RIRs do not authorise the origin of a prefix, that > is done by a prefix holder. What the RIRs and LIRs and all other parties > in the chain of resource allocation do is attest to the that at the time > of issuance of a certificate the holder of the address space listed in > the extensions demonstrated possession of the private key. These basic > RPKI data can be used in other application, securing routing, for instance.
Perhaps I could clarify. I am speaking of validation of the information on the ROA rather than the validation of a chain of authority that ultimately validates the prefix/origin pairs. Please correct me if I am misunderstanding or confusing terms here. As a hypothetical illustration, let's say that RIPE were to issue 2.2.0.0/16 over to Verizon Business (702) and we had an RPKI in place. Let us also say for the sake of discussion that everyone agreed on RIPE as the trust anchor for 2.0.0.0/8. In the world of SSL/TLS certificates our friends over at CyberTrust (for example) have an incentive to make sure I am truly associated with the verizonbusiness.com domain name in the CN field of my cert request before they their stamp of approval on my certificate request (fax, mail-from, government & employer id...). They are doing more than simply validating that I have the associated private key with the public key on the cert request. The ongoing revenue stream for CyberTrust is directly tied to its reputation. It has every reason to do their due diligence and confirm that I am tied to the resource. As a user with a root CA store I can decide whether or not to have CyberTrust's CA in my list. An RIR may not have the same incentives to verify that me and my public key are truly associated with AS702 - so as an RP I need to think about how much I trust that the public key associated with a ROA that comes from this RIR. Further, as a provider I do not have the same ability to take my business elsewhere with regards to an RIR and allocated resources. As a corporation I can choose to end all associations with CyberTrust, both as a signer of our certificates and as a trusted CA much easier than cutting all ties with an RIR in a region I operate. The survival of an RIR is not as intricately tied to its vigilance as with the SSL model - that is the gist of what I am saying. -Ryan > Regards, > > Andrei > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > sidr mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/sidr
signature.asc
Description: This is a digitally signed message part
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
