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

["Sriram, Kotikalapudi" <[e-mail]>]

Geoff,

Thanks for the reply.
Quoting from your responses,

> I think that is a
>consistent extension, but its a matter that should be further considered.

>(with the same caveat that this is an extension to the described approach to
>certificate
>validation, but an extension that I personally am comfortable with)

Yes, that is right. I think we are in sync on my questions (1) and (2), 
except that as you've said all this needs further consideration by the WG.

For my question (3), we need to delve deeper. Please see my next email.

Sriram 

>-----Original Message-----
>From: Geoff Huston [mailto:[e-mail]]
>Sent: Wednesday, March 12, 2014 2:14 AM
>To: Sriram, Kotikalapudi
>Cc: George Michaelson; sidr wg list
>Subject: Re: Questions about draft-huston-rpki-validation-01
>
>Hi Srinam,
>
>Thanks for your questions - let me try and answer them as best I can...
>
>
>> I went through your -01 draft and the SIDR presentation slides from
>> last week once again, and have the following questions:
>>
>> (1) An update with prefix-origin pair {5.0.0.0/24, AS64511} is received.
>> There is a ROA: {5.0.0.0/22, maxLength = 24; AS64511} in the RPKI.
>> However, it is signed using a certificate that is "valid" only for resource
>{5.0.0.0/24}.
>> In this case, is it the intent of your alternate validation model to
>> ascertain that the above ROA is partially valid, and accordingly prefix-origin
>pair {5.0.0.0/24, AS64511} is "Valid"?
>
>If I understand your question, you are painting the picture where:
>
>The ROA says that AS64511 can announce 5.0.0.0/22 or any subset  up to a /24
>
>The EE cert that signed it has a resource extension of 5.0.0.0/24 (i.e. the ROA is
>overclaiming)
>
>And the CA that signed it has a resource extension set that encompasses
>5.0.0.0/24
>
>And the CA "above" it has a resources extension that encompasses 5.0.0.0/24
>
>etc to the trust anchor
>
>So if we said "is the UPDATE 5.0.0.0/24 valid" then given that 5.0.0.0/24 is
>contained in the ROA, and the same prefix is contained in all the certs from the
>EE cert to a TA in an otherwise valid validation path, then the answer would be
>YES
>
>Although I note that the draft did NOT explicitly talk about the relationship
>between a ROA and the EE cert that signed it. It only talked about the treatment
>of the resource extensions in the pair-wise comparison of certificates in the
>validation path.
>In your question you've extended that same approach to the relationship
>between the EE cert that signed the ROA and the ROA. I think that is a
>consistent extension, but its a matter that should be further considered.
>
>
>>
>> (2) Let us say, there is a ROA: {1.0.0.0/24, 2.0.0.0/22, 3.0.0.0/20; AS64500} in
>the RPKI.
>> But this ROA is signed using a certificate that is "valid" only for resources
>{1.0.0.0/24, 3.0.0.0/20}
>> that is a subset of the prefixes listed in the ROA.
>> In this case, is it the intent of your alternate validation model to ascertain that
>> the above ROA is partially valid, and accordingly prefix-origin pairs
>> {1.0.0.0/24, AS64500} and {3.0.0.0/20, AS64500} are "Valid"?
>
>
>In this example you are again painting a picture of a ROA that "overclaims" as
>compared to the resources
>listed in the EE certificate that signed it.
>
>Assuming that there are validation paths for 1.0.0.0/24 and 3.0.0.0/24 between
>a TA and the EE cert then yes,
>by the same reasoning as the answer to the previous question I would say that a
>consistent answer
>is that these two updates would be accepted as "valid"
>
>(with the same caveat that this is an extension to the described approach to
>certificate
>validation, but an extension that I personally am comfortable with)
>
>
>
>
>>
>> (3) On slide #18, do you need to require "Certificates 1 through n-1 are also
>"valid"
>> according to this same criterion"?  You are not validating them at this point.
>> You are only validating Certificate 'n' for *a given INR*.
>> Is it not enough to require that "the resources in the INR extension of
>> Certificate x must subsume the given INR" for each x (individually); x=1, 2, 3,
>..., n?
>
>
>I was taking the text of RFC3779 that defined the certificate validity (slide 3) and
>was illustrating
>the difference in that text were we to use this approach. I think your formulation
>of the text has the same semantic
>intent as the text on slide 18, but your text highlights the difference from
>RFC3779, while I was
>trying to illustrate what would need to change from the original validation
>definition.
>
>Either that or I have not understood your question! If so, could you explain this a
>bit more?
>
>regards,
>
>    Geoff