On Sun, Nov 15, 2020 at 6:02 AM Dimitris Zacharopoulos <ji...@it.auth.gr> wrote:
> > > On 2020-11-15 1:04 π.μ., Peter Bowen via dev-security-policy 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. > > > > Thanks, > > Peter > > Thanks for chiming-in Peter, > > I have always considered this revocation reason as the absolutely "last > resort" for CAs when it comes to revocation of Certificates. Especially > for the revocation of end-entity Certificates for which there is a > Subscriber Agreement attached, if the CA cannot properly justify the > revocation based on other documented reasons that Subscribers can > understand and be prepared for, it seems like a process failure and a > possible reason for Subscribers to move against the CA. Much like the > invocation of 9.16.3 should be avoided as much as possible, I believe > the same applies for relying on such very wide unbound CPS statements. > Isn't this the "different problem" that Nick was raising concerns about? That is, your reply here, talking about revocation for reasons outside of the Subscriber Agreement, sounds even further afield than Issue 205. Am I missing something on how it connects here? _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
