Re: Public trust of VISA's CA
On 20/09/2017 09:37, Martin Rublik wrote: On Tue, Sep 19, 2017 at 5:22 PM, Alex Gaynor via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: https://crt.sh/mozilla-certvalidations?group=version&id=896972 is a very informative graph for me -- this is the number of validations performed by Firefox for certs under this CA. It looks like at the absolute peak, there were 1000 validations in a day. That's very little value for our users, in return for an awful lot of risk. Alex Hi, I agree that 1000 validations in a day is not much, or better to say really low number. Anyway I was wondering what should be a minimum value or whether this number is a good metric at all. I went through the Mozilla validations telemetrics and there are more CAs with similliar number of validations. In interpreting that statistic, it is worth noting that Banks etc. tend to have strong internal security configuration policies, which probably include the disabling of all kinds of application "telemetry". But it is still worth considering if this CA root should only be a non-public CA root, included only by local configuration (typically using the Firefox/Thunderbird enterprise deployment tools in the case of Firefox/Thunderbird). The age of their inclusion suggests a long transition period if removal is solely for formal reasons rather than actual insecurity. And of cause such removal should be in a form that doesn't block manual reinclusion via configuration. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
SHA-1 OCSP responder certificates
On September 8, 2017, a member our team discovered that one of our OCSP responder certificates had been signed with SHA-1 with a notBefore date of May 23, 2017. We initiated an investigation and discovered that there were a total of 4 such certificates, all issued on May 23 as annual renewals to support our old SHA-1 issuing CAs until the last of the certificates issued from them has expired or been revoked and the CAs themselves can be revoked. The 4 OCSP responder certificates have been posted to CT and are available from the following URLs: https://crt.sh/?id=201187008 https://crt.sh/?id=214252118 https://crt.sh/?id=214252119 https://crt.sh/?id=214252120 Our OCSP responses are generated on the same HSMs that host our issuing CAs, so the renewal of the OCSP signing certificates is performed using a script executed directly on the CA servers during a scheduled quarterly CA room entry. This issuance was the result of an oversight in updating that script from the one used in 2016, in order to force the non-default behavior of signing the responder certificates with a different hash than the one with which the CA itself is signed. None of our active issuing CAs, nor our offline root CAs were affected. Our offline root CAs also use delegated OCSP responder certificates, which were also renewed on the same day, but were properly signed with SHA-256. Our active SHA-256 issuing CAs sign OCSP responses directly and thus do not require responder certificates. We are in the process of updating the OCSP responder issuing script and testing it in our test environment. We will then schedule a CA room entry to repeat this procedure to issue and deploy new SHA-256 signed certificate replacements and revoke the stated 4 certificates. We expect to complete this by the end of the month. The last still-valid certificate expiration dates for the 4 CAs are as follows: DVCA: October 24, 2017 OVCA: January 19, 2018 CLACA: December 10, 2018 CSCA: March 18, 2019 Based on these dates, we would anticipate revoking both DVCA and OVCA in Q1 2018, and performing one more OCSP responder renewal for CLACA and CSCA in mid-2018, for which we will use the updated SHA-256 script. As further insurance against this happening in the future, we have updated QA procedures to explicitly check the signature algorithm on OCSP responder certificate renewals when testing our quarterly CA room activities. We appreciate the efforts of the independent researchers who have identified a variety of issues as of late, and apologize for our oversight in this instance. We also welcome any further suggestions members of the community may provide on this matter. Best regards, Frank Corday Trustwave ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Audit Reminder Email Summary
On Wednesday, September 20, 2017 at 6:34:04 AM UTC-7, Kurt Roeckx wrote: > On 2017-09-20 01:09, Kathleen Wilson wrote: > > Forwarded Message > > Subject: Summary of September 2017 Audit Reminder Emails > > Date: Tue, 19 Sep 2017 19:00:08 + (GMT) > > > > Mozilla: Overdue Audit Statements > > Root Certificates: > > Autoridad de Certificacion Firmaprofesional CIF A62634068 > > Standard Audit: https://cert.webtrust.org/SealFile?seal=2032&file=pdf > > Audit Statement Date: 2016-04-11 > > BR Audit: https://bug521439.bmoattachments.org/attachment.cgi?id=8809981 > > BR Audit Statement Date: 2016-08-05 > > EV Audit: https://bug521439.bmoattachments.org/attachment.cgi?id=8809982 > > EV Audit Statement Date: 2016-08-05 > > CA Comments: BR and EV audits have happened, but there are action plans > > being presented to the auditors. Primary issues are use of UTF8 instead of > > PrintableString in jurisdictionOfIncorporation, and a recently repealed > > Spanish law that required privat > > Does that mean the standard audit did not happen? The currently linked > one covered the period 2015-03-10 to 2016-03-09. The next period of 1 > year is now over for more than 6 months. > > If the audits happened, why don't we have the audit statement yet? > I'll contact the CA, and ask them to respond. I noticed that for the audit reminders the program was sending to the email alias only, so I've asked my Salesforce consultant to make sure the Primary POC(s) are always in the 'To' list for the emails. However, it is the CA's responsibility to provide their updated audit statements, so not receiving the audit reminder email does not excuse them. > > Mozilla: Audit Reminder > > Root Certificates: > > Chambers of Commerce Root > > Chambers of Commerce Root - 2008 > > Global Chambersign Root > > Global Chambersign Root - 2008 > > Standard Audit: > > https://bug986854.bmoattachments.org/attachment.cgi?id=8775118 > > Audit Statement Date: 2016-06-17 > > BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8800807 > > BR Audit Statement Date: 2016-08-05 > > EV Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8800811 > > EV Audit Statement Date: 2016-08-05 > > CA Comments: null > > The standard audit was for the period of 2015-04-14 to 2016-04-13, and > so are also late with their audit. I'll contact the CA... > > > Mozilla: Audit Reminder > > Root Certificates: > > GlobalSign ECC Root CA - R5 > > Standard Audit: https://cert.webtrust.org/SealFile?seal=2287&file=pdf > > Audit Statement Date: 2017-07-26 > > BR Audit: https://bug1388488.bmoattachments.org/attachment.cgi?id=8895040 > > BR Audit Statement Date: 2017-07-26 > > EV Audit: https://cert.webtrust.org/SealFile?seal=2055&file=pdf > > EV Audit Statement Date: 2016-06-10 > > CA Comments: null > > The EV period was from 2015-04-01 to 2013-03-31. The others are new, > maybe forgot to update something? Bug in CCADB. I am waiting for my Salesforce consultant to confirm that she has replicated the bug in Sandbox, and then I will fix the data in Production. > > > Mozilla: Audit Reminder > > Root Certificates: > > Certum Trusted Network CA 2** > > Certum Trusted Network CA** > > > > ** Audit Case in the Common CA Database is under review for this root > > certificate. > > > > Standard Audit: https://cert.webtrust.org/SealFile?seal=2064&file=pdf > > Audit Statement Date: 2016-06-10 > > BR Audit: https://cert.webtrust.org/SealFile?seal=2066&file=pdf > > BR Audit Statement Date: 2016-06-10 > > EV Audit: https://cert.webtrust.org/SealFile?seal=2065&file=pdf > > EV Audit Statement Date: 2016-06-10 > > CA Comments: null > As noted by the '**' we have received the updated audit statements, and are working with the CA on their Audit Case. Since the Audit Case is a new process, there is a learning curve for most CAs. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: DigiCert-Symantec Announcement
The original Mozilla plan was to distrust around Sep 2018. We're still planning for that date, but would appreciate it if trust was permitted around a single intermediate (say the DigiCert Global Trust G2 root?). If we need to use a separate root with no other certs as the transition, we could create one. I know my team would prefer it as the Global Trust G2 root is our primary SHA2 root. -Original Message- From: Peter Bowen [mailto:pzbo...@gmail.com] Sent: Wednesday, September 20, 2017 10:21 AM To: Jeremy Rowley Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: DigiCert-Symantec Announcement On Tue, Sep 19, 2017 at 8:39 PM, Jeremy Rowley via dev-security-policy wrote: > > The current end-state plan for root cross-signing is provided at > https://bugzilla.mozilla.org/show_bug.cgi?id=1401384. The diagrams there show > all of the existing sub CAs along with the new Sub CAs and root signings > planned for post-close. Some of these don’t have names so they are lumped in > a general “Intermediate” box. > > The Global G2 root will become the transition root to DigiCert for customers > who can’t move fully to an operational DigiCert roots prior to September > 2018. Any customers that require a specific root can use the transition root > for as long as they want, realizing that path validation may be an issue as > Symantec roots are removed by platform operators. Although we cannot > currently move to a single root because of the lack of EV support and trust > in non-Mozilla platforms, we can move to the existing three roots in an > orderly fashion. > > If the agreement closes prior to Dec 1, the Managed CA will never exist. > Instead, all issuance will occur through one of the three primary DigiCert > roots mentioned above with the exception of customers required to use a > Symantec root for certain platforms or pinning. The cross-signed Global root > will be only transitory, meaning we’d hope customers would migrate to the > DigiCert roots once the systems requiring a specific Symantec roots are > deprecated or as path validation errors arise. Jeremy, Am I correct that a key input into this plan was the Mozilla plan to fully remove the Symantec roots from the trust store before then end of 2018? Google seemed to suggest they would keep trusting them for a longer period with a restriction on which subordinate CAs are trusted. Thanks, Peter smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DigiCert-Symantec Announcement
On Tue, Sep 19, 2017 at 8:39 PM, Jeremy Rowley via dev-security-policy wrote: > > The current end-state plan for root cross-signing is provided at > https://bugzilla.mozilla.org/show_bug.cgi?id=1401384. The diagrams there show > all of the existing sub CAs along with the new Sub CAs and root signings > planned for post-close. Some of these don’t have names so they are lumped in > a general “Intermediate” box. > > The Global G2 root will become the transition root to DigiCert for customers > who can’t move fully to an operational DigiCert roots prior to September > 2018. Any customers that require a specific root can use the transition root > for as long as they want, realizing that path validation may be an issue as > Symantec roots are removed by platform operators. Although we cannot > currently move to a single root because of the lack of EV support and trust > in non-Mozilla platforms, we can move to the existing three roots in an > orderly fashion. > > If the agreement closes prior to Dec 1, the Managed CA will never exist. > Instead, all issuance will occur through one of the three primary DigiCert > roots mentioned above with the exception of customers required to use a > Symantec root for certain platforms or pinning. The cross-signed Global root > will be only transitory, meaning we’d hope customers would migrate to the > DigiCert roots once the systems requiring a specific Symantec roots are > deprecated or as path validation errors arise. Jeremy, Am I correct that a key input into this plan was the Mozilla plan to fully remove the Symantec roots from the trust store before then end of 2018? Google seemed to suggest they would keep trusting them for a longer period with a restriction on which subordinate CAs are trusted. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: DigiCert-Symantec Announcement
Post-close, all products and offerings will stay the same as pre-close except that DigiCert will do the validation and issuance. This does mean DigiCert is offering a DV product post close. We agreed with Ryan that separation by root for DV, OV, and EV doesn't make much sense, meaning all TSL certs will issue from the generally the same roots. Right now, the Global Trust CA root will be our primary root for issuing TLS certs, but the High Assurance root will remain dedicated to OV and EV certs. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of James Burton via dev-security-policy Sent: Wednesday, September 20, 2017 4:33 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: DigiCert-Symantec Announcement Hi Jeremy, Is DigiCert planning on continuing selling DV certificates after the transition? As DigiCert has previously been vocal on the fact that the drawbacks of issuing DV certificates outweigh the benefits as stated here: https://www.digicert.com/dv-ssl-certificate.htm. If DigiCert is going to issue DV certificates which root or roots are you going to dedicated for the certificates? James ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Audit Reminder Email Summary
On 2017-09-20 01:09, Kathleen Wilson wrote: Forwarded Message Subject: Summary of September 2017 Audit Reminder Emails Date: Tue, 19 Sep 2017 19:00:08 + (GMT) Mozilla: Overdue Audit Statements Root Certificates: Autoridad de Certificacion Firmaprofesional CIF A62634068 Standard Audit: https://cert.webtrust.org/SealFile?seal=2032&file=pdf Audit Statement Date: 2016-04-11 BR Audit: https://bug521439.bmoattachments.org/attachment.cgi?id=8809981 BR Audit Statement Date: 2016-08-05 EV Audit: https://bug521439.bmoattachments.org/attachment.cgi?id=8809982 EV Audit Statement Date: 2016-08-05 CA Comments: BR and EV audits have happened, but there are action plans being presented to the auditors. Primary issues are use of UTF8 instead of PrintableString in jurisdictionOfIncorporation, and a recently repealed Spanish law that required privat Does that mean the standard audit did not happen? The currently linked one covered the period 2015-03-10 to 2016-03-09. The next period of 1 year is now over for more than 6 months. If the audits happened, why don't we have the audit statement yet? Mozilla: Audit Reminder Root Certificates: Chambers of Commerce Root Chambers of Commerce Root - 2008 Global Chambersign Root Global Chambersign Root - 2008 Standard Audit: https://bug986854.bmoattachments.org/attachment.cgi?id=8775118 Audit Statement Date: 2016-06-17 BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8800807 BR Audit Statement Date: 2016-08-05 EV Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8800811 EV Audit Statement Date: 2016-08-05 CA Comments: null The standard audit was for the period of 2015-04-14 to 2016-04-13, and so are also late with their audit. Mozilla: Audit Reminder Root Certificates: GlobalSign ECC Root CA - R5 Standard Audit: https://cert.webtrust.org/SealFile?seal=2287&file=pdf Audit Statement Date: 2017-07-26 BR Audit: https://bug1388488.bmoattachments.org/attachment.cgi?id=8895040 BR Audit Statement Date: 2017-07-26 EV Audit: https://cert.webtrust.org/SealFile?seal=2055&file=pdf EV Audit Statement Date: 2016-06-10 CA Comments: null The EV period was from 2015-04-01 to 2013-03-31. The others are new, maybe forgot to update something? Mozilla: Audit Reminder Root Certificates: Certum Trusted Network CA 2** Certum Trusted Network CA** ** Audit Case in the Common CA Database is under review for this root certificate. Standard Audit: https://cert.webtrust.org/SealFile?seal=2064&file=pdf Audit Statement Date: 2016-06-10 BR Audit: https://cert.webtrust.org/SealFile?seal=2066&file=pdf BR Audit Statement Date: 2016-06-10 EV Audit: https://cert.webtrust.org/SealFile?seal=2065&file=pdf EV Audit Statement Date: 2016-06-10 CA Comments: null The period was 2015-04-15 to 2016-04-14. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Public trust of VISA's CA
On Wed, Sep 20, 2017 at 12:37 AM, Martin Rublik via dev-security-policy wrote: > On Tue, Sep 19, 2017 at 5:22 PM, Alex Gaynor via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> https://crt.sh/mozilla-certvalidations?group=version&id=896972 is a very >> informative graph for me -- this is the number of validations performed by >> Firefox for certs under this CA. It looks like at the absolute peak, there >> were 1000 validations in a day. That's very little value for our users, in >> return for an awful lot of risk. >> >> Alex > > > Hi, > > I agree that 1000 validations in a day is not much, or better to say really > low number. Anyway I was wondering what should be a minimum value or > whether this number is a good metric at all. I went through the Mozilla > validations telemetrics and there are more CAs with similliar number of > validations. Note that Firefox 55 had a regression on how it does chain building (https://bugzilla.mozilla.org/show_bug.cgi?id=1400913) that causes it prefer the longest chain rather than the shortest chain. This means, for Root CAs that are cross-signed, Firefox 55 will frequently attribute to the wrong bucket. The total on the buckets does not change, but the validations per day did shift. For example, Firefox 55 shows "AddTrust External CA Root" is a super popular root while prior versions had "COMODO RSA Certification Authority" as a top root. "Go Daddy Class 2 CA" and "Go Daddy Root Certificate Authority - G2" also flipped in Firefox 55. This does not impact the Visa bucket, as far as I know, as the Visa root is not cross-signed by any other root. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [saag] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt
Dear Nikos On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos wrote: > > 4. How do you handle extensions to this format? > > Overall, why not use X.509 extensions to store such additional > constraints? We already (in the p11-kit trust store in Fedora/RHEL > systems) use the notion of stapled extensions to limit certificates > [0, 1] and seems quite a flexible approach. Have you considered that > path? > > regards, > Nikos > > [0]. https://p11-glue.freedesktop.org/doc/storing-trust-policy/ > storing-trust-model.html > [1]. http://nmav.gnutls.org/2016/06/restricting-scope-of-ca- > certificates.html > I've looked through the specification. It's OK for me, but I do not get whether the attached extensions are crypto-protected. I'm ready to cooperate with you if there is any interest. -- SY, Dmitry Belyavsky ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DigiCert-Symantec Announcement
Hi Jeremy, Is DigiCert planning on continuing selling DV certificates after the transition? As DigiCert has previously been vocal on the fact that the drawbacks of issuing DV certificates outweigh the benefits as stated here: https://www.digicert.com/dv-ssl-certificate.htm. If DigiCert is going to issue DV certificates which root or roots are you going to dedicated for the certificates? James ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: DigiCert-Symantec Announcement
Thanks a ton, Ryan! This was very helpful, and we really appreciate the feedback and suggestions. Here’s what we currently use as publicly-trusted roots and how we use them: 1. Baltimore CyberTrust Root – Expires in 2025. Currently only used to support Verizon customers who have not transitioned to DigiCert’s roots for whatever reason (SubCAs, Pinned keys, etc) 2. CyberTrust Global Root – Expires in 2021 (I think) and used primarily in Japan. This is our EV root for customers who need trust in Japanese systems. 3. DigiCert Assured ID Root CA – RSA root that issues primarily client certs and code signing certificates. The root is trusted in Adobe and cross-signed by the FBCA (one-way trust). Although it issues some TLS certs, these TLS are only issued when a special cross-certification is required that is no available under the other roots. 4. DigiCert Assured ID Root G2 – RSA rollover root for the Assured ID root. Once sufficient ubiquity exists, the plan is to retire the Assured ID Root in favor of this one. 5. DigiCert Assured ID Root G3 – ECC version of the G2 root. This root is for entities who want a complete ECC chain. 6. DigiCert Global Root CA – RSA root that is used for OV and code signing certificates. This is our primary issuing root and is cross-signed by Baltimore for additional ubiquity. 7. DigiCert Global Root G2 – RSA rollover root intended to replace the Global Root CA. 8. DigiCert Global Root G3 – ECC version of the G2 root used to support entities who want a complete ECC chain 9. DigiCert High Assurance EV Root CA – Our only EV root until this bug is complete: https://bugzilla.mozilla.org/show_bug.cgi?id=1165472. This root is primarily used for entities who want one or more EV certificates and is cross-signed by the Baltimore root for ubiquity. 10. DigiCert Trusted Root CA – A 4096 bit root in case 2048 is no longer sufficient. This is cross-signed by the Global Root. Symantec has the following roots according to CCADB. Symantec would have to comment on how these are used. 1. Symantec Class 1 G4 2. Symantec Class 1 G6 3. Symantec Class 2 G4 4. Symantec Class 2 G6 5. Symantec Class 3 G4 6. Symantec Class G6 7. Symantec Enterprises Mobile 8. Equifax Secure Certificate Authority 9. Equifax Secure eBusiness CA-1 10. Equifax Secure Global eBusiness CA-1 11. GeoTrust Global CA 12. GeoTrust Global CA 2 13. GeoTrust Primary Certificate Authority 14. GeoTrust Primary Certificate Authority – G2 15. GeoTrust Primary Certificate Authority – G3 16. GeoTrust Universal CA 17. GeoTrust Universal CA 2 18. Thawte Premium Server CA 19. Thawte Primary Root CA 20. Thawte Primary Root CA – G2 21. Thawte Primary Root CA – G3 22. Thawte Server CA 23. Thawte Timestamping CA 24. UTN-Userfirst-Network Applications 25. Verisign Class 1 Public PCA 26. Verisign Class 3 Public Primary Certificate Authority – G4 27. Verisign Class 3 Public Primary Certificate Authority – G5 28. Verisign Class 4 Public Primary Certificate Authority – G3 29. Verisign Time Stamping CA 30. Verisign Universal Root Certificate Authority 31. Verisign4 32. Verisign Class 1 Public PCA – G3 33. Verisign Class 1 Public PCA – G2 34. Verisign Class 2 Public PCA – G3 35. Verisign Class 2 Public PCA – G2 36. Verisign Class 3 Public PCA 37. Verisign Class 3 Public PCA – MD2 38. Verisign Class 3 Public PCA – G2 39. Verisign Class 2 Public Primary Certification Authority – G3 The current end-state plan for root cross-signing is provided at https://bugzilla.mozilla.org/show_bug.cgi?id=1401384. The diagrams there show all of the existing sub CAs along with the new Sub CAs and root signings planned for post-close. Some of these don’t have names so they are lumped in a general “Intermediate” box. We reached the same conclusion as you about segmentation by root (that compartmentalization by root won’t work), not to mention that compartmentalization will be near impossible considering what we’ve previously issued and how the roots are trusted in various root programs. Instead, we plan on creating sub CAs based on the number of entities using the intermediate. For example, every 2000 or so entities will use another Sub CA. This will roughly segment customers based on excepted volumes. We also plan on providing a lot more unique intermediates on a per customer basis. Permitting large companies to have a dedicated intermediate will help shield them from being revoked if another Sub CA needs to be revoked and allow browsers to selectively whitelist/blacklist entities. Of course, not every company will want this, but it’ll be available for anyone who wants it. The plan, based on your suggestions, is to cross-sign the DigiCert Global G2 root with the four Symantec roots: 1.
Re: Public trust of VISA's CA
On Tue, Sep 19, 2017 at 5:22 PM, Alex Gaynor via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > https://crt.sh/mozilla-certvalidations?group=version&id=896972 is a very > informative graph for me -- this is the number of validations performed by > Firefox for certs under this CA. It looks like at the absolute peak, there > were 1000 validations in a day. That's very little value for our users, in > return for an awful lot of risk. > > Alex Hi, I agree that 1000 validations in a day is not much, or better to say really low number. Anyway I was wondering what should be a minimum value or whether this number is a good metric at all. I went through the Mozilla validations telemetrics and there are more CAs with similliar number of validations. Martin ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy