On Friday, March 23, 2018 at 4:20:51 PM UTC+1, Ryan Sleevi wrote: > On Fri, Mar 23, 2018 at 1:12 PM ramirommunoz--- via dev-security-policy < > [email protected]> wrote: > > > On Thursday, March 22, 2018 at 10:43:49 PM UTC+1, Ryan Sleevi wrote: > > > On Thu, Mar 22, 2018 at 6:26 PM ramirommunoz--- via dev-security-policy < > > > [email protected]> wrote: > > > > > > > Hi Ryan > > > > Many thanks for your report. I will try to answer to your concerns > > about > > > > our root inclusión. > > > > > > > > > In attempt to discuss continued trust, I have attempted to summarize > > the > > > > > patterns and issues of note, along with the timeline from reporting > > to > > > > > remediation. It is my goal that this will allow the public to make an > > > > > objective assessment of the risks introduced by Camerfirma, as well > > as > > > > the > > > > > responsiveness towards remediation. While the ecosystem continues to > > > > > improve both its understanding of the requirements and expectations, > > we > > > > > must nevertheless consider the full picture. > > > > > > > > > > Issue 1: Invalid dNSNames/CNs ( > > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 ) > > > > > 2014-09-25 - https://crt.sh/?id=5129200&opt=cablint issued > > > > > 2017-08-12 - Jonathan Rudenberg posts to m.d.s.p > > > > > 2017-08-13 - Jonathan Rudenberg contacts the CA > > > > > 2017-08-16 - Kathleen Wilson opens a Bugzilla incident > > > > > 2017-08-17 - Camerfirma Responds > > > > > 2017-09 - Scheduled remediation > > > > > 2017-12 - First attempted remediation > > > > > 2018-02-14 - Actual remediation, as per > > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c33 > > > > > > > > > > Issue 2: Unrevoked Internal Servernames ( > > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 ) > > > > > 2016-10-01 - Deadline for revoking internal server name certificates > > > > > 2017-08-24 - Camerfirma shares list of misissued certificates > > affected by > > > > > Issue 1, along with their response > > > > > 2017-08-24 - Ryan Sleevi highlights that Camerfirma failed to > > identify > > > > and > > > > > revoke internal server name certificates - > > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c13 > > > > > 2017-09-12 - Camerfirma revokes https://crt.sh/?id=8680123&opt=ocsp > > > > > 2017-11-28 - Gerv Markham highlights that Camerfirma has still not > > > > > responded to outstanding questions - > > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c21 > > > > > 2017-12-21 - Camerfirma responds to the substance of the questions > > > > > > > > > > Issue 3 - Improperly Configured OCSP - > > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1426233 > > > > > 2017-12-12 - Rob Stradling reports on CA's improperly configured OCSP > > > > > configurations at > > > > > > > > > > > https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/C2vTpvouP3g > > > > > 2017-12-19 - Wayne Thayer opens a bug regarding OCSP non-conformance > > by > > > > > Camerfirma > > > > > 2017-12-22 - Camerfirma confirms the issue is resolved. It took one > > of > > > > > their sub-CAs from 12-12 to 12-19, and another from 12-12 to 12-22, > > to > > > > > implement these changes. Camerfirma did not self-report this > > > > > non-compliance, despite acknowledging it on 12-12. > > > > > 2018-01-03 - Camerfirma completes a minimal incident report with all > > > > > required information. > > > > > > > > > > Issue 4 - Improper CAA checking ( > > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1420871 ) > > > > > 2017-09-08 - Baseline Requirements require checking CAA > > > > > 2017-11-27 - Quirin Scheitle reports CAA checking non-compliance by > > > > > Camerfirma > > > > > 2017-11-29 - Camerfirma confirms misissuance, believing it was valid > > > > > because they found "and for which CAA was checked" to be confusing > > and > > > > > indicating that CAA checking was optional. > > > > > 2017-11-29 - Camerfirma claims CAA checking is activated on all RAs > > > > > > > > > > > > > All previous bugs as you said are closed successfully. > > > > > > > > > > > > > > Issue 5 - Duplicate dNSNames and invalid > > > > localityName/stateOrProvinceName ( > > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1357067 ) > > > > > 2017-04-17 - Issue reported > > > > > 2017-04-20 - Camerfirma reports the issue is fixed to StartCom. The > > issue > > > > > is apparently a Camerfirma issue, and with improper logging as well > > as > > > > > certificate configuration. > > > > > 2017-10-13 - StartCom provides incident report, as a Camerfirma > > reseller > > > > > Note: No response was provided by Camerfirma in this incident report. > > > > > > > > > We were not aware that an answer from us was needed. The incident > > report > > > > provided by StartCom was coordinated with us. > > > > > > > > > > Issue 6 - Out of date CP/CPSes > > > > > 2016-06 - Last published version of the CPS at > > > > > > > > > > > http://docs.camerfirma.com/publico/DocumentosWeb/politicas/CPS_V_3_2_7_EN.pdf > > > > > 2018-05 - Next proposed update of the CPS, as stated elsewhere on > > this > > > > > thread > > > > > > > > > We already have a new CPS version, next week we will publish it, and a > > new > > > > version when it was RFC 3647 compliant. > > > > > > > > > > > > > > I'm not sure whether to track issues with the new hierarchy, so I > > will > > > > > simply note the following: > > > > > 2017-08-23 - Last issued certificate with invalid dNSName ( > > > > > > > > > > > https://crt.sh/?caid=50473&opt=cablint,zlint,x509lint&minNotBefore=2011-01-01 > > > > > ) > > > > > 2017-12-13 - Last issued certificate that violates RFC 5280, > > 4.1.2.4's > > > > > requirements that "CAs conforming to this profile MUST use either the > > > > > PrintableString or UTF8String encoding of DirectoryString, with two > > > > > exceptions" ( > > > > https://crt.sh/?cablint=261&iCAID=50473&minNotBefore=2011-01-01 ) > > > > > > > > > there is an open bug > > https://bugzilla.mozilla.org/show_bug.cgi?id=1443857 > > > > where previous bug are treated. > > > > > > > > > > > > > > Notable is that Camerfirma includes the organizationIdentifier, > > > > > OID 2.5.4.97, in their certificates. This is documented in the CPS > > [5] > > > > from > > > > > the original message, within Section 3.1.1, with the validation > > process > > > > > described in 3.1.8.1. However, the CP/CPS lacks details as to the > > > > > construction and validation - it appears to be a construction of > > "VAT" > > > > > [member state] "-" [VAT number] > > > > > > > > > website certificates profile is defined in ETSI EN 319 412-4. This > > > > standard refers ETSI EN 319 412-1 where this OID is defined. VAT is as > > > > defined in CPS section 3.1.8.2.3 > > > > > > > > > > > > > > In this, we see a pattern of issues, with a strong reliance on > > trusting > > > > RAs > > > > > (which included entities such as StartCom, known to not be validating > > > > > correctly) and, when failure detected, on technical controls. We see > > a > > > > > pattern of delayed remediation, misunderstanding of expectations in > > the > > > > > face of misissuance, and misunderstandings of the requirements > > > > themselves. > > > > > If there is any one remark that perfectly captures this, it would be > > > > found > > > > > in https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c30 , > > provided > > > > on > > > > > 2017-12-21 (i.e. after many of these issues) > > > > > > > > > We rely on our RA network and we train them and audit them for assure a > > > > correct validation. As a result of > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c30 technical > > > > controls were deployed to avoid misissuance, misunderstandings and > > reduce > > > > this dependency on trusting RAs. > > > > > > > > > > > > > > "AC Camerfirma is a small CA that uses an in-house developed CA > > software > > > > > and is supported by our RA trusted operators and the continuous > > training > > > > > they receive. AC Camerfirma has been working with this technology and > > > > staff > > > > > for 17 years without problems and we have dedicated a big effort > > > > improving > > > > > it along those years. Due to the number of TLS certificates issued on > > > > > previous years, this working method was appropriate and suitable for > > us. > > > > > The increase of certificates issued, increasing technical > > requirements > > > > and > > > > > the analysis of these reported problems have helped us to realize the > > > > need > > > > > to extend the technical controls in the CA application to cover all > > > > > possible and new requirements and introduce a new person in charge of > > > > > coordinating these implementations." > > > > > > > > > > I think it's problematic to suggest "without problems", and > > concerning > > > > that > > > > > it required a "big effort" to improving. It equally remains > > > > > problematic/concerning that the in-house CA software has continued to > > > > show > > > > > issues. > > > > > > > > > When we said “without problems” means that our practices and tools (PKI > > > > platform included) has passed many audit successfully. Sure, we have to > > > > improve (this very process, and every control, audits, certifications > > helps > > > > us to improve it). Just to let the community know, this is the list of > > AC > > > > Camerfirma SA last audit process: > > > > ETSI 319 401 Audited by TÜV-IT (2017-2019) > > > > > > https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/9725UE_s.pdf > > > > ETSI 319 401 Audited by CSQA (2017-2019) > > > > > > http://docs.camerfirma.com/publico/DocumentosWeb/certificaciones/certificatocamerfirma2017.pdf > > > > ETSI 319 411-1 Audited by TÜV-IT (2017-2019) > > > > > > https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/9725UE_s.pdf > > > > ETSI 319 411-1 Audited by CSQA (2017-2019) > > > > > > http://docs.camerfirma.com/publico/DocumentosWeb/certificaciones/certificatocamerfirma2017.pdf > > > > ETSI 319 411-2 Audited by TÜV-IT (2017-2019) > > > > > > https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/9725UE_s.pdf > > > > ETSI 319 411-2 Audited by CSQA (2017-2019) > > > > > > http://docs.camerfirma.com/publico/DocumentosWeb/certificaciones/certificatocamerfirma2017.pdf > > > > ETSI 319 421 Audited by CSQA (2017-2019) > > > > > > http://docs.camerfirma.com/publico/DocumentosWeb/certificaciones/certificatocamerfirma2017.pdf > > > > WEBTRUST FOR CA Audited by AUREN (2017) > > > > https://cert.webtrust.org/SealFile?seal=2283&file=pdf > > > > WEBTRUST BR Audited by AUREN (2017-2018) > > > > https://cert.webtrust.org/SealFile?seal=2284&file=pdf > > > > WEBTRUST EV Audited by AUREN (2017-2018) > > > > https://cert.webtrust.org/SealFile?seal=2285&file=pdf > > > > ISO 27001 Audited by AENOR (2016-2019) > > > > > > http://docs.camerfirma.com/publico/DocumentosWeb/certificaciones/ISO_27001_AENOR.pdf > > > > ISO 20000 Audited by AENOR (2016-2019) > > > > > > http://docs.camerfirma.com/publico/DocumentosWeb/certificaciones/ISO_20000_AENOR.pdf > > > > . > > > > > > > > In spite of the issues arisen, hope that at least this could count on > > our > > > > favor when a decision about our root inclusion were taken. > > > > > > > > > Camerfirma states that it believes those issues remediated, in part, > > by > > > > > extending technical controls. Yet many of these failures also > > highlight > > > > > problems in the design of the system (and its reliance on RAs) and > > the > > > > > staff tasked with understanding and implementing compliance. > > > > > > > > > > In the midst of all of this overhaul at Camerfirma, the 2016 root was > > > > > created. The existing roots still show problems (such as their CP/CPS > > > > > issues), and it seems energy has been focused on the new root, > > despite it > > > > > operating for a considerable time on the legacy infrastructure and > > > > subject > > > > > to issues as recently as 3 months ago. > > > > > > > > > > If, despite the evidence, we are to believe that Camerfirma has > > > > remediated > > > > > the technical issues (via the technical controls deployed in February > > > > 2018) > > > > > and has remediated the policy issues (via the onboarding of new staff > > > > > tasked with ensuring compliance in December 2017), then it seems > > > > minimally > > > > > appropriate to suggest that a new, Camerfirma 2018 root be created > > and > > > > > established. Camerfirma's 2016 root can be used to cross-certify > > this, > > > > thus > > > > > supporting those users on Microsoft platforms for which 2016 is > > trusted, > > > > > while providing greater assurance that the issuance and trust is > > > > > appropriate. Such an inclusion should not occur until a key > > generation > > > > > ceremony report, a point in time audit, and a period of time audit > > report > > > > > have been provided for the new 2018 root, which would mean would not > > be > > > > > reconsidered for at least 3 months, at a minimum. This would also > > ensure > > > > > that Camerfirma has completed its remediation steps for its existing > > set > > > > of > > > > > hierarchy, such as updating the CP/CPS, demonstrating that the new > > > > controls > > > > > and personnel are equipped to maintain a globally trusted CA. > > > > > > > > > > Further, given Camerfirma's statements that their investment in > > > > compliance > > > > > is with regards to the 2016 root, and the issue the prior roots have > > had > > > > > (both from policy compliance and issuance), it seems that we should > > also > > > > > begin discussing at what point trust in those legacy roots should be > > > > > removed, up to and including disallowing new certificates from it if > > > > > existing certificates are to remain trusted, as new issuance will be > > > > > on/from the 2018 root (through the 2016 path, for Windows users) > > > > > > > > Creating a new root 2018 is unfeasible for us for the following > > reasons: > > > > •Root 2016 is already audited and incorporated into the European TSL > > based > > > > on the favorable evaluation of our national supervisor body for both > > the > > > > issuance of S/MIME, WEB and TSU certificates. > > > > •Root is already recognized by other comunities such as Microsoft and > > > > Adobe. > > > > •Root 2016 is already accredited in the Spanish public administration & > > > > Public Services. > > > > •And above all, because the problems found so far have not > > incorporated a > > > > significant risk to the user community and they have been solved by > > > > incorporating technical controls and specific resources that currently > > > > allow us to commit with the ecosystem requirements. > > > > > > > > > The path I provided ensures every one of those things continues to work. > > > > > > Can you please elaborate more as to why it is unfeasible? > > > > > > > > > > > Hi Ryan > > > > Sure, this could work for browsers validation, but our concern is about > > Web Certificates for Spanish Public administration. > > Spanish Public Administration is AC Camerfirma main customer. > > Additionally, Roots should be accepted by public administration validation > > services. > > > And cross-signing covers this. > > > > > > So, if we provide a new root 2018, first of all, we should pass a new > > eIDAS conformity assessment for the new roots and then send it to > > administration validation services to be accepted by each particular public > > service. > > > This is not correct. Cross-signing the 2018 Root with the 2016 root allows > all services that support your 2016 root to continue to work without > disruption. From the point of view of clients, you’ve just added another > intermediate certificate. > > > > We have been working for month to be our root 2016 recognized by Spanish > > public services. We hope this could be improved in a future but nowadays is > > so complicated. > > > Yes, but the cross-signing of the 2018 root with the 2016 root will ensure > all the work you have done for 2016 is applied. > > > > > > We have been waiting for Mozilla 2016 root inclusion for many years, and > > we have to going back to the starting point ? > > Root 2016 are not having problems, we have issue only a few SSL > > certificates. It has nothing to do with StartCom, Have technical controls > > to avoid related problems found with RA validation and other, have no CPS > > problems.... I don't know how creating a new root 2018 can improve our > > trust for the community, in contrast, it will produce an economic damage > > and time consuming tasks for Camerfirma. > > > > I’m afraid this statement is not correct, and it’s based on an unfortunate > understanding about what is being proposed - and how PKI works. > > None of what you’ve described is required by what I have proposed here. > > > > Regards > > Ramiro > > _______________________________________________ > > dev-security-policy mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-security-policy > >
On Friday, March 23, 2018 at 4:20:51 PM UTC+1, Ryan Sleevi wrote: > On Fri, Mar 23, 2018 at 1:12 PM ramirommunoz--- via dev-security-policy < > [email protected]> wrote: > > > On Thursday, March 22, 2018 at 10:43:49 PM UTC+1, Ryan Sleevi wrote: > > > On Thu, Mar 22, 2018 at 6:26 PM ramirommunoz--- via dev-security-policy < > > > [email protected]> wrote: > > > > > > > Hi Ryan > > > > Many thanks for your report. I will try to answer to your concerns > > about > > > > our root inclusión. > > > > > > > > > In attempt to discuss continued trust, I have attempted to summarize > > the > > > > > patterns and issues of note, along with the timeline from reporting > > to > > > > > remediation. It is my goal that this will allow the public to make an > > > > > objective assessment of the risks introduced by Camerfirma, as well > > as > > > > the > > > > > responsiveness towards remediation. While the ecosystem continues to > > > > > improve both its understanding of the requirements and expectations, > > we > > > > > must nevertheless consider the full picture. > > > > > > > > > > Issue 1: Invalid dNSNames/CNs ( > > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 ) > > > > > 2014-09-25 - https://crt.sh/?id=5129200&opt=cablint issued > > > > > 2017-08-12 - Jonathan Rudenberg posts to m.d.s.p > > > > > 2017-08-13 - Jonathan Rudenberg contacts the CA > > > > > 2017-08-16 - Kathleen Wilson opens a Bugzilla incident > > > > > 2017-08-17 - Camerfirma Responds > > > > > 2017-09 - Scheduled remediation > > > > > 2017-12 - First attempted remediation > > > > > 2018-02-14 - Actual remediation, as per > > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c33 > > > > > > > > > > Issue 2: Unrevoked Internal Servernames ( > > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 ) > > > > > 2016-10-01 - Deadline for revoking internal server name certificates > > > > > 2017-08-24 - Camerfirma shares list of misissued certificates > > affected by > > > > > Issue 1, along with their response > > > > > 2017-08-24 - Ryan Sleevi highlights that Camerfirma failed to > > identify > > > > and > > > > > revoke internal server name certificates - > > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c13 > > > > > 2017-09-12 - Camerfirma revokes https://crt.sh/?id=8680123&opt=ocsp > > > > > 2017-11-28 - Gerv Markham highlights that Camerfirma has still not > > > > > responded to outstanding questions - > > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c21 > > > > > 2017-12-21 - Camerfirma responds to the substance of the questions > > > > > > > > > > Issue 3 - Improperly Configured OCSP - > > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1426233 > > > > > 2017-12-12 - Rob Stradling reports on CA's improperly configured OCSP > > > > > configurations at > > > > > > > > > > > https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/C2vTpvouP3g > > > > > 2017-12-19 - Wayne Thayer opens a bug regarding OCSP non-conformance > > by > > > > > Camerfirma > > > > > 2017-12-22 - Camerfirma confirms the issue is resolved. It took one > > of > > > > > their sub-CAs from 12-12 to 12-19, and another from 12-12 to 12-22, > > to > > > > > implement these changes. Camerfirma did not self-report this > > > > > non-compliance, despite acknowledging it on 12-12. > > > > > 2018-01-03 - Camerfirma completes a minimal incident report with all > > > > > required information. > > > > > > > > > > Issue 4 - Improper CAA checking ( > > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1420871 ) > > > > > 2017-09-08 - Baseline Requirements require checking CAA > > > > > 2017-11-27 - Quirin Scheitle reports CAA checking non-compliance by > > > > > Camerfirma > > > > > 2017-11-29 - Camerfirma confirms misissuance, believing it was valid > > > > > because they found "and for which CAA was checked" to be confusing > > and > > > > > indicating that CAA checking was optional. > > > > > 2017-11-29 - Camerfirma claims CAA checking is activated on all RAs > > > > > > > > > > > > > All previous bugs as you said are closed successfully. > > > > > > > > > > > > > > Issue 5 - Duplicate dNSNames and invalid > > > > localityName/stateOrProvinceName ( > > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1357067 ) > > > > > 2017-04-17 - Issue reported > > > > > 2017-04-20 - Camerfirma reports the issue is fixed to StartCom. The > > issue > > > > > is apparently a Camerfirma issue, and with improper logging as well > > as > > > > > certificate configuration. > > > > > 2017-10-13 - StartCom provides incident report, as a Camerfirma > > reseller > > > > > Note: No response was provided by Camerfirma in this incident report. > > > > > > > > > We were not aware that an answer from us was needed. The incident > > report > > > > provided by StartCom was coordinated with us. > > > > > > > > > > Issue 6 - Out of date CP/CPSes > > > > > 2016-06 - Last published version of the CPS at > > > > > > > > > > > http://docs.camerfirma.com/publico/DocumentosWeb/politicas/CPS_V_3_2_7_EN.pdf > > > > > 2018-05 - Next proposed update of the CPS, as stated elsewhere on > > this > > > > > thread > > > > > > > > > We already have a new CPS version, next week we will publish it, and a > > new > > > > version when it was RFC 3647 compliant. > > > > > > > > > > > > > > I'm not sure whether to track issues with the new hierarchy, so I > > will > > > > > simply note the following: > > > > > 2017-08-23 - Last issued certificate with invalid dNSName ( > > > > > > > > > > > https://crt.sh/?caid=50473&opt=cablint,zlint,x509lint&minNotBefore=2011-01-01 > > > > > ) > > > > > 2017-12-13 - Last issued certificate that violates RFC 5280, > > 4.1.2.4's > > > > > requirements that "CAs conforming to this profile MUST use either the > > > > > PrintableString or UTF8String encoding of DirectoryString, with two > > > > > exceptions" ( > > > > https://crt.sh/?cablint=261&iCAID=50473&minNotBefore=2011-01-01 ) > > > > > > > > > there is an open bug > > https://bugzilla.mozilla.org/show_bug.cgi?id=1443857 > > > > where previous bug are treated. > > > > > > > > > > > > > > Notable is that Camerfirma includes the organizationIdentifier, > > > > > OID 2.5.4.97, in their certificates. This is documented in the CPS > > [5] > > > > from > > > > > the original message, within Section 3.1.1, with the validation > > process > > > > > described in 3.1.8.1. However, the CP/CPS lacks details as to the > > > > > construction and validation - it appears to be a construction of > > "VAT" > > > > > [member state] "-" [VAT number] > > > > > > > > > website certificates profile is defined in ETSI EN 319 412-4. This > > > > standard refers ETSI EN 319 412-1 where this OID is defined. VAT is as > > > > defined in CPS section 3.1.8.2.3 > > > > > > > > > > > > > > In this, we see a pattern of issues, with a strong reliance on > > trusting > > > > RAs > > > > > (which included entities such as StartCom, known to not be validating > > > > > correctly) and, when failure detected, on technical controls. We see > > a > > > > > pattern of delayed remediation, misunderstanding of expectations in > > the > > > > > face of misissuance, and misunderstandings of the requirements > > > > themselves. > > > > > If there is any one remark that perfectly captures this, it would be > > > > found > > > > > in https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c30 , > > provided > > > > on > > > > > 2017-12-21 (i.e. after many of these issues) > > > > > > > > > We rely on our RA network and we train them and audit them for assure a > > > > correct validation. As a result of > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c30 technical > > > > controls were deployed to avoid misissuance, misunderstandings and > > reduce > > > > this dependency on trusting RAs. > > > > > > > > > > > > > > "AC Camerfirma is a small CA that uses an in-house developed CA > > software > > > > > and is supported by our RA trusted operators and the continuous > > training > > > > > they receive. AC Camerfirma has been working with this technology and > > > > staff > > > > > for 17 years without problems and we have dedicated a big effort > > > > improving > > > > > it along those years. Due to the number of TLS certificates issued on > > > > > previous years, this working method was appropriate and suitable for > > us. > > > > > The increase of certificates issued, increasing technical > > requirements > > > > and > > > > > the analysis of these reported problems have helped us to realize the > > > > need > > > > > to extend the technical controls in the CA application to cover all > > > > > possible and new requirements and introduce a new person in charge of > > > > > coordinating these implementations." > > > > > > > > > > I think it's problematic to suggest "without problems", and > > concerning > > > > that > > > > > it required a "big effort" to improving. It equally remains > > > > > problematic/concerning that the in-house CA software has continued to > > > > show > > > > > issues. > > > > > > > > > When we said “without problems” means that our practices and tools (PKI > > > > platform included) has passed many audit successfully. Sure, we have to > > > > improve (this very process, and every control, audits, certifications > > helps > > > > us to improve it). Just to let the community know, this is the list of > > AC > > > > Camerfirma SA last audit process: > > > > ETSI 319 401 Audited by TÜV-IT (2017-2019) > > > > > > https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/9725UE_s.pdf > > > > ETSI 319 401 Audited by CSQA (2017-2019) > > > > > > http://docs.camerfirma.com/publico/DocumentosWeb/certificaciones/certificatocamerfirma2017.pdf > > > > ETSI 319 411-1 Audited by TÜV-IT (2017-2019) > > > > > > https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/9725UE_s.pdf > > > > ETSI 319 411-1 Audited by CSQA (2017-2019) > > > > > > http://docs.camerfirma.com/publico/DocumentosWeb/certificaciones/certificatocamerfirma2017.pdf > > > > ETSI 319 411-2 Audited by TÜV-IT (2017-2019) > > > > > > https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/9725UE_s.pdf > > > > ETSI 319 411-2 Audited by CSQA (2017-2019) > > > > > > http://docs.camerfirma.com/publico/DocumentosWeb/certificaciones/certificatocamerfirma2017.pdf > > > > ETSI 319 421 Audited by CSQA (2017-2019) > > > > > > http://docs.camerfirma.com/publico/DocumentosWeb/certificaciones/certificatocamerfirma2017.pdf > > > > WEBTRUST FOR CA Audited by AUREN (2017) > > > > https://cert.webtrust.org/SealFile?seal=2283&file=pdf > > > > WEBTRUST BR Audited by AUREN (2017-2018) > > > > https://cert.webtrust.org/SealFile?seal=2284&file=pdf > > > > WEBTRUST EV Audited by AUREN (2017-2018) > > > > https://cert.webtrust.org/SealFile?seal=2285&file=pdf > > > > ISO 27001 Audited by AENOR (2016-2019) > > > > > > http://docs.camerfirma.com/publico/DocumentosWeb/certificaciones/ISO_27001_AENOR.pdf > > > > ISO 20000 Audited by AENOR (2016-2019) > > > > > > http://docs.camerfirma.com/publico/DocumentosWeb/certificaciones/ISO_20000_AENOR.pdf > > > > . > > > > > > > > In spite of the issues arisen, hope that at least this could count on > > our > > > > favor when a decision about our root inclusion were taken. > > > > > > > > > Camerfirma states that it believes those issues remediated, in part, > > by > > > > > extending technical controls. Yet many of these failures also > > highlight > > > > > problems in the design of the system (and its reliance on RAs) and > > the > > > > > staff tasked with understanding and implementing compliance. > > > > > > > > > > In the midst of all of this overhaul at Camerfirma, the 2016 root was > > > > > created. The existing roots still show problems (such as their CP/CPS > > > > > issues), and it seems energy has been focused on the new root, > > despite it > > > > > operating for a considerable time on the legacy infrastructure and > > > > subject > > > > > to issues as recently as 3 months ago. > > > > > > > > > > If, despite the evidence, we are to believe that Camerfirma has > > > > remediated > > > > > the technical issues (via the technical controls deployed in February > > > > 2018) > > > > > and has remediated the policy issues (via the onboarding of new staff > > > > > tasked with ensuring compliance in December 2017), then it seems > > > > minimally > > > > > appropriate to suggest that a new, Camerfirma 2018 root be created > > and > > > > > established. Camerfirma's 2016 root can be used to cross-certify > > this, > > > > thus > > > > > supporting those users on Microsoft platforms for which 2016 is > > trusted, > > > > > while providing greater assurance that the issuance and trust is > > > > > appropriate. Such an inclusion should not occur until a key > > generation > > > > > ceremony report, a point in time audit, and a period of time audit > > report > > > > > have been provided for the new 2018 root, which would mean would not > > be > > > > > reconsidered for at least 3 months, at a minimum. This would also > > ensure > > > > > that Camerfirma has completed its remediation steps for its existing > > set > > > > of > > > > > hierarchy, such as updating the CP/CPS, demonstrating that the new > > > > controls > > > > > and personnel are equipped to maintain a globally trusted CA. > > > > > > > > > > Further, given Camerfirma's statements that their investment in > > > > compliance > > > > > is with regards to the 2016 root, and the issue the prior roots have > > had > > > > > (both from policy compliance and issuance), it seems that we should > > also > > > > > begin discussing at what point trust in those legacy roots should be > > > > > removed, up to and including disallowing new certificates from it if > > > > > existing certificates are to remain trusted, as new issuance will be > > > > > on/from the 2018 root (through the 2016 path, for Windows users) > > > > > > > > Creating a new root 2018 is unfeasible for us for the following > > reasons: > > > > •Root 2016 is already audited and incorporated into the European TSL > > based > > > > on the favorable evaluation of our national supervisor body for both > > the > > > > issuance of S/MIME, WEB and TSU certificates. > > > > •Root is already recognized by other comunities such as Microsoft and > > > > Adobe. > > > > •Root 2016 is already accredited in the Spanish public administration & > > > > Public Services. > > > > •And above all, because the problems found so far have not > > incorporated a > > > > significant risk to the user community and they have been solved by > > > > incorporating technical controls and specific resources that currently > > > > allow us to commit with the ecosystem requirements. > > > > > > > > > The path I provided ensures every one of those things continues to work. > > > > > > Can you please elaborate more as to why it is unfeasible? > > > > > > > > > > > Hi Ryan > > > > Sure, this could work for browsers validation, but our concern is about > > Web Certificates for Spanish Public administration. > > Spanish Public Administration is AC Camerfirma main customer. > > Additionally, Roots should be accepted by public administration validation > > services. > > > And cross-signing covers this. > > > > > > So, if we provide a new root 2018, first of all, we should pass a new > > eIDAS conformity assessment for the new roots and then send it to > > administration validation services to be accepted by each particular public > > service. > > > This is not correct. Cross-signing the 2018 Root with the 2016 root allows > all services that support your 2016 root to continue to work without > disruption. From the point of view of clients, you’ve just added another > intermediate certificate. > > > > We have been working for month to be our root 2016 recognized by Spanish > > public services. We hope this could be improved in a future but nowadays is > > so complicated. > > > Yes, but the cross-signing of the 2018 root with the 2016 root will ensure > all the work you have done for 2016 is applied. > > > > > > We have been waiting for Mozilla 2016 root inclusion for many years, and > > we have to going back to the starting point ? > > Root 2016 are not having problems, we have issue only a few SSL > > certificates. It has nothing to do with StartCom, Have technical controls > > to avoid related problems found with RA validation and other, have no CPS > > problems.... I don't know how creating a new root 2018 can improve our > > trust for the community, in contrast, it will produce an economic damage > > and time consuming tasks for Camerfirma. > > > > I’m afraid this statement is not correct, and it’s based on an unfortunate > understanding about what is being proposed - and how PKI works. > > None of what you’ve described is required by what I have proposed here. > > > > Regards > > Ramiro > > _______________________________________________ > > dev-security-policy mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-security-policy > > On Friday, March 23, 2018 at 4:20:51 PM UTC+1, Ryan Sleevi wrote: > On Fri, Mar 23, 2018 at 1:12 PM ramirommunoz--- via dev-security-policy < > [email protected]> wrote: > > > On Thursday, March 22, 2018 at 10:43:49 PM UTC+1, Ryan Sleevi wrote: > > > On Thu, Mar 22, 2018 at 6:26 PM ramirommunoz--- via dev-security-policy < > > > [email protected]> wrote: > > > > > > > Hi Ryan > > > > Many thanks for your report. I will try to answer to your concerns > > about > > > > our root inclusión. > > > > > > > > > In attempt to discuss continued trust, I have attempted to summarize > > the > > > > > patterns and issues of note, along with the timeline from reporting > > to > > > > > remediation. It is my goal that this will allow the public to make an > > > > > objective assessment of the risks introduced by Camerfirma, as well > > as > > > > the > > > > > responsiveness towards remediation. While the ecosystem continues to > > > > > improve both its understanding of the requirements and expectations, > > we > > > > > must nevertheless consider the full picture. > > > > > > > > > > Issue 1: Invalid dNSNames/CNs ( > > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 ) > > > > > 2014-09-25 - https://crt.sh/?id=5129200&opt=cablint issued > > > > > 2017-08-12 - Jonathan Rudenberg posts to m.d.s.p > > > > > 2017-08-13 - Jonathan Rudenberg contacts the CA > > > > > 2017-08-16 - Kathleen Wilson opens a Bugzilla incident > > > > > 2017-08-17 - Camerfirma Responds > > > > > 2017-09 - Scheduled remediation > > > > > 2017-12 - First attempted remediation > > > > > 2018-02-14 - Actual remediation, as per > > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c33 > > > > > > > > > > Issue 2: Unrevoked Internal Servernames ( > > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 ) > > > > > 2016-10-01 - Deadline for revoking internal server name certificates > > > > > 2017-08-24 - Camerfirma shares list of misissued certificates > > affected by > > > > > Issue 1, along with their response > > > > > 2017-08-24 - Ryan Sleevi highlights that Camerfirma failed to > > identify > > > > and > > > > > revoke internal server name certificates - > > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c13 > > > > > 2017-09-12 - Camerfirma revokes https://crt.sh/?id=8680123&opt=ocsp > > > > > 2017-11-28 - Gerv Markham highlights that Camerfirma has still not > > > > > responded to outstanding questions - > > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c21 > > > > > 2017-12-21 - Camerfirma responds to the substance of the questions > > > > > > > > > > Issue 3 - Improperly Configured OCSP - > > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1426233 > > > > > 2017-12-12 - Rob Stradling reports on CA's improperly configured OCSP > > > > > configurations at > > > > > > > > > > > https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/C2vTpvouP3g > > > > > 2017-12-19 - Wayne Thayer opens a bug regarding OCSP non-conformance > > by > > > > > Camerfirma > > > > > 2017-12-22 - Camerfirma confirms the issue is resolved. It took one > > of > > > > > their sub-CAs from 12-12 to 12-19, and another from 12-12 to 12-22, > > to > > > > > implement these changes. Camerfirma did not self-report this > > > > > non-compliance, despite acknowledging it on 12-12. > > > > > 2018-01-03 - Camerfirma completes a minimal incident report with all > > > > > required information. > > > > > > > > > > Issue 4 - Improper CAA checking ( > > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1420871 ) > > > > > 2017-09-08 - Baseline Requirements require checking CAA > > > > > 2017-11-27 - Quirin Scheitle reports CAA checking non-compliance by > > > > > Camerfirma > > > > > 2017-11-29 - Camerfirma confirms misissuance, believing it was valid > > > > > because they found "and for which CAA was checked" to be confusing > > and > > > > > indicating that CAA checking was optional. > > > > > 2017-11-29 - Camerfirma claims CAA checking is activated on all RAs > > > > > > > > > > > > > All previous bugs as you said are closed successfully. > > > > > > > > > > > > > > Issue 5 - Duplicate dNSNames and invalid > > > > localityName/stateOrProvinceName ( > > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1357067 ) > > > > > 2017-04-17 - Issue reported > > > > > 2017-04-20 - Camerfirma reports the issue is fixed to StartCom. The > > issue > > > > > is apparently a Camerfirma issue, and with improper logging as well > > as > > > > > certificate configuration. > > > > > 2017-10-13 - StartCom provides incident report, as a Camerfirma > > reseller > > > > > Note: No response was provided by Camerfirma in this incident report. > > > > > > > > > We were not aware that an answer from us was needed. The incident > > report > > > > provided by StartCom was coordinated with us. > > > > > > > > > > Issue 6 - Out of date CP/CPSes > > > > > 2016-06 - Last published version of the CPS at > > > > > > > > > > > http://docs.camerfirma.com/publico/DocumentosWeb/politicas/CPS_V_3_2_7_EN.pdf > > > > > 2018-05 - Next proposed update of the CPS, as stated elsewhere on > > this > > > > > thread > > > > > > > > > We already have a new CPS version, next week we will publish it, and a > > new > > > > version when it was RFC 3647 compliant. > > > > > > > > > > > > > > I'm not sure whether to track issues with the new hierarchy, so I > > will > > > > > simply note the following: > > > > > 2017-08-23 - Last issued certificate with invalid dNSName ( > > > > > > > > > > > https://crt.sh/?caid=50473&opt=cablint,zlint,x509lint&minNotBefore=2011-01-01 > > > > > ) > > > > > 2017-12-13 - Last issued certificate that violates RFC 5280, > > 4.1.2.4's > > > > > requirements that "CAs conforming to this profile MUST use either the > > > > > PrintableString or UTF8String encoding of DirectoryString, with two > > > > > exceptions" ( > > > > https://crt.sh/?cablint=261&iCAID=50473&minNotBefore=2011-01-01 ) > > > > > > > > > there is an open bug > > https://bugzilla.mozilla.org/show_bug.cgi?id=1443857 > > > > where previous bug are treated. > > > > > > > > > > > > > > Notable is that Camerfirma includes the organizationIdentifier, > > > > > OID 2.5.4.97, in their certificates. This is documented in the CPS > > [5] > > > > from > > > > > the original message, within Section 3.1.1, with the validation > > process > > > > > described in 3.1.8.1. However, the CP/CPS lacks details as to the > > > > > construction and validation - it appears to be a construction of > > "VAT" > > > > > [member state] "-" [VAT number] > > > > > > > > > website certificates profile is defined in ETSI EN 319 412-4. This > > > > standard refers ETSI EN 319 412-1 where this OID is defined. VAT is as > > > > defined in CPS section 3.1.8.2.3 > > > > > > > > > > > > > > In this, we see a pattern of issues, with a strong reliance on > > trusting > > > > RAs > > > > > (which included entities such as StartCom, known to not be validating > > > > > correctly) and, when failure detected, on technical controls. We see > > a > > > > > pattern of delayed remediation, misunderstanding of expectations in > > the > > > > > face of misissuance, and misunderstandings of the requirements > > > > themselves. > > > > > If there is any one remark that perfectly captures this, it would be > > > > found > > > > > in https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c30 , > > provided > > > > on > > > > > 2017-12-21 (i.e. after many of these issues) > > > > > > > > > We rely on our RA network and we train them and audit them for assure a > > > > correct validation. As a result of > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c30 technical > > > > controls were deployed to avoid misissuance, misunderstandings and > > reduce > > > > this dependency on trusting RAs. > > > > > > > > > > > > > > "AC Camerfirma is a small CA that uses an in-house developed CA > > software > > > > > and is supported by our RA trusted operators and the continuous > > training > > > > > they receive. AC Camerfirma has been working with this technology and > > > > staff > > > > > for 17 years without problems and we have dedicated a big effort > > > > improving > > > > > it along those years. Due to the number of TLS certificates issued on > > > > > previous years, this working method was appropriate and suitable for > > us. > > > > > The increase of certificates issued, increasing technical > > requirements > > > > and > > > > > the analysis of these reported problems have helped us to realize the > > > > need > > > > > to extend the technical controls in the CA application to cover all > > > > > possible and new requirements and introduce a new person in charge of > > > > > coordinating these implementations." > > > > > > > > > > I think it's problematic to suggest "without problems", and > > concerning > > > > that > > > > > it required a "big effort" to improving. It equally remains > > > > > problematic/concerning that the in-house CA software has continued to > > > > show > > > > > issues. > > > > > > > > > When we said “without problems” means that our practices and tools (PKI > > > > platform included) has passed many audit successfully. Sure, we have to > > > > improve (this very process, and every control, audits, certifications > > helps > > > > us to improve it). Just to let the community know, this is the list of > > AC > > > > Camerfirma SA last audit process: > > > > ETSI 319 401 Audited by TÜV-IT (2017-2019) > > > > > > https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/9725UE_s.pdf > > > > ETSI 319 401 Audited by CSQA (2017-2019) > > > > > > http://docs.camerfirma.com/publico/DocumentosWeb/certificaciones/certificatocamerfirma2017.pdf > > > > ETSI 319 411-1 Audited by TÜV-IT (2017-2019) > > > > > > https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/9725UE_s.pdf > > > > ETSI 319 411-1 Audited by CSQA (2017-2019) > > > > > > http://docs.camerfirma.com/publico/DocumentosWeb/certificaciones/certificatocamerfirma2017.pdf > > > > ETSI 319 411-2 Audited by TÜV-IT (2017-2019) > > > > > > https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/9725UE_s.pdf > > > > ETSI 319 411-2 Audited by CSQA (2017-2019) > > > > > > http://docs.camerfirma.com/publico/DocumentosWeb/certificaciones/certificatocamerfirma2017.pdf > > > > ETSI 319 421 Audited by CSQA (2017-2019) > > > > > > http://docs.camerfirma.com/publico/DocumentosWeb/certificaciones/certificatocamerfirma2017.pdf > > > > WEBTRUST FOR CA Audited by AUREN (2017) > > > > https://cert.webtrust.org/SealFile?seal=2283&file=pdf > > > > WEBTRUST BR Audited by AUREN (2017-2018) > > > > https://cert.webtrust.org/SealFile?seal=2284&file=pdf > > > > WEBTRUST EV Audited by AUREN (2017-2018) > > > > https://cert.webtrust.org/SealFile?seal=2285&file=pdf > > > > ISO 27001 Audited by AENOR (2016-2019) > > > > > > http://docs.camerfirma.com/publico/DocumentosWeb/certificaciones/ISO_27001_AENOR.pdf > > > > ISO 20000 Audited by AENOR (2016-2019) > > > > > > http://docs.camerfirma.com/publico/DocumentosWeb/certificaciones/ISO_20000_AENOR.pdf > > > > . > > > > > > > > In spite of the issues arisen, hope that at least this could count on > > our > > > > favor when a decision about our root inclusion were taken. > > > > > > > > > Camerfirma states that it believes those issues remediated, in part, > > by > > > > > extending technical controls. Yet many of these failures also > > highlight > > > > > problems in the design of the system (and its reliance on RAs) and > > the > > > > > staff tasked with understanding and implementing compliance. > > > > > > > > > > In the midst of all of this overhaul at Camerfirma, the 2016 root was > > > > > created. The existing roots still show problems (such as their CP/CPS > > > > > issues), and it seems energy has been focused on the new root, > > despite it > > > > > operating for a considerable time on the legacy infrastructure and > > > > subject > > > > > to issues as recently as 3 months ago. > > > > > > > > > > If, despite the evidence, we are to believe that Camerfirma has > > > > remediated > > > > > the technical issues (via the technical controls deployed in February > > > > 2018) > > > > > and has remediated the policy issues (via the onboarding of new staff > > > > > tasked with ensuring compliance in December 2017), then it seems > > > > minimally > > > > > appropriate to suggest that a new, Camerfirma 2018 root be created > > and > > > > > established. Camerfirma's 2016 root can be used to cross-certify > > this, > > > > thus > > > > > supporting those users on Microsoft platforms for which 2016 is > > trusted, > > > > > while providing greater assurance that the issuance and trust is > > > > > appropriate. Such an inclusion should not occur until a key > > generation > > > > > ceremony report, a point in time audit, and a period of time audit > > report > > > > > have been provided for the new 2018 root, which would mean would not > > be > > > > > reconsidered for at least 3 months, at a minimum. This would also > > ensure > > > > > that Camerfirma has completed its remediation steps for its existing > > set > > > > of > > > > > hierarchy, such as updating the CP/CPS, demonstrating that the new > > > > controls > > > > > and personnel are equipped to maintain a globally trusted CA. > > > > > > > > > > Further, given Camerfirma's statements that their investment in > > > > compliance > > > > > is with regards to the 2016 root, and the issue the prior roots have > > had > > > > > (both from policy compliance and issuance), it seems that we should > > also > > > > > begin discussing at what point trust in those legacy roots should be > > > > > removed, up to and including disallowing new certificates from it if > > > > > existing certificates are to remain trusted, as new issuance will be > > > > > on/from the 2018 root (through the 2016 path, for Windows users) > > > > > > > > Creating a new root 2018 is unfeasible for us for the following > > reasons: > > > > •Root 2016 is already audited and incorporated into the European TSL > > based > > > > on the favorable evaluation of our national supervisor body for both > > the > > > > issuance of S/MIME, WEB and TSU certificates. > > > > •Root is already recognized by other comunities such as Microsoft and > > > > Adobe. > > > > •Root 2016 is already accredited in the Spanish public administration & > > > > Public Services. > > > > •And above all, because the problems found so far have not > > incorporated a > > > > significant risk to the user community and they have been solved by > > > > incorporating technical controls and specific resources that currently > > > > allow us to commit with the ecosystem requirements. > > > > > > > > > The path I provided ensures every one of those things continues to work. > > > > > > Can you please elaborate more as to why it is unfeasible? > > > > > > > > > > > Hi Ryan > > > > Sure, this could work for browsers validation, but our concern is about > > Web Certificates for Spanish Public administration. > > Spanish Public Administration is AC Camerfirma main customer. > > Additionally, Roots should be accepted by public administration validation > > services. > > > And cross-signing covers this. > > > > > > So, if we provide a new root 2018, first of all, we should pass a new > > eIDAS conformity assessment for the new roots and then send it to > > administration validation services to be accepted by each particular public > > service. > > > This is not correct. Cross-signing the 2018 Root with the 2016 root allows > all services that support your 2016 root to continue to work without > disruption. From the point of view of clients, you’ve just added another > intermediate certificate. > > > > We have been working for month to be our root 2016 recognized by Spanish > > public services. We hope this could be improved in a future but nowadays is > > so complicated. > > > Yes, but the cross-signing of the 2018 root with the 2016 root will ensure > all the work you have done for 2016 is applied. > > > > > > We have been waiting for Mozilla 2016 root inclusion for many years, and > > we have to going back to the starting point ? > > Root 2016 are not having problems, we have issue only a few SSL > > certificates. It has nothing to do with StartCom, Have technical controls > > to avoid related problems found with RA validation and other, have no CPS > > problems.... I don't know how creating a new root 2018 can improve our > > trust for the community, in contrast, it will produce an economic damage > > and time consuming tasks for Camerfirma. > > > > I’m afraid this statement is not correct, and it’s based on an unfortunate > understanding about what is being proposed - and how PKI works. > > None of what you’ve described is required by what I have proposed here. > > > > Regards > > Ramiro > > _______________________________________________ > > dev-security-policy mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-security-policy > > Hi Ryan Thanks again for your remarks. In the end I am going to learn something of PKI :-). Surely I do not get a full understanding of you solution, but public administration is requiring a EU qualified Web certificate this means that should be included in the EUTL. I do know other solution for a new root but a new conformity assessment. Nevertheless, let me insist. In which aspects a new root 2018 improve our trustworthiness instead of the current root 2016? Best Regards Ramiro _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
