Resource Public Key Infrastructure (RPKI) Validation Reconsidered
draft-ietf-sidr-rpki-validation-reconsidered-10

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

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 4.2.4.4:

   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?

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)?

- 4.2.4.4: 
-- "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:

-4.2.2.1: The third paragraph seems redundant to the first paragraph (pattern repeats in several sections.)he 

- 4.2.4.3: "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.

- 4.3.4.3: "... 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.

- 4.2.4.4 : 
-- "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"?

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.

TECHNICAL
S 4.2.4.4.
Point 5 says:

       Section 4.2.4.2 or Section 4.2.4.3, 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 4.2.2.2 and 4.2.2.3
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..."

I agree with Ben and Alexey as well as EKRs comments.

Given this new mechanism seems to be the recommended way of doing things, I would expect that this draft updates RFC 6487.

I had the same question Mirja did. Thanks, Alvaro, for your response.

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.