Reviewer: Tim Bray Review result: On the Right Track I have reviewed draft-ietf-sidrops-rpki-has-no-identity-04. Preliminary disclosures: I have never previously encountered RPKI and don't know much about BGP. I do understand PKI issues reasonably well. Summary: The authors point out that RFC 6480 is at pains to establish that its certs and keypairs do not assert the identity of any organization, but rather just the capability of issuing ROAs to support routing. They discuss problems that could occur should these certs be used in a way that implies they identify some organization, and go on to say, in section 2, “RPKI-based credentials of INRs MUST NOT be used to authenticate real-world documents or transactions without some formal external authentication of the INR and the authority for the actually anonymous INR holder to authenticate the particular document or transaction.” Then they repeat this MUST in section 4. Upon reading this, the following issues occur. None of the questions below are rhetorical; as mentioned above, my expertise here is very limited. 1. Is this sort of bad-practice use of RPKI keypairs actually occurring? Ie. is there a threat that needs to be staved off? I hypothesize that some Internet-Draft somewhere has suggested this mis-use of RPKIs and the purpose of draft-ietf-sidrops-rpki-has-no-identity is to give reviewers an extra leg to stand on when saying "Don't do that". Which seems reasonable but shouldn't be necessary? 2. Assuming that people are doing this and we want them to stop, is issuing this sort of RFC the best way, or even likely to be effective, at doing so? I grant that it might be effective in suppressing this bad practice in I-Ds but 6480 seems pretty clear to me. 3. The single MUST assertion being repeated twice is unnecessary. 4. The MUST assertion feels unnecessarily complicated and long-winded. I think what they're trying to say is "You MUST NOT perform PKI operations with these certs except exactly as described, and for the purposes described, in 6480.” 5. The discussion in section 3 about how the holders of RPKI keys probably don't issue their own certs but get CAs to do that left me a bit puzzled. Is the conclusion that we should admonish CAs not to do this? Or is it the case that some key-holders do issue their own certs but are Being Bad? 6. Section 3 is kind of long and discursive and could likely be shortened without loss of value. The document might be more useful if there were subsection 3.1 Issuers of RPKI certificates, 3.2 Organizational issues, etc It should be obvious that I don't understand whether there's a bad-practice problem out there, who the bad practitioners are, and whether this document as an RFC will help stop them. If it is the case that there is some organization that is mis-using RFC6480 keys and there is a case to be made that a follow-up RFC will curtail this practice, then this draft contains the basis of such an RFC. [It is also possibly the case that those better acquainted with RPKI will instantly understand what the problem is and why the language herein will help deal with it, in which case feel free to ignore most of my comments. ] -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
