On Dec 2, 2015, at 5:23 AM, Geoff Huston <gih...@gmail.com> wrote: > >> On 2 Dec 2015, at 11:32 AM, Sandra Murphy <sa...@tislabs.com> wrote: >> >> Speaking as regular ol’ member: >> >> On Dec 1, 2015, at 9:42 AM, Andrei Robachevsky >> <andrei.robachev...@gmail.com> 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. > >> >> 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. > >> >> 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. >> 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. —Sandy
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
