Re: Extending Android Device Compatibility for Let's Encrypt Certificates
I'm curious whether this approach of cross-signing from a root certificate which has already expired is exceptional for Let's Encrypt. I'm not aware of any discussion on what conditions this approach could be accepted by Mozilla and other root certificate programs. Or, is it just an usual practice of CA? If yes, this approach may provide some new solutions in the CA ecosystem. Firstly, for those new CAs who do not have their root certificates included in the root certificate programs, they may acquire an expired root certificate from an existing CA who are probably more willing to sell the expired root certificate rather than an active root certificate. Secondly, for some CAs whose root certificates are going to expire, they may continue using the root certificates to issue intermediate CA certificates beyond its expiry. So, there will be no need for rollover of root certificates to new one. Are they good or bad things? On 22-Dec-20 7:42 AM, jo...--- via dev-security-policy wrote: We (Let's Encrypt) just announced a new cross-sign from IdenTrust which is a bit unusual because it will extend beyond the expiration of the issuing root. More details can be found here: https://letsencrypt.org/2020/12/21/extending-android-compatibility.html Best, Josh ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Summary of Camerfirma's Compliance Issues
On Tue, Jan 5, 2021 at 9:01 AM Ramiro Muñoz via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > In response to Ryan’s latest post, we want to provide the community with > Camerfirma’s due responses and we hope this clears up any doubts that might > have arisen. > > Ryan argument number 1: “These statements are ones that are sort of "true > by degree". That is, if I was to dispute 1, Camerfirma would/could > rightfully point out that they were *much* worse before, and so yes, it's > true that they've improved.” > 1. Camerfirma has made huge improvements. > > Camerfirma has improved its operations to avoid errors. We have procedures > in place to incentivate improvement in every level in our operations. We > shall continue to work in this way in the future. > We have worked to automate internal processes, also improving the > management and level of attention on each incident. We have involved more > experts in the process. Our goal has always been to meet the highest > demands, including monitoring of CA activities that Mozilla has been > implementing over the past years. > In addition, Camerfirma publishes SSL certificates in the CT, EV since > (May 2016) and OV since (April 2017) ( even if it was mandatory only from > April 30, 2018). We have always been in favour of increasing transparency > and providing useful information to the community. > We have implemented several improvements during 2019 and 2020 (as we have > already mentioned in previous reports): > > • Decreased response time and increased attention to incidents. As a > result, we have eliminated communications failures and we have avoided > response delays (2020). > • Use of a centralized lint. Our three unconstrained subCA > (Multicert, Infocert and Intesa Sao Paolo) with codification errors in > issued certificates were added to our centralized lint. The first one since > March 2019 and the other two since April 2019. > • Contractual cover of unilateral revocations with the subCAs has > been clarified and streamlined. (October 2019). > • Mass revocation processes have been implemented (June 2020). > • Verification of CAA has been revised and reinforced with automatic > procedures (June 2020). > • Control zlint has been implemented, both at pre-issuance and > post-issuance (January 2019). > • Syntax control of the domain (August 2020) > • Additional automatic control to verify the correctness of AKI > extension before certificate issuance has been implemented (April 2020). > > In addition, Camerfirma periodically evaluates the efficacy of these > measures and every other improvement implemented. > I understand why Camerfirma feels it important to exhaustively list these things, but I think the Wiki page, and its details, provides a much more honest look at these. The adoption of Certificate Transparency before it was mandatory, for example, does not highlight Camerfirma's leadership in the area: it reveals how many issues Camerfirma's own management was letting through its quality control processes, even though tools readily existed to prevent this. The centralized lints for sub-CAs, for example, were not imposed proactively to prevent incidents, but reactively in response to a failure to supervise sub-CAs. Each of these improvements you list, while there are some improvements, have been reactive in nature, after Camerfirma has been shown to repeatedly fail to meet the basic expectations of CAs, fail to detect this, and have the community highlight it. Perhaps no greater example of this can be found than "Syntax control of the domain", implemented in August 2020, despite issues having been raised in 2017 highlighting the importance of this requirement. [1] What Camerfirma has done here has list the controls they've implemented in response to their specific incidents, which, while important, overlooks that many of these were basic expectations that would have prevented incidents. This is akin to a student asking for full credit for a paper they turned in a semester late, on the principle that they at least turned it in, even after their (failing) grade had already been received. [1] https://groups.google.com/g/mozilla.dev.security.policy/c/D0poUHqiYMw/m/Pf5p0kB7CAAJ > > Ryan argument number 2: “Similarly, to point out at how laughably bad the > old system was does show that there is a degree of truth in 2” > 2. Camerfirma nowadays has a much more mature management system. > > Subjective opinions aside, the community bug reports from the last 4 years > show the improvement and efficacy of controls in Camerfirma's systems and > procedures: > > CAMERFIRMA InfoCertMULTICERT > DIGITALSIGN CGCOM TOTAL > BUGS 20201 3 2 > 0 1 7 > BUGS 20195 1 1 > 0
Re: Summary of Camerfirma's Compliance Issues
In response to Ryan’s latest post, we want to provide the community with Camerfirma’s due responses and we hope this clears up any doubts that might have arisen. Ryan argument number 1: “These statements are ones that are sort of "true by degree". That is, if I was to dispute 1, Camerfirma would/could rightfully point out that they were *much* worse before, and so yes, it's true that they've improved.” 1. Camerfirma has made huge improvements. Camerfirma has improved its operations to avoid errors. We have procedures in place to incentivate improvement in every level in our operations. We shall continue to work in this way in the future. We have worked to automate internal processes, also improving the management and level of attention on each incident. We have involved more experts in the process. Our goal has always been to meet the highest demands, including monitoring of CA activities that Mozilla has been implementing over the past years. In addition, Camerfirma publishes SSL certificates in the CT, EV since (May 2016) and OV since (April 2017) ( even if it was mandatory only from April 30, 2018). We have always been in favour of increasing transparency and providing useful information to the community. We have implemented several improvements during 2019 and 2020 (as we have already mentioned in previous reports): • Decreased response time and increased attention to incidents. As a result, we have eliminated communications failures and we have avoided response delays (2020). • Use of a centralized lint. Our three unconstrained subCA (Multicert, Infocert and Intesa Sao Paolo) with codification errors in issued certificates were added to our centralized lint. The first one since March 2019 and the other two since April 2019. • Contractual cover of unilateral revocations with the subCAs has been clarified and streamlined. (October 2019). • Mass revocation processes have been implemented (June 2020). • Verification of CAA has been revised and reinforced with automatic procedures (June 2020). • Control zlint has been implemented, both at pre-issuance and post-issuance (January 2019). • Syntax control of the domain (August 2020) • Additional automatic control to verify the correctness of AKI extension before certificate issuance has been implemented (April 2020). In addition, Camerfirma periodically evaluates the efficacy of these measures and every other improvement implemented. Ryan argument number 2: “Similarly, to point out at how laughably bad the old system was does show that there is a degree of truth in 2” 2. Camerfirma nowadays has a much more mature management system. Subjective opinions aside, the community bug reports from the last 4 years show the improvement and efficacy of controls in Camerfirma's systems and procedures: CAMERFIRMA InfoCertMULTICERT DIGITALSIGN CGCOM TOTAL BUGS 20201 3 2 0 1 7 BUGS 20195 1 1 0 0 7 BUGS 20184 1 2 1 0 8 BUGS 20175 1 0 0 0 6 TOTAL 15 6 5 1 1 28 Regarding the nature of the errors, the bug associated with Camerfirma’ s systems in the last year (2020) was: • #1623384 AKI issue encountered due to the incomplete templates in the certificate model. The modification of the profile correction procedure and establishment of an additional automatic control to verify the AKI before the issue of certificates was implemented in a timely manner. If we consider also bugs concerning the external SubCAs, the total number of bugs registered in 2020 is in line with the previous years. In order to extend to subCAs the same rate of improvement registered by Camerfirma we’ve proposed to obtain the contractual right and the operational procedures in place to insource the management of all the operational activities of subCAs. Ryan argument number 3: “…and, as I laid out in my own post, Camerfirma *is* not very different from other CAs - CAs that have been distrusted, for not very different reasons than Camerfirma. I'm sure Camerfirma meant to mean "not much different than other *currently trusted* CAs", but that's equally a degree of truth - many individual incidents affected other CAs, even though the sheer volume *and nature* of Camerfirma bugs is troubling. 3. Camerfirma is not very different from other (trusted) CAs. Obviously, when we state
