On Mon, Jan 15, 2018 at 3:36 PM, Doug Beattie via dev-security-policy < [email protected]> wrote:
> Ryan, > > I’m not sure where we go from here. As suggested, we encourage you to work on devising technical mitigations or alternative methods of validating such certificates that can meet the use case. We don't think that, as described, the OneClick method meets the necessary level of assurance, nor do the necessary level of mitigating factors exist, to consider such certificates trustworthy. > We have customers that need certificates and they have demonstrated they > can comply with not permitting the creation and use of certificates for > domains other than those that the hosting company is hosting for that > customer. All certificates will continue to be posted to CT logs. > While understanding and sensitive to this, what you're asking is that, on the basis of an abstract need, that known-insecure methods be used, with the assurance that the CA has taken steps (which are fundamentally non-interoperable) to mitigate, and for which an improper decision by a CA has no further mitigating factors. This does not provide a sufficient level of assurance to permit its continued use. > As far as the wildcard question, when someone asks for a wildcard cert for > a domain like *.us.example.com, we validate on that minus the * (so, > us.example.com in this case). > I'm afraid you're still missing the point of FQDN versus Authorization Domain Name. This further does not instill confidence that it's fully been described. > We’d like to move forward with issuing certificates with controls in > place. I'm sorry, but at present, we do not feel it is in the appropriate interests of users, sites, or the ecosystem to permit this. > If there are any other controls you need us to implement to resume > issuance, let us know. For example, if we limit validity to 1 year > (possibly up to 15 months) and if we put a firm end date for OneClick for > July 1, 2018, would that suffice? > As stated, we believe 90 days is an appropriate and necessary upper-bound for such certificates. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
