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.
Dimitris.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
