Tim, Your explanation does lay it out more clearly, and it is consistent with how I understood it before. However, I have two questions/suggestions:
1. A question/suggestion about the new validation algorithm: Consider the following cert-chain, ROA example: TA: {5.0.0.0/8, 8.0.0.0/12, AS1-AS100} CA1: {5.0.0.0/20, 8.0.0.0/18, AS1-AS400} CA2: {5.0.0.0/24, 8.0.0.0/20, AS1-AS50} <-- note the "narrowing" of sub-cone in the 5.0.0.0/x space CA3: {5.0.0.0/22, 8.0.0.0/22, AS1-AS500} <-- note the "widening" of sub-cone in the 5.0.0.0/x space CA4: {5.0.0.0/24, 8.0.0.0/24, AS1-AS5} (Hint: picture specific-resource sub-cones within the broader cone of varied resources) The EE certs are: EE1: {5.0.0.0/24} generated from CA4 EE2: {8.0.0.0/24} generated from CA4 And the ROAs are: ROA1: {5.0.0.0/24, AS1000} (signed with EE1) ROA2: {8.0.0.0/24, AS2000} (signed with EE2) I think your proposed validation algorithm would determine that EE1, EE2, ROA1 and ROA2 are all valid. However, if you require that the specific resource (e.g. 5.0.0.0/24) -- that is relevant to the ROA or the EE cert being validated -- MUST have a “non-narrowing sub-cone” in the cert chain resources, then EE2 and RAO2 will be still valid, but EE1 and ROA1 will be invalid. By “non-narrowing sub-cone” (for a specific resource/prefix), I mean the following: As we move up the cert-chain, the “relevant” or “corresponding” prefixes (relative to the specific prefix in consideration) seen at each level in the hierarchy of certs must be such that the same prefix or a less specific is found at each level relative to the level directly below. As you can see in the example, non-narrowing sub-cone is true for 8.0.0.0/24 (EE2), but not for 5.0.0.0/24 (EE1). Hence, EE1 and ROA1 are invalid (under this enhancement). Do you think there merit in this approach over what you have now in validation reconsidered? This somewhat less lenient approach would seem a bit more sensible (at least in my mind). 2. How do you perform the validation of a CRL? How is it similar to or different from how you validate a ROA? How do you walk the certificate hierarchy in the case of a CRL validation process? I.e. How are the "encompassing" rules applied? I think this should be explicitly explained/clarified in the document. Sriram ________________________________________ From: sidr <sidr-boun...@ietf.org> on behalf of Tim Bruijnzeels <t...@ripe.net> Sent: Thursday, November 26, 2015 7:29 AM To: Stephen Kent Cc: sidr Subject: Re: [sidr] Validation Reconsidered (again/again) question Hi, > On 25 Nov 2015, at 21:19, Stephen Kent <k...@bbn.com> wrote: > > None of those who believe that this draft is a good thing seem to have > addressed > an issue I raised a while ago; the proposed solution is ill-defined and, the > most > likely interpretation doesn't seem to work, in general. I'll try to explain > this > reasoning, again, and provide an example. I believe the draft is being precise, but in the process has become difficult to parse. Let me attempt once more to explain the proposal in a different way: "When doing top-down validation of resource certificates in the RPKI we propose that rather than rejecting a certificate that has resources not held by the parent (but is valid on all other respects), we would accept the certificate but keep note of the actual resources we believe it can be authoritative for. I.e. the intersection of resources on this certificate and the resources accepted for the parent. The RP SHOULD however issue a warning in case certain resources are excluded because of this, so that the responsible CA can fix the situation. Please note that for ROAs there is a requirement that all ROA prefixes are included on the EE certificate of the (ROA) signed object CMS. This proposal does not change this. A ROA that has prefixes that were removed for whatever reason higher in the path would still become invalid using this algorithm. We would therefore RECOMMEND that CAs issue 1 ROA for each prefix, and avoid fate sharing. That way only ROAs for prefixes that were removed will be affected." Essentially that really is all there is to it. If this is easier to parse, and the co-chairs conclude that work should continue, then I am happy to use this line of explanation in a next version of the document. And no, I have no doubt that it will need more detail than above in an I-D - but it's the basic principle that I am trying to convey here. Tim _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr