Tim: Thanks for taking the time to read the document and submit a review. > On Apr 7, 2022, at 5:09 PM, Tim Bray via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Tim Bray > Review result: Ready with Issues > > I have reviewed draft-ietf-sidrops-rpki-has-no-identity-05. > > It seems obvious that the WG needs to develop consensus whether or not a > document such as this, which essentially says "REALLY don't do what this other > RFC says not to", is a useful and appropriate tool. If no such consensus exists > we can stop reviewing revisions and save time. Yes. In fact, this seems to need repeated and highlighted. This was written when a system was deployed. initially, I considered it a reminder, but the SIDROPS WG felt that it was important enough to publish. > If we assume that the document is useful and appropriate… > > - In section 2, the title "The Bottom Line" doesn’t seem appropriate. Could > this be expressed a little less figuratively? I am not really sure what section title works better. How about: The RPKI is for Authorization > - In section 2, the phrase "If it tried to do so, aside from the liability, it > would end in a world of complexity with no proof of termination, as X.400 > learned." leaves me blank. If we assume that this is likely to make sense to > others likely to read this, disregard this. How about we drop the end of the sentence? With some editing, I suggest: That the RPKI does not authenticate real-world identity is by design. If it tried to do so, aside from the additional liability, it would also add considerable complexity. > - In section 2, the two MUST assertions in successive paragraphs are a little > puzzling. Is the second a proper subset of the first (looks like it to me)? If > so, does it need to exist? Maybe it's trying to be an example, in which case it > should say "e.g." instead of "i.e." If it's really an "i.e.", i.e. a > restatement of the first MUST, then why does the first MUST need to exist? > Also, I found the second MUST hard to understand (reminder: not an expert in > this domain, feel free to disregard.) I suggest that we merge the two paragraphs: PKI operations MUST NOT be performed with RPKI certificates other than exactly as described, and for the purposes described, in [RFC6480]. That is, 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. Hopefully this make it clear that he second MUST NOT is talking about an example of the first one. > And, since this is the second time I've been asked, I do have a philosophical > unease about this document. Whenever there is a key-pair, there is an identity > in play: The entity which can arrange for documents to be signed with the > private key. Which in this particular case, means the entity which has at some > point in time could generate ROAs. This draft implies that there could never > in any conceivable world be a useful result of having confidence that some > document was signed by whoever it is that at that point in time could generate > ROAs for some INR out there. Not the “owner”, not the “controller”, just > whoever it is does the ROAs. How can you know that that could never be useful? > In general, when a protocol element or online resource can be used to do > something, and someone comes around saying “but you shouldn’t want to do that > thing”, I get nervous. It is an authorization, not an identity. RFC 6484 says: The most important and distinguishing aspect of the PKI for which this policy was created is that it does not purport to identify an INR holder via the subject name contained in the certificate issued to that entity. Rather, each certificate issued under this policy is intended to enable an entity to assert, in a verifiable fashion, that it is the current holder of an INR based on the current records of the entity responsible for the resources in question. Verification of the assertion is based on two criteria: the ability of the entity to digitally sign data that is verifiable using the public key contained in the corresponding certificate, and validation of that certificate in the context of this PKI. Russ -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
