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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
