I whole heartedly agree with Comment #13.
(In reply to Paul van Brouwershaven from comment #12)
We agree that our action was not strictly in line with point 7 of section 22.214.171.124 of the Baseline Requirements:
The reply here, "not strictly", suggests that it's believed to be partially compliant. Is that a correct understanding of the above statement?
To minimize the impact on the subscriber and relying parties we wanted to prevent revoking, requesting, and installing a new certificate with the same information, as this doesn't benefit anyone.
Thanks for sharing the perspective, although it does seem to overlook a number of substantial (and long-discussed) issues. My hope is that this is accidental, and that comments like Matthias' Comment #13 provide greater insight into why the statement "doesn't benefit anyone" is both without merit and substance.
Relying parties and root stores take upon themselves all of the risk when including particular CAs within their products. They suffer the reputational risk, and the direct security harms to their users, if and when that CA fails to abide by the agreed-upon behaviour, whether it's a failure to format certificates in the correct manner (leading to, e.g. compatibility issues, which can increase the complexity of products due to workarounds or suffer user attrition due to not accepting such invalid certificates) or without proper validation.The CA is included on the basis of both their stated policies, and an assessment of how well those policies align with user needs.
This sort of post-issuance validation completely violates that expectation, and as a consequence, directly undermines trust in the CA. As Matthias points out, allowing this sort of behaviour is to say, in effect, "You can do whatever you want, as long as you don't get caught, and if you do get caught, there are no consequences."
Revocation serves to redress some of these concerns. First, it demonstrates the CAs own awareness of their failure to abide by the agreed-upon practices, and represents their commitment that they shall not benefit from such malfeasance, whether malicious or unintentional. It also serves as an important backstop for server operators, in signalling that a particular CA may not be willing or capable of behaving as it has agreed upon. Although there is some disruption, that only exists if and when the CA has materially failed its duties.
While an argument by analogy is not the strongest, in the hopes of communicating just how serious this is, the parallel here would be saying that it's OK to rob a bank, as long as you only steal as much as is in your account, and leave a note after so that they can debit your account. As a society, we obviously reject such brazen rejection of norms, and as it applies to a CA community, the sort of failure to abide by the expected behaviour is equally serious.
I suggest we discuss this type of rectification with the Server Certificate Working Group in the new year, as I don't think it's the intention of the Baseline Requirements to disturb the WebPKI unnecessarily.
I do think this is concerning. Whether or not it was intentional, this would have the direct effect of excluding participation of the broader community. I encourage Entrust to look at the behavior of other CAs when faced with such challenges, which include involving relying parties as stakeholders, by engaging with the Mozilla forum.
I think that, should Entrust look to discuss this in the CA/B Forum first, given the existence of this issue, this should be viewed very negatively with respect to how well Entrust values community feedback and how seriously they take compliance. My hope is that this suggestion just didn't consider this possibility, and that by making it very explicit, a different course of action can be considered.
I remain deeply concerned that, in light of repeated comments from multiple members (Comment #4, Comment #9, Comment #11) pointing out that this is a naked violation of the Baseline Requirements, and Entrust's own acknowledgement that they have violated the Baseline Requirements (Comment #12), Entrust has still not revoked these certificates.
- Will you be revoking these certificates, now that you've realized the behaviour taken is completely out of line with the Baseline Requirements?
- If so, when will you be revoking?
- When can we expect a separate incident report for the failure to revoke?