Re: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash Requirements
On Tue, May 21, 2019 at 3:32 PM Daniel McCarney wrote: > >> Of the 8 unrevoked, they're all issued by a single CA - GlobalSign - and >> are all RSA keys that lack the explicit NULL parameter, and thus violate >> the requirements of https://tools.ietf.org/html/rfc3279#section-2.3.1 > > >> These are flagged by cablint (but not zlint), so that is an opportunity >> for >> CAs to improve things - both in how they encode and how they lint. > > > Ryan: Thanks for flagging this difference between cablint and zlint. > > Let's Encrypt uses zlint and so I took some time today to submit a PR to > address this missing lint finding: https://github.com/zmap/zlint/pull/285 > Extra > eyes on that would be most welcome. > Thanks. I left some comments, and also spent some time digging into the signature algorithm encodings. Using an algorithm that undercounts (meaning if they got it right in the SPKI, but botched it in the signature, or vice-versa, I'm not counting it), I still only found 415 certificates. I sampled around 40 of these, and they were all revoked, and all fell into the class of RSA omitting the NULL. Note that this is applicable for signatureAlgorithms as well (and the same section of the RFC), and this is again something cablint picks up and zlint misses. However, it seems CAs happened to already have revoked these certificates - perhaps from internal linting efforts that looked at all their certificates, or crt.sh, or some other bit. It's also not too surprising, given that this is the logic that mozilla::pkix implements directly in its implementation. So I'm fairly confident that the increased expression in policy does not harm things, makes it easier to implement safe linters. Not to pick on Daniel, but it looks like the PR made for zlint missed some edge corner cases - perfectly understandable, in context, but exactly why/where the direct comparison makes it easier :) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Avast Antivirus enables the entire Microsoft PKI for Firefox
On Tue, May 21, 2019 at 1:23 PM Adrian R via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Wayne Thayer wrote: > > > > > > That is not my understanding of how this setting works: it only imports > > roots that have been added to the Windows root store, e.g. by a program > > such as Avast, or an administrator. It does not import roots Microsoft > > ships with Windows. > > > > The problem is that if a root certificate is revoked locally by: > - exporting it from any place in the windows certificate store, > - adding it to the Untrusted Certificates store > - keeping it untouched in the initial store where it was exported from ... > Firefox considers that certificate as valid when it should consider it as > revoked. > Windows considers such a certificate to be revoked. > > There is a big difference between importing the entire Windows root store and thus effectively overriding Mozilla's trust decisions, and importing roots added by an antivirus program, so I wanted to clarify that. The bug that you filed (thanks!) should address the revocation issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1553233 > > With Avast antivirus it's not possible to delete their MITM scanner > certificate because they will re-create another if i delete it, but they > allow it to be revoked and stay revoked. > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Avast Antivirus enables the entire Microsoft PKI for Firefox
Wayne Thayer wrote: > > > That is not my understanding of how this setting works: it only imports > roots that have been added to the Windows root store, e.g. by a program > such as Avast, or an administrator. It does not import roots Microsoft > ships with Windows. > The problem is that if a root certificate is revoked locally by: - exporting it from any place in the windows certificate store, - adding it to the Untrusted Certificates store - keeping it untouched in the initial store where it was exported from ... Firefox considers that certificate as valid when it should consider it as revoked. Windows considers such a certificate to be revoked. With Avast antivirus it's not possible to delete their MITM scanner certificate because they will re-create another if i delete it, but they allow it to be revoked and stay revoked. Adrian R. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Avast Antivirus enables the entire Microsoft PKI for Firefox
On Tue, May 21, 2019 at 12:59 PM Adrian R via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hello > > Today, as part of an "upgrade" to version 19.5 Avast Antivirus has > forcefully enabled the entire Microsoft PKI for all Firefox users that also > happen to be users of Avast [Free] Antivirus. > > They now forcefully set this Mozilla enterprise policy for all users of > Avast: > > HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Mozilla\Firefox\Certificates > "ImportEnterpriseRoots"=dword:0001 > > And this causes Mozilla Firefox to trust all the root certificates in the > Windows store... That is not my understanding of how this setting works: it only imports roots that have been added to the Windows root store, e.g. by a program such as Avast, or an administrator. It does not import roots Microsoft ships with Windows. > but with a bug: Firefox ignores the local revocation info for root > certificates and thus considers revoked root certificates as being valid. > > > Related Mozilla bugzilla bug id: 1553233 > > *sigh* > > > Adrian R. > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Avast Antivirus enables the entire Microsoft PKI for Firefox
Hello Today, as part of an "upgrade" to version 19.5 Avast Antivirus has forcefully enabled the entire Microsoft PKI for all Firefox users that also happen to be users of Avast [Free] Antivirus. They now forcefully set this Mozilla enterprise policy for all users of Avast: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Mozilla\Firefox\Certificates "ImportEnterpriseRoots"=dword:0001 And this causes Mozilla Firefox to trust all the root certificates in the Windows store... but with a bug: Firefox ignores the local revocation info for root certificates and thus considers revoked root certificates as being valid. Related Mozilla bugzilla bug id: 1553233 *sigh* Adrian R. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash Requirements
> > > Of the 8 unrevoked, they're all issued by a single CA - GlobalSign - and > are all RSA keys that lack the explicit NULL parameter, and thus violate > the requirements of https://tools.ietf.org/html/rfc3279#section-2.3.1 > These are flagged by cablint (but not zlint), so that is an opportunity for > CAs to improve things - both in how they encode and how they lint. Ryan: Thanks for flagging this difference between cablint and zlint. Let's Encrypt uses zlint and so I took some time today to submit a PR to address this missing lint finding: https://github.com/zmap/zlint/pull/285 Extra eyes on that would be most welcome. On Tue, May 21, 2019 at 6:06 AM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thu, May 9, 2019 at 4:48 PM Brian Smith wrote: > > > On Fri, Apr 26, 2019 at 11:39 AM Wayne Thayer > wrote: > > > >> On Wed, Apr 24, 2019 at 10:02 AM Ryan Sleevi wrote: > >> > >>> Thank you David and Ryan! This appears to me to be a reasonable > >>> improvement to our policy. > >>> > >> > >> Brian: could I ask you to review the proposed change? > >> > >> > >>> This does not, however, address the last part of what Brian proposes - > >>> which is examining if, how many, and which CAs would fail to meet these > >>> encoding requirements today, either in their roots, subordinates, or > leaf > >>> certificates. > >>> > >>> > >> While I agree that this would be useful information, for the purpose of > >> moving ahead with this policy change would it instead be reasonable to > set > >> an effective date and require certificates issued (notBefore) after that > >> date to comply, putting the burden on CAs to verify their > implementations > >> rather than relying on someone else to do that work? > >> > > > > My understanding here is that the proposed text is not imposing a new > > requirement, but more explicitly stating a requirement that is already > > imposed by the BRs. AFAICT BRs require syntactically valid X.509 > > certificates, RFC 5280 defines what's syntactically valid, RFC 5280 > defers > > to other documents about what is allowed for each algorithm identifier, > and > > this is an attempt to collect all those requirements into one spot for > > convenience. > > > > I unintentionally let this drop off my radar. > > I did some light analysis, based on analyzing simply the bytes of the cert > (i.e. without structural parsing), simply looking at whether or not one of > the prescribed sequences appears, first for SPKIs, then for signatures. > > For SPKIs, I only found a total of 9 unexpired certs, so I've just > reproduced them here: > - > > https://crt.sh/?c=ad567be233e98ac621e8b760005f37f1d7e916d73c602391771ab5f23f7af38b > - > > https://crt.sh/?c=b719593d1e625e45f42ab3d1537e0a9c7a33c0a87244e7000db61571bc0fd98b > - > > https://crt.sh/?c=541e29ce0aee8244a43b31e031208e6808a7e412d6c9cda6cd032d528ea0c690 > - > > https://crt.sh/?c=6101a94793441c3b85ac653703d62d5c65ca6457662b36ad7abd3ee43d5eec11 > - > > https://crt.sh/?c=ca304b895d0d652da1c352dbda577f7c70c5f6741758e17a919a97d063ad56c7 > - > > https://crt.sh/?c=91d876790b645196389d3c92a6b480969557192ecdd2bfeaaced6c07948d9d5c > - > > https://crt.sh/?c=96185e2fadc17a5b896338a3fcce3647b3b2f9221c61c9624814c4d37b884dbb > - > > https://crt.sh/?c=9a9ec285f834b421416e5e5ba45727deaf92adf37e76a82cdf6d45d0fba0728c > - (Revoked) > > https://crt.sh/?c=5cf9ff16c5d1e128a2082df9d290d1571c1a8f2f782bc1cacd2b0437094f0e13 > > Of the 8 unrevoked, they're all issued by a single CA - GlobalSign - and > are all RSA keys that lack the explicit NULL parameter, and thus violate > the requirements of https://tools.ietf.org/html/rfc3279#section-2.3.1 > > These are flagged by cablint (but not zlint), so that is an opportunity for > CAs to improve things - both in how they encode and how they lint. > > I haven't (yet) gone through the Signature encodings, but that should > hopefully address the SPKI concerns. Of course, I may have botched things > rather significantly in my queries, but at least sharing my data provides a > way for people to prove that :) > > > > > > It would be easier to understand if this is true if the proposed text > > cited the RFCs, like RFC 4055, that actually impose the requirements that > > result in the given encodings. > > > > Could you clarify, do you just mean adding references to each of the > example encodings (such as the above example, for the SPKI encoding)? > ___ > 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: Audit Reminder Email Summary
Forwarded Message Subject: Summary of May 2019 Audit Reminder Emails Date: Tue, 21 May 2019 19:01:45 + (GMT) Mozilla: Audit Reminder CA Owner: LuxTrust Root Certificates: LuxTrust Global Root 2 Standard Audit: https://www.lsti-certification.fr/images/LSTI--11085-57-AL-V1.0_LUXTRUST.pdf Standard Audit Period End Date: 2018-03-30 BR Audit: https://www.lsti-certification.fr/images/LSTI--11085-57-AL-V1.0_LUXTRUST.pdf BR Audit Period End Date: 2018-03-30 EV Audit: https://www.lsti-certification.fr/images/LSTI--11085-57-AL-V1.0_LUXTRUST.pdf EV Audit Period End Date: 2018-03-30 CA Comments: null Mozilla: Audit Reminder CA Owner: Autoridad de Certificacion Firmaprofesional Root Certificates: Autoridad de Certificacion Firmaprofesional CIF A62634068 Standard Audit: https://bug1412950.bmoattachments.org/attachment.cgi?id=9018966 Standard Audit Period End Date: 2018-03-27 BR Audit: https://bug1412950.bmoattachments.org/attachment.cgi?id=9018971 BR Audit Period End Date: 2018-03-27 EV Audit: https://bug1412950.bmoattachments.org/attachment.cgi?id=9018971 EV Audit Period End Date: 2018-03-27 CA Comments: null Mozilla: Audit Reminder CA Owner: AC Camerfirma, S.A. Root Certificates: Chambers of Commerce Root Chambers of Commerce Root - 2008 Global Chambersign Root Global Chambersign Root - 2008 Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8995928 Standard Audit Period End Date: 2018-04-13 BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8995930 BR Audit Period End Date: 2018-04-13 EV Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8995931 EV Audit Period End Date: 2018-04-13 CA Comments: null Mozilla: Overdue Audit Statements CA Owner: certSIGN Root Certificates: certSIGN ROOT CA** ** Audit Case in the Common CA Database is under review for this root certificate. Standard Audit: https://www.certsign.ro/certsign/files/certSIGN-Webtrust-CA-Report-2018.pdf Standard Audit Period End Date: 2018-02-08 BR Audit: https://www.certsign.ro/certsign/files/certSIGN-Webtrust-CA-SSL-Report-2018.pdf BR Audit Period End Date: 2018-02-08 CA Comments: The audit statements are reviewed and fine, just waiting for the Webtrust Seals to be provided. Mozilla: Audit Reminder CA Owner: Sectigo Root Certificates: COMODO RSA Certification Authority USERTrust ECC Certification Authority AAA Certificate Services AddTrust Class 1 CA Root AddTrust External CA Root COMODO Certification Authority COMODO ECC Certification Authority UTN-USERFirst-Client Authentication and Email USERTrust RSA Certification Authority Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8989406 Standard Audit Period End Date: 2018-03-31 BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8989407 BR Audit Period End Date: 2018-03-31 BR Audit: BR Audit Period End Date: EV Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8989408 EV Audit Period End Date: 2018-03-31 CA Comments: null Mozilla: Audit Reminder CA Owner: Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert) Root Certificates: EC-ACC Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=9013271 Standard Audit Period End Date: 2018-03-28 BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=9013273 BR Audit Period End Date: 2018-03-28 CA Comments: null Mozilla: Audit Reminder CA Owner: Cybertrust Japan / JCSI Root Certificates: SecureSign RootCA11 Standard Audit: http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221213 Standard Audit Period End Date: 2018-02-28 BR Audit: http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221212 BR Audit Period End Date: 2018-02-28 CA Comments: null Mozilla: Audit Reminder CA Owner: DigiCert Root Certificates: Baltimore CyberTrust Root Cybertrust Global Root DigiCert Assured ID Root CA DigiCert Assured ID Root G2 DigiCert Assured ID Root G3 DigiCert Trusted Root G4 Standard Audit: http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221124 Standard Audit Period End Date: 2018-03-31 BR Audit: http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221125 BR Audit Period End Date: 2018-03-31 EV Audit: http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221126 EV Audit Period End Date: 2018-03-31 CA Comments: null Mozilla: Audit Reminder CA Owner: Entrust Root Certificates: Entrust Root Certification Authority - EC1 Entrust Root Certification Authority - G2 AffirmTrust Commercial AffirmTrust Networking AffirmTrust Premium AffirmTrust Premium ECC Entrust Root Certification Authority Entrust.net Certification Authority (2048) Standard Audit: https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/entrust_wforca_2018.pdf Standard Audit Period End
Re: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash Requirements
On Thu, May 9, 2019 at 4:48 PM Brian Smith wrote: > On Fri, Apr 26, 2019 at 11:39 AM Wayne Thayer wrote: > >> On Wed, Apr 24, 2019 at 10:02 AM Ryan Sleevi wrote: >> >>> Thank you David and Ryan! This appears to me to be a reasonable >>> improvement to our policy. >>> >> >> Brian: could I ask you to review the proposed change? >> >> >>> This does not, however, address the last part of what Brian proposes - >>> which is examining if, how many, and which CAs would fail to meet these >>> encoding requirements today, either in their roots, subordinates, or leaf >>> certificates. >>> >>> >> While I agree that this would be useful information, for the purpose of >> moving ahead with this policy change would it instead be reasonable to set >> an effective date and require certificates issued (notBefore) after that >> date to comply, putting the burden on CAs to verify their implementations >> rather than relying on someone else to do that work? >> > > My understanding here is that the proposed text is not imposing a new > requirement, but more explicitly stating a requirement that is already > imposed by the BRs. AFAICT BRs require syntactically valid X.509 > certificates, RFC 5280 defines what's syntactically valid, RFC 5280 defers > to other documents about what is allowed for each algorithm identifier, and > this is an attempt to collect all those requirements into one spot for > convenience. > I unintentionally let this drop off my radar. I did some light analysis, based on analyzing simply the bytes of the cert (i.e. without structural parsing), simply looking at whether or not one of the prescribed sequences appears, first for SPKIs, then for signatures. For SPKIs, I only found a total of 9 unexpired certs, so I've just reproduced them here: - https://crt.sh/?c=ad567be233e98ac621e8b760005f37f1d7e916d73c602391771ab5f23f7af38b - https://crt.sh/?c=b719593d1e625e45f42ab3d1537e0a9c7a33c0a87244e7000db61571bc0fd98b - https://crt.sh/?c=541e29ce0aee8244a43b31e031208e6808a7e412d6c9cda6cd032d528ea0c690 - https://crt.sh/?c=6101a94793441c3b85ac653703d62d5c65ca6457662b36ad7abd3ee43d5eec11 - https://crt.sh/?c=ca304b895d0d652da1c352dbda577f7c70c5f6741758e17a919a97d063ad56c7 - https://crt.sh/?c=91d876790b645196389d3c92a6b480969557192ecdd2bfeaaced6c07948d9d5c - https://crt.sh/?c=96185e2fadc17a5b896338a3fcce3647b3b2f9221c61c9624814c4d37b884dbb - https://crt.sh/?c=9a9ec285f834b421416e5e5ba45727deaf92adf37e76a82cdf6d45d0fba0728c - (Revoked) https://crt.sh/?c=5cf9ff16c5d1e128a2082df9d290d1571c1a8f2f782bc1cacd2b0437094f0e13 Of the 8 unrevoked, they're all issued by a single CA - GlobalSign - and are all RSA keys that lack the explicit NULL parameter, and thus violate the requirements of https://tools.ietf.org/html/rfc3279#section-2.3.1 These are flagged by cablint (but not zlint), so that is an opportunity for CAs to improve things - both in how they encode and how they lint. I haven't (yet) gone through the Signature encodings, but that should hopefully address the SPKI concerns. Of course, I may have botched things rather significantly in my queries, but at least sharing my data provides a way for people to prove that :) > > It would be easier to understand if this is true if the proposed text > cited the RFCs, like RFC 4055, that actually impose the requirements that > result in the given encodings. > Could you clarify, do you just mean adding references to each of the example encodings (such as the above example, for the SPKI encoding)? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
