Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
On Sun, Jul 12, 2020 at 4:19 PM Oscar Conesa via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > To obtain this confidence, CAs must comply with all the requirements > that are imposed on them in the form of Policies, Norms, Standards and > Audits that are decided on an OBJECTIVE basis for all CAs. The > fulfillment of all these requirements must be NECESSARY, but also > SUFFICIENT to stay in the Root Program. > As Matt Palmer points out, that's not consistent with how any root program behaves. This is not unique to Mozilla, as you find similar text at Microsoft and Google, and I'm sure you'd find similar text with Apple were they to say anything. Mozilla's process is transparent, in that it seeks to weigh public information, but it's inherently subjective: this can easily be seen by the CP/CPS reviews, which are, by necessity, a subjective evaluation of risk criteria based on documentation. You can see this in the CAs that have been accepted, and the applications that have been rejected, and the CAs that have been removed and those that have not been. Relying parties act on the information available to them, including how well the CA handles and responds to incidents. Some CAs may want to assume a leadership role in the sector and > unilaterally assume more additional strict security controls. That is > totally legitimate. But it is also legitimate for other CAs to assume a > secondary role and limit ourselves to complying with all the > requirements of the Root Program. You cannot remove a CA from a Root > Program for not meeting fully SUBJETIVE additional requirements. > CAs have been, can be, and will continue to be. I think it should be precise here: we're talking about an incident response. Were things as objective as you present, then every CA who has misissued such a certificate would be at immediate risk of total and complete distrust. We know that's not a desirable outcome, nor a likely one, so we recognize that there is, in fact, a shade of gray here for judgement. That judgement is whether or not the CA is taking the issue seriously, and acting to assume a leadership role. CAs that fail to do so are CAs that pose risk, and it may be that the risk they pose is unacceptable. Key destruction is one way to reassure relying parties that the risk is not possible. I think a CA that asked for it to be taken on faith, indefinitely, is a CA that fundamentally misunderstands the purpose and goals of a root program. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
On Sun, Jul 12, 2020 at 10:13:59PM +0200, Oscar Conesa via dev-security-policy wrote: > Some CAs may want to assume a leadership role in the sector and unilaterally > assume more additional strict security controls. That is totally legitimate. > But it is also legitimate for other CAs to assume a secondary role and limit > ourselves to complying with all the requirements of the Root Program. You > cannot remove a CA from a Root Program for not meeting fully SUBJETIVE > additional requirements. I fear that your understanding of the Mozilla Root Store Policy is at odds with the text of that document. "Mozilla MAY, at its sole discretion, decide to disable (partially or fully) or remove a certificate at any time and for any reason." I'd like to highlight the phrase "at its sole discretion", and also "for any reason". If the CA Module owner wakes up one day and, having had a dream which causes them to dislike the month of July, decides that all CAs whose root certificates have a notBefore in July must be removed, the impacted CAs do not have any official cause for complaint. I have no doubt that such an arbitrary decision would be reversed, and the consequences would not make it into production, but the decision would not be reversed because it "cannot" happen, but rather because it is contrary to the interests of Mozilla and the user community which Mozilla serves. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New Blog Post on 398-Day Certificate Lifetimes
On Sat, 11 Jul 2020 11:06:56 +1000 Matt Palmer via dev-security-policy wrote: > A histogram of the number of certificates grouped by their notBefore > date is going to show a heck of a bump on August 31, I'll wager. > Will be interesting to correlate notBefore with SCTs. I expect there will be a modest number of entities which are all three of: 1. Aware this is happening in time to obtain certificates on or before August 31 2. Sufficiently unprepared for shorter certificate lifetimes still that they desire a longer lived certificate rather than just using new one year certificates (or automation). 3. And also organised enough to execute on a plan which obtains certificates in a timely fashion. But, there's no particular attraction to August 31 itself for these subscribers, once they meet these criteria why shouldn't they take action sooner? So I'd expect this bump to be quite small and also spread over days and weeks. For the subscribers who are too late, too bad. I'm sure from September for the next year or two commercial CAs will see some level of whining from disgruntled customers whose cheese has been moved and aren't happy about it. Some of it might leak here too. I don't anticipate a WoSign-style back-dating epidemic. The benefits to the subscriber are relatively small and the risk to a CA that gets caught is more obvious than ever. Nick. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
On 12/7/20 2:21, Ryan Sleevi wrote: I want to be clear here: CAs are not trusted by default. The existence of a CA, within a Root Program, is not a blanket admission of trust in the CA. Here we have a deep disagreement: A CA within a Root Program must be considered as a trusted CA by default. Mistrust in a CA about its ability to operate safely can occur BEFORE being admitted in the Root Program or AFTER being removed of the Root Program. Relaying parties trust in the Root Program (this implies that they trust all the CAs that are part of the program without exception). To obtain this confidence, CAs must comply with all the requirements that are imposed on them in the form of Policies, Norms, Standards and Audits that are decided on an OBJECTIVE basis for all CAs. The fulfillment of all these requirements must be NECESSARY, but also SUFFICIENT to stay in the Root Program. Some CAs may want to assume a leadership role in the sector and unilaterally assume more additional strict security controls. That is totally legitimate. But it is also legitimate for other CAs to assume a secondary role and limit ourselves to complying with all the requirements of the Root Program. You cannot remove a CA from a Root Program for not meeting fully SUBJETIVE additional requirements. I want to highlight that both the "destruction of uncompromised keys" and "the prohibition to reuse uncompromised keys" are two security controls that do not appear in any requirement of the Mozilla Root Program, so CAs have no obligation to fulfill them. If someone considers these security controls as necessary, they can be requested to be included in the next version of the corresponding standard. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
