RPKI Validation Reconsidered

Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.

Ben Campbell Discuss

Discuss (2017-08-28)
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 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.
Comment (2017-08-28)

- General: There's a lot of amending going on here--does this draft really not update any RFCs (e.g. 6487)?

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


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

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

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

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

Discuss (2017-08-30)
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?
Comment (2017-08-30)
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

Comment (2017-08-29)
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

Comment (2017-08-27)
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)
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

Comment (2017-08-30)
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

   3.  The Version, Issuer, and Subject fields of certificate x satisfy
       the constraints established in Section 4.1-4.7 of this

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)
I agree with Ben and Alexey as well as EKRs comments.

Eric Rescorla No Objection

Comment (2017-08-26)
Point 5 says:

       Section or Section, 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

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 and
is just the same syntax as in 6487 with a new OID? If not, can you please
describe the differences clearly in this document?

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)
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)
I am recusing myself from balloting on this document.

Alia Atlas No Record

Alissa Cooper No Record