On Thu, Nov 12, 2020 at 1:39 PM Ben Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> On Thu, Nov 12, 2020 at 2:57 AM Dimitris Zacharopoulos <ji...@it.auth.gr> > wrote: > > > > > I believe this information should be the "minimum" accepted methods of > > proving that a Private Key is compromised. We should allow CAs to accept > > other methods without the need to first update their CP/CPS. Do people > > think that the currently proposed language would forbid a CA from > > accepting methods that are not explicitly documented in the CP/CPS? > > > > I also think that "parties" is a bit ambiguous, so I would suggest > > modifying that to follow the language of the BRs section 4.9.2 > > "Subscribers, Relying Parties, Application Software Suppliers, and other > > third parties". Here is my proposed change: > > > > "Section 4.9.12 of a CA's CP/CPS MUST clearly specify the methods (at a > > minimum) that Subscribers, Relying Parties, Application Software > > Suppliers, and other third parties may use to demonstrate private key > > compromise." > > > > Dimitris, > Instead, what about something like, "Section 4.9.12 of a CA's CP/CPS MUST > clearly specify its accepted methods that Subscribers, Relying Parties, > Application Software Suppliers, and other third parties may use to > demonstrate private key compromise. A CA MAY allow additional, alternative > methods that do not appear in section 4.9.12 of its CP/CPS." ? > I understand and appreciate Dimitris' concern, but I think your original language works better for Mozilla users in practice, and sadly, moves us back in a direction that the trend has been to (carefully) move away from. I would say the first goal is transparency, and I think that both proposals try to accomplish that baseline level of providing some transparency. Where I think it's different is that the concern Dimitris raised about "minimums", and the proposed language here, is that it discourages transparency. "We accept X or Y", and a secret document suggesting "We also accept Z", makes it difficult to evaluate a CA on principle. The second goal is auditability: whether or not the CP/CPS represents a binding commitment to the community. This is why they exist, and they're supposed to help relying parties not only understand how the CA operates, but how it is audited. If a CA has a secret document Foo that discloses secret method Z, is the failure to actually support secret method Z worth noting within the audit? I would argue yes, but this approach would (effectively) argue no. I think your original language was better suited for this, and is consistent with the view that the CP/CPS is both the primary document that becomes part of the auditable controls, and is the primary document for reviewing how well a CA aligns with Mozilla's practices, needs, and users. Yes, this does mean they would need to update their CP/CPS as they introduce new methods, but this seems a net-positive for everyone. Getting CAs more attuned into updating their CP/CPS, to provide adequate disclosure, seems like a net-win, even though I'm sure some CAs have designed processes and contracts that make this difficult. However, the industry of the past 10 years has shown the importance of being able to update the CP/CPS, and clearly document it, so I think we should increasingly be skeptical about statements about the challenges. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
