On 15/11/2020 9:44 μ.μ., Ryan Sleevi wrote:
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?
If a CA already has a statement in its CP/CPS that the CA can revoke a
certificate at any time and with no justification, this is probably
already included in the Subscriber Agreement. I just wanted to highlight
that this is a very weak revocation reason that CAs should avoid as much
as possible. In any case, the fact that a CA can revoke for any reason
is not related to the #205 issue which is to document how a third-party
can prove that a key is compromised. The revocation reasons related to
key compromise can fully cover the justification for why a certificate
must be revoked.
We're trying to ensure that the Mozilla Policy language doesn't create a
situation where a CA is being presented with evidence that a key is
compromised, and this evidence is not inline with the documented
procedure of the CA's 4.9.12 (at that time), thus the proposal to add
broader language so a CA can accept other methods of demonstrating a key
compromise.
I think Nick supports the updated language from Ben, and I also support
Nick's updated version presented in
https://groups.google.com/g/mozilla.dev.security.policy/c/QQmhYW6kxSw/m/CKaRcl27AgAJ.
Just a reminder, I'm also happy with the original language (that you
support) in the MRSP, as long as it is clearly allowed for CAs to ADD
the broader language in 4.9.12 of their CPS to avoid "audit
misunderstandings" :)
Dimitris.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
