Hi Sriram,
> On 28 Nov 2015, at 10:52 AM, Sriram, Kotikalapudi > <[email protected]> wrote: > > 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. yes in both cases > 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). qualitative judgment: no, not in my view > > 2. How do you perform the validation of a CRL? RFC6487 provided no guidance, and referred to RFC5280, so that is still the case. nothing changes herre. > How is it similar to or different from how you validate a ROA? There are no resources in a CRL so I presume that section 6.1 of RFC5280 is a good procedure to follow. > How do you walk the certificate hierarchy in the case of a CRL validation > process? > I.e. How are the "encompassing" rules applied? huh - I’ll say it again just to be sure: CRLs have no resources. > I think this should be explicitly explained/clarified in the document. I disagree. Geoff > > Sriram > > ________________________________________ > From: sidr <[email protected]> on behalf of Tim Bruijnzeels > <[email protected]> > 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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
