Re: [sidr] Questions about draft-huston-rpki-validation-01

[Geoff Huston <[e-mail]>]

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 <[e-mail]> 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
> 
>