Re: [sidr] Validation Reconsidered (again/again) question

[Geoff Huston <[e-mail]>]

> On 2 Dec 2015, at 11:32 AM, Sandra Murphy <[e-mail]> wrote:
> 
> Speaking as regular ol’ member:
> 
> On Dec 1, 2015, at 9:42 AM, Andrei Robachevsky <[e-mail]> wrote:
> 
>> Tim Bruijnzeels wrote on 01/12/15 14:55:
>>>> 
>>>> Tim, I am not sure I understand this. If the parent of the EE cert has a
>>>> shrunken set of resources, will it invalidate the EE or only the
>>>> non-overlapping subset?
>>> 
>>> If the parent has a shrunken resource set this would lead to the EE certificate being accepted only for the intersection of its resources, and the parent. Because there is a requirement that all prefixes on a ROA are included (and accepted in reconsidered) in the resource set of the EE certificate the ROA will be considered invalid.
>>> 
>> 
>> Thank you Tim, this makes sense. Otherwise we will be changing the
>> semantics of ROA, which is tricky. Could you please point me to the
>> place where the requirement is specified?
> 
> In RFC6483, page 5, section 4.  ROA Validation:
> 
>   o  The IP address delegation extension [RFC3779] is present in the
>      end-entity (EE) certificate (contained within the ROA), and each
>      IP address prefix(es) in the ROA is contained within the set of IP
>      addresses specified by the EE certificate's IP address delegation
>      extension.
> 
> Quibble.

RFC6482, section 4

> 
> In the current algorithm, the EE cert that mentioned some of the removed resources will be invalid.  That makes the ROA that mentioned some of the removed resources be invalid.
> 
> Under validation reconsidered, the EE cert will be valid, but not all the resources contained in it will be valid.  However, the EE cert still "contains" the removed resources, so the ROA “contained within” test would still succeed. So a ROA that mentioned some of the removed resources would still be considered valid. (I would say that’s bad.)


I’d say thats bad too.

So how about an example or two:

Example 1:

A CA Cert: 1.0.0.0/24, 2.0.0.0/24

issues:

B CA Cert: 1.0.0.0/24, 2.0.0.0/24, 3.0.0.0/24

issues:

C EE Cert: 1.0.0.0/24

and signs

ROA: 1.0.0.0/24 AS1

all good (assuming that A is a trust anchor)

Example 2:

A CA Cert: 1.0.0.0/24, 2.0.0.0/24

issues:

B CA Cert: 1.0.0.0/24, 2.0.0.0/24, 3.0.0.0/24

issues:

C EE Cert: 1.0.0.0/24, 2.0.0.0/24

and signs

ROA: 1.0.0.0/24 AS1

still all good (assuming that A is a trust anchor)

Example 3:

A CA Cert: 1.0.0.0/24, 2.0.0.0/24

issues:

B CA Cert: 1.0.0.0/24, 2.0.0.0/24, 3.0.0.0/24

issues:

C EE Cert: 1.0.0.0/24, 3.0.0.0/24

and signs

ROA: 1.0.0.0/24 AS1

still all good (assuming that A is a trust anchor)

Example 4:

A CA Cert: 1.0.0.0/24, 2.0.0.0/24

issues:

B CA Cert: 1.0.0.0/24, 2.0.0.0/24, 3.0.0.0/24

issues:

C EE Cert: 1.0.0.0/24, 3.0.0.0/24

and signs

ROA: 1.0.0.0/24, 3.0.0.0/24 AS1

invalid ROA

(or at least that’s my opinion of what should happen. My assumption here is that the ROA IS intentionally a collection of resources where the entirety of the collection is important, so if all elements of the collection cannot be validated via the ROA’s EE certificate then its a dud ROA.)



> 
> Under validation-reconsidered, we would need to make sure this section said something about the validity of the resources in the valid EE cert.


I don’t think its a question of the EE cert, but the question of section 4 of RFC6482 and what validation of the ROA means.

> 
> Just in case it is not obvious:
> 
> Suppose the EE cert always contained more resources than the ROA mentioned.


which is ok today under RFC6482

> 
> Suppose the ROA did not mention the resources that were removed.  In that case the shrinking of the parent causes a shrinking of the set of resources that are contained in the EE cert that are considered valid under validation-reconsidered.  The valid subset of the resources contained in the valid EE cert (i.e., the shrunken resources) would still cover the resources mentioned in the ROA.  So a ROA whose resources were contained exclusively within the retained resources would be valid.  (I would say that’s good.)


i.e. thats like my example 3 above, so I agree thats good from where I sit as well.

> 
> —Sandy, speaking as regular ol’ member
> 
> (We’ve overloaded “Valid” a couple of different ways valid certs, valid ROAs, valid origins, valid Signature_Blocks, …) - it might be nice to readers and users to come up with a different adjective here for the subset of the resources that are contained within the certificate, rather than yet another use of “valid”.   Before we have to talk about valid certs with invalid resources.)
>