On Fri, Jun 1, 2018 at 2:38 PM, Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> This is one of the reasons I think we should require an OID specifying the > validation method be included in the cert. Then you can require the CA > support revocation using the same validation process as was used to confirm > certificate authorization. With each cert logged in CT, everyone in the > world will know exactly how to revoke an unauthorized or no-longer-wanted > cert. > > I agree that it would be forensically interesting to have that data available in the certificate. I question whether a policy of using only the same method of demonstrating control anew is appropriate as a policy for granting revocation. There is a hierarchy of supremacy in domain validation. The party controlling the NS delegations from the registry has absolute precedence over the present effective DNS server administrator, should they choose to flex it. The party immediately in effective control of the authoritative DNS takes precedence over a website admin within the domain. Consider that now current CAA records and policy (for good cause, even) might presently prohibit successful validation via the method previously utilized to acquire the certificate that the current domain holder wishes to have revoked. (Even if only by specifying a new CA, rather than the CA that previously issued the certificate for which revocation is being sought.) Would you then advocate that if the validation can succeed -- save for the CAA mismatch -- that this be regarded as sufficient evidence to revoke? That probably deserves some careful thought. In any event, proof of ability to modify the authoritative DNS over each label in the certificate should almost certainly suffice to revoke a previously issued certificate that relied exclusively upon just about any other sort of domain validation. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
