On Tue, Apr 21, 2020 at 1:48 AM Matt Palmer via dev-security-policy < [email protected]> wrote:
> That ship sailed so very, very long ago, though. No it hasn’t. These are much easier to remove than to add new dependencies. We’re already seeing progress in addressing some of the ambiguities in the base certificate profiles in the CABF (via the validation WG), and while that effort is not necessarily to remove things, it does make it easier to make sure everyone is on the same page about what is permitted and good. Part of the goal is to make sure it’s clear precisely when and where flexibility exists, so we can make sure that flexibility balances all of the stakeholder needs. > 2. Make the cPSuri actually point to the relevant CPS > > > > That doesn’t really capture what a CPS is. There can be many relevant > CPSes > > to a single certificate, both for a single path and multiple paths. > That’s > > literally how audits came to be - to support the model of multiple CPSes. > > >From what I can see in a CSV o' Doom, a CA can only provide a single CPS > link for a given intermediate. That does rather suggest that there's only > one CPS for a given certificate. That’s something Kathleen is literally in the process of fixing :) > Do you disagree? If Mozilla Policy made normative that there be some form > > of binding problem reporting statement for each issuer certificate, would > > that address your problem or not? > > Not particularly, because while problem reporting addresses are the major > part of why I have gone looking for CPSes in the recent past, it is not the > only reason. Not as helpful as a reply ;) What are the other reasons, so we can better understand the challenges you’re facing, and find solutions that balance those needs better? :) _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
