RPKI Validation Reconsidered
Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
Ben Campbell Discuss
This is probably just a matter of me being dense, but I'd like to understand what I am missing: Is it legal to mix certificate policies in a given cert path? The last paragraph of section 5 implies that you can, but doesn't say so explicitly. If you _can_ mix policies, what happens if you do? If I read the rules in 188.8.131.52. correctly (and it's likely that I am not), if you run into a cert in the chain that does not follow this profile, it's likely to give a null VRS-IP or VRS-AS value, which would seem to invalidate an certificate further down the chain that _does_ follow this policy? So, I guess it comes down to the following: If mixed policies are allowed, how does that work? If mixed policies are not allowed, there needs to be text that says that. It's quite possible such text exists (here or elsewhere), and I missed it.
Substantive: - General: There's a lot of amending going on here--does this draft really not update any RFCs (e.g. 6487)? - 184.108.40.206: -- "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: -220.127.116.11: The third paragraph seems redundant to the first paragraph (pattern repeats in several sections.)he - 18.104.22.168: "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. - 22.214.171.124: "... 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. - 126.96.36.199 : -- "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"?
Terry Manderson Discuss
Thank you for considering the stability of the internet's routing system during administrative changes to resources. One thing isn't quite clear to me, so I'm balloting this as a DISCUSS with the plan that a small amount discussion will resolve it. With the definition of the new validation OID (a idea that I like BTW), at any stage of the certificate issuance can the validation OID be switched? That is a TA has a particular OID and down the tree an issued certificate has a different OID? If that can't happen (and please make that clear in the document) is there plan to migrate the set of all issued certificates to the new OID? and deprecate the old OID? Logically speaking a trust anchor cannot be thought of as over-claiming. (eg you trust where the self signed cert came from, and its contents) However the new validation constructs suggest that a TA can over-claim, but it seems like there won't be any warning (as the example in S4.3) to highlight this possible eventuality when (in the model where all RIRs issue a TA) a resource is transferred from one RIR to another for the clients use. Is that interpretation correct? OR does this new model espouse the belief that all RIRs each issue a TA that covers 0/0 and ::/0 in perpetuity? In that construct does this mean that RFC6491 should be updated or made historic?
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?
Alvaro Retana Yes
Deborah Brungard No Objection
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.
Benoit Claise No Objection
Spencer Dawkins No Objection
I had the same question Mirja did. Thanks, Alvaro, for your response.
Suresh Krishnan No Objection
Mirja Kühlewind No Objection
Given this new mechanism seems to be the recommended way of doing things, I would expect that this draft updates RFC 6487.
Alexey Melnikov No Objection
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 188.8.131.52: 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
I agree with Ben and Alexey as well as EKRs comments.
Eric Rescorla No Objection
TECHNICAL S 184.108.40.206. Point 5 says: Section 220.127.116.11 or Section 18.104.22.168, 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 22.214.171.124 and 126.96.36.199 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
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
I am recusing myself from balloting on this document.