Hi Sriram, I am espousing method B in your terminology.
Perhaps if I rephrase the validation question a little, it may be a little clearer. The validation question is: Given a certificate X and a TA certificate, for what resources is this certificate "valid"? You point out > (In terms of language and clarity, the notion of calling a certificate > "valid" > is misleading when in fact all that is being checked is merely > whether a given INR is subsumed in it.) Maybe there is a way of tightening this up. How about: A resource contained in the resource extension of a certificate is defined as "valid" if this resource is listed in the resource extension field of all certificates that are contained in a certification path, where the construction of this certification path is defined in section 6 of RFC5280. Back you your example...So the question posted by the ROA, which is signed by certificate 3, is "Is certificate 3 valid for 10.0.0.0/24?" As you've described here the certification path is Cert 1, Cert 2, and Cert 3, and as 10.0.0.0/24 is contained in the resource extension of all of these certificates then it can be concluded that the question posed by the ROA, namely whether certificate 3 is valid for 10.0.0.0/24, can be answered in the affirmative. (In the WG I also considered a slightly expanded question: Given a certificate X and a set of TA certificates, for what resources is this certificate "valid"?, but that proved to be a little more controversial for many!) regards, Geoff On 13 Mar 2014, at 7:17 am, Sriram, Kotikalapudi <[email protected]> wrote: > Geoff, > > About my Question (3), let us discuss this a bit more carefully with an > example. > > There is this ROA: {10.0.0.0/24, AS64499} that we wish to validate. > It is signed with Certificate 3, which has the following certificate path to > the TA: > Certificate 1: It lists {10.0.0.0/12, AS64501, AS64505, AS64509} (TA > certificate) > Certificate 2: It lists {10.0.0.0/22, AS64501, AS64505, AS64511} > Certificate 3: It lists {10.0.0.0/20, AS64501, AS64505} > Note: Certificate 1 is the TA certificate. > > It is clear that following the current (RFC 3779) method, > Certificates 2 and 3 are invalid, and it follows that the ROA is invalid. > > Now, there are two methods that we may enumerate for a modified (or > alternate) > validation proposal: > > Method A (more conservative but less robust relative to Method B below): > > Step 1: Ask what certificate is used to sign the RAO? Answer: Certificate 3. > > Step 2: Do the resources in Certificate 3 subsume the prefix in the ROA? > Answer: YES, > because "the INR of interest" 10.0.0.0/24 in the ROA is subsumed by > an INR 10.0.0.0/20 in Certificate 3. OK, now proceed to validate Certificate > 3. > Note that "the INR of interest" in Certificate 3 is 10.0.0.0/20. > > Step 3: Ask if the resources in Certificate 2 subsume "the INR of interest" > in Certificate 3? > Answer: NO, because "the INR of interest" 10.0.0.0/20 in Certificate 3 is NOT > subsumed > by an INR in the parent Certificate 2. > (Note: The parent Certificate 2 has a more specific prefix 10.0.0.0/22.) > > Step 4: Since the certificate chain "validation" failed at Step 3, declare > the ROA > being considered as "Invalid" for the prefix-origin pair {10.0.0.0/24, > AS64499} . > > Method B (less conservative but more robust relative to Method A above): > > Step 1: Ask what certificate is used to sign the RAO? Answer: Certificate 3. > > Step 2: Set "the given INR" as 10.0.0.0/24. That is the INR in the ROA for > which > validation is being sought. > [Note: "The given INR" remains a constant in the steps that follow. > We just *stay focused on this given INR* for the rest of the validation > process below. > This is the main difference compared to method A.] > > Step 3: Do the resources in Certificate 3 subsume the "the given INR" > 10.0.0.0/24? > Answer: YES, because the given INR 1.0.0.0/24 is subsumed by an INR > 10.0.0.0/20 in Certificate 3. > > Step 4: Do the resources in Certificate 2 subsume the "the given INR" > 10.0.0.0/24? > Answer: YES, because the given INR 1.0.0.0/24 is subsumed by an INR > 10.0.0.0/22 in Certificate 2. > > Step 5: Do the resources in Certificate 1 subsume the "the given INR" > 10.0.0.0/24? > Answer: YES, because the given INR 10.0.0.0/24 is subsumed by an INR > 10.0.0.0/12 in Certificate 1. > > Step 6: Since the certificate chain "validation" passed at each step above > for "the given INR" 10.0.0.0/24, declare the ROA being considered > as "Valid" for the prefix-origin pair {10.0.0.0/24, AS64499} . > > So Method A produces an "Invalid" result for the ROA, > whereas Method B yields a "Valid" result. > I hope the difference between Methods A and B is clear. > In Method A, "the INR of interest" at level x must be subsumed by an INR at > level x+1. > But in Method B, only "the given INR" (e.g., a prefix in a ROA or an ASN in a > router certificate) > is the steady focus, and what is required is that "the given INR" must be > subsumed > by resources listed in the certificate at each level (1, 2, 3, ..., n). > > The description on your Slide #18 falls short of describing precisely > either Method A or Method B. From your Slide #14, it seems evident that you > are > proposing Method B; am I right? > (In terms of language and clarity, the notion of calling a certificate > "valid" > is misleading when in fact all that is being checked is merely > whether a given INR is subsumed in it.) > > Sriram > > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
