On Sat, Nov 14, 2020 at 6:05 PM Peter Bowen <pzbo...@gmail.com> wrote:
> On Sat, Nov 14, 2020 at 2:05 PM Ryan Sleevi via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > > > So, perhaps now that we've had this conversation, and you've learned > about > > potentially illegitimate revocations are a thing, but that they were not > > the thing I was worrying about and that you'd misunderstood, perhaps we > can > > move back to the substantive discussion? > > Going back to earlier posts, it seems like CAs could include a > statement in their CPS separate from key compromise that they may > revoke a certificate at any time for any reason or no reason at their > sole discretion. That would allow the CA to choose to accept proofs > of key compromise that are not listed in the CPS based on their > internal risk methodologies, correct? It does still have the "secret > document" issue, but moves it away from key compromise and makes it > clear and transparent to subscribers and relying parties. This means > the CA could revoke the subscriber certificate because they have an > internal procedure that they roll a bunch of D16 and revoke any > certificate with a serial number that matches the result. Or the CA > could revoke the certificate because they got a claim that the key in > the certificate is compromised but it came in a form not explicitly > called out, so they had to use their own judgement on whether to > revoke. > The reply was to me, but it sounds like your proposal was to address Dimitris' concerns, not mine. Is that correct? As I mentioned when trying to clarify my reply to Nick, the reason I think the originally proposed language works, in a way that the modified proposal does not, is that what you describe conflates the "we decide to revoke" (the D16, in your example) with the "You gave us some details and we should have revoked on that basis". That's a valuable property to have, by making sure it's unambiguous whether they're explicitly limiting the methods of key compromise, or not. The goal is, and has been, the same, to make sure that CAs are not setting an onerous burden on the community to report key compromise, while also providing guidance to the community on how the CA will reasonably take action on reports of key compromise, including those that aren't "perfect" matches to one of the methods. If I understand Dimitris' concern correctly, it was about ensuring CAs had flexibility for discretion, and your language supports that discretion. However, as you note, it still has the issue with non public documents, in the best case, or it leaves it ambiguous whether the CA is affirmatively stating they will *reject* any report of key compromise that doesn't exactly follow their methodology. I believe Ben's original language ( https://github.com/BenWilson-Mozilla/pkipolicy/commit/719b834689949e869a0bd94f7bacb8dde0ccc9e4 ) supports that, by both expecting CAs to define some set of explicit methods (which was, I believe, Nick's original concern, if I've understood), while also allowing them to state that they won't reject reports outright, by disclosing they'll accept additional methods (which is my concern). This disclosure also addresses Dimitris' concern, because it allows the CA to accept other methods as needed, but sets the expectation that the CP/CPS is the canonical place to document the methods you do accept. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
