Hi Ben, all, > On 15 Sep 2017, at 23:20, Ben Campbell <[email protected]> wrote: > > Hi, > > See comments inline. I apologize in advance if I am just being dense, and I > cannot claim to be an expert on how one applies a path validation policy OID > in general. > > > Thanks! > > Ben. > >> On Sep 14, 2017, at 7:00 AM, Tim Bruijnzeels <[email protected]> wrote: >> >> Hi, >> >> Sure. I also proceeded to discuss your and Terry’s points, but apparently >> not to the desired level of clarity. Let me try again here, and tackle both >> your and Terry’s discuss items since they are closely related. >> >>> Is it legal to mix certificate policies in a given cert path? The last >>> paragraph of section 5 implies that you can, but doesn't say so explicitly. >> >> According to this document it is. Section 4.2.2.4 starts with the following: >> >> The following is an amended specification for path validation to be >> used in place of section 7.2 of [RFC6487] allowing for the validation >> of both certificates following the profile defined in [RFC6487], as >> well as certificates following the profile described above. >> >> So the intent here is to describe a single validation algorithm that can be >> used to validate a chain of old OIDs only (in which case it’s semantically >> equivalent to the current spec in RFC6487), new OIDs only (as described in >> the example in 4.3), or indeed a mix - but no example is given on how that >> works out. >> >> >>> If you _can_ mix policies, what happens if you do? If I read the rules in >>> 4.2.4.4. >>> correctly (and it's likely that I am not), if you run into a cert in the >>> chain >>> that does not follow this profile, it's likely to give a null VRS-IP or >>> VRS-AS >>> value, which would seem to invalidate an certificate further down the chain >>> that _does_ follow this policy? >> >> >> The “Validated Resource Sets” (VRS-*) are always calculated, regardless of >> whether the old or new OIDs are used. > > This is where I am confused. The calculation of VRS is described in this > draft in the amendment to the path validation in section 7.2 of 6487. I > assumed that the amended path validation procedure only applies with the > “new” OID. Is that incorrect? If so, can you point to the text that states > that? (It’s entirely possible I missed something, or completely misunderstand > how the OIDs are applied. )
First paragraph of 4.2.2.4: "The following is an amended specification for path validation to be used in place of section 7.2 of [RFC6487] allowing for the validation of both certificates following the profile defined in [RFC6487], as well as certificates following the profile described above." So, yes, as far as I am concerned the intent was to have this cover both the old and new OIDs. Where the algorithm if applied to old OID only is semantically equivalent to section 7.2 of RFC6487 - or at least: it has the same outcome. If this needs to be more explicit I am happy to accept a suggestion - as an author knowing my own intentions, it’s not always trivial to see how others would interpret text differently. Kind regards Tim Bruijnzeels _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
