Resource Public Key Infrastructure (RPKI) Validation Reconsidered
Note: This ballot was opened for revision 08 and is now closed.
Alvaro Retana Yes
Deborah Brungard No Objection
Comment (2017-08-29 for -08)
I was confused also if this was an update based on the abstract and shepherd writeup. As it was decided not to be an update, but to be a new procedure, suggest tweaking the wording on update/modify, e.g. in the Abstract: updated procedure/s/procedure.
Ben Campbell (was Discuss) No Objection
Comment (2017-11-16 for -09)
Thanks for resolving my DISCUSS points. I note that there is new explanatory text in the abstract. I suggest similar text be added in an introductory section in the body, since readers are known to sometimes skip the abstract. I am leaving my other comments below for documentation purposes; I leave it to the authors and shepherd to decide if they are sufficiently addressed. ------------------- Substantive: - General: There's a lot of amending going on here--does this draft really not update any RFCs (e.g. 6487)? - 220.127.116.11: -- "Any extension not thus identified MUST NOT appear in certificate x." (Repeats multiple times) That seems to prevent future extensibility. Is that the intent? -- "Certificate x MUST NOT have been revoked, i.e., it MUST NOT appear on a CRL issued by the CA represented by certificate x-1" Is this intended as a requirement to check CRLs? If so, please say that explicitly. Editorial: -18.104.22.168: The third paragraph seems redundant to the first paragraph (pattern repeats in several sections.)he - 22.214.171.124: "Either the IP Resources extension, or the AS Resources extension, or both, MUST be present in all RPKI certificates, and if present, MUST be marked critical." "... and if present..." seems redundant, since the previous clause said one MUST be present. - 126.96.36.199: "... values are NOT supported..." a floating, capitalized "NOT" is not defined in RFC 2119. I suspect the all-caps is just for emphasis, but we typically reserve that for RFC 2119 keywords. - 188.8.131.52 : -- "Certificate validation requires verifying that all of the following conditions hold, in addition to the certification path validation criteria specified in Section 6 of [RFC5280]." The "... in addition to..." part doesn't seem quite true. For example, making sure the current date fits in the active range, ensuring a cert is signed by the issuer, etc. are already covered in 5280. - - "...certificate MUST contain all extensions defined in section 4.8 of [RFC6487] that must be present." That seems tautologically true. If this is a statement of fact, then please avoid the MUST. If this is really a new normative requirement, then I'm confused at the intent. -- "all extensions defined in section 4.8 of [RFC6487], except sections 4.8.9, 4.8.10 and 4.8.10 MUST be present. " It would be more reader-friendly to mention what extensions are defined in 4.8.9. -- "7. Compute the VRS-IP and VRS-AS set values as indicated below:" Inconsistent voice. -- list entry 7, 4th bullet: "If the IP Address Delegation extension is present in certificate x and x=1, set the VRS-IP to the resources found in this extension." That seems identical to the first bullet. Should it has said "AS Address Delegation extension"?
(Benoit Claise) No Objection
Spencer Dawkins No Objection
Comment (2017-08-27 for -08)
I had the same question Mirja did. Thanks, Alvaro, for your response.
Suresh Krishnan No Objection
Mirja Kühlewind No Objection
Comment (2017-08-24 for -08)
Given this new mechanism seems to be the recommended way of doing things, I would expect that this draft updates RFC 6487.
Terry Manderson (was Discuss) No Objection
Thank you for adding text into the document that placates my DISCUSS concerns until others look to implement (and use in anger) this in the wild. I'm going to leave a part of my original thoughts on this document here for future reflection: "I get the sense that many of the ramifications for this validation change are yet to be discovered. It worries me that from the shepherd writeup "The existing CA/RP code implementations will support this once published." What experiments have been done to identify any gaps and assumptions?" And further add that the RPKI is starting to appear, in my eyes, exceptionally fragile when faced with operational realities and also quasi-political issues surrounding trust anchors. Without doubt the underpinnings of routing security and integrity is hard, no surprise that this effort (as one of many that has preceded it) also struggles.
Alexey Melnikov No Objection
Comment (2017-08-30 for -08)
I am agreeing with Ben's comments and I am generally concerned about lack of certificate extensibility in SIDR. (But I've raised this question when reviewing an earlier SIDR document and the WG didn't change its mind.) In Section 184.108.40.206: 3. The Version, Issuer, and Subject fields of certificate x satisfy the constraints established in Section 4.1-4.7 of this specification. There is no section 4.7 in this draft, so I think this should point to the original RFC from which this text was copied. On page 16: * If the IP Address Delegation extension is present in certificate x and x=1, set the VRS-IP to the resources found in this extension. This looks like a cut & paste error. I think you meant "Identifier" and "VRS-AS" above?
(Kathleen Moriarty) No Objection
Comment (2017-08-30 for -08)
I agree with Ben and Alexey as well as EKRs comments.
Eric Rescorla No Objection
Comment (2017-08-26 for -08)
TECHNICAL S 220.127.116.11. Point 5 says: Section 18.104.22.168 or Section 22.214.171.124, or both. The value(s) for each of these extensions MUST satisfy the constraints established for each extension in the respective sections. Any extension not thus identified MUST NOT appear in certificate x. Assuming I am reading this correctly, you are saying that no other extensions at all can be added? That seems contrary to the point of extensions. The 4th bullet of point 7 says: * If the IP Address Delegation extension is present in certificate x and x=1, set the VRS-IP to the resources found in this extension. I think you mean AS Identifier Delegation Can you please clarify whether the new syntax defined in 126.96.36.199 and 188.8.131.52 is just the same syntax as in 6487 with a new OID? If not, can you please describe the differences clearly in this document? EDITORIAL It would help if the abstract were more clear about the problem you were trying to solve. 8. If there is any difference in resources in the VRS-IP and the IP Address Delegation extension on certificate x, or the VRS-AS and This might read better if it were "difference in resources between the..."
Adam Roach No Objection
Comment (2017-08-28 for -08)
This seems like a good change. Not knowing much about the deployment practicalities of BGP, I presume that the set of tools used for validation is sufficiently well-known that CAs will positively know when it is safe to start using the new OIDs? I found the lack of an introduction section to be odd. Please double-check this document against the I-D Nits document; and, in particular, section 2.2: <https://www.ietf.org/id-info/checklist.html#anchor4> I believe "Russ Housley" is misspelled section 8. Please expand the following acronyms upon first use and in the title; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. - RPKI - Resource Public Key Infrastructure - AS - Autonomous System - ROA - Route Origin Authorization - CA - Certificate Authority - CRL - Certificate Revocation List
Warren Kumari Recuse
Comment (2017-08-28 for -08)
I am recusing myself from balloting on this document.