> On 3 Dec 2015, at 5:28 AM, Sandra Murphy <[email protected]> wrote: > > > On Dec 2, 2015, at 5:23 AM, Geoff Huston <[email protected]> wrote: > >> >>> On 2 Dec 2015, at 11:32 AM, Sandra Murphy <[email protected]> wrote: >>> >>> Speaking as regular ol’ member: >>> >>> On Dec 1, 2015, at 9:42 AM, Andrei Robachevsky >>> <[email protected]> wrote: >>> >>> >>> 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 > > Yep, my bad, that’s a typo, the quote is from RFC6482. Sorry about that. > > Attempt to be precise and miss a point. Hate that.
I do it all the time. sigh. > >> >>> >>> 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 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.) > > That’s not my understanding of what the text currently says will happen. > Note that I am not disagreeing that this is the desired result. (I did say > “that’s bad”, above, remember.) > > By my understanding of validation-reconsidered, the C EE cert would be valid > but the valid resources in the valid C EE cert would be only 1.0.0.0/24. > > The actual text of RFC6482 says that the “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.” > > Set 1: "each IP address prefix(es) in the ROA" : 1.0.0.0/24, 3.0.0.0/24 AS1 > > Set 2: "the set of IP addresses specified by the EE certificate's IP address > delegation extension": 1.0.0.0/24, 3.0.0.0/24 > > is set1 contained within set2? Yes. > > So (under validation-reconsidered) the ROA meets the RFC6482 condition, as > the text currently stands. So the ROA would be valid. That’s a good point, and in my world that’s not the desired outcome. Which implies that a revision of the validation algorithm should have something to say about the set of number resources in an EE certificate that can be considered - informally each of the “good” resources in an EE cert must be present in each of the CA certs in the validation path. And secondly it should specifically consider ROAs, and possibly considere the more generic case and consider whether the “bundle” of resources is a critical element of the signed attestation. My intuitive reaction is that a ROA is an “all or nothing” prospect, so you can’t have a valid ROA with a subset of INRs listed in the ROA, but others may see it differently. > >> >>> >>> 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. > > Under validation-reconsidered, I would say that the ROA should be valid if > the IP addresses it contains are contained within the *valid* resources among > the resources specified in the EE cert. > > We need to say that because the valid resources specified in a valid EE cert > could be a proper subset of the resources specified in the EE cert. As your > examples show. Just “contained within” is not going to be sufficient > specification. > > No biggie, just a need for more precise text, under validation-reconsidered. agreed by me at any rate. > > >>> 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. > > Good, then I’ve got that much of validation-reconsidered right. > Its a good point, however, and I hope its been useful to consider in this way. regards, Geoff _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
