> 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: > >> 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.) > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
