Re: potential audit delay due to issue with CPA Canada
If you have the letters from your auditor, you can upload them as an attachment to a Bugzilla bug, then submit the links in your CCADB audit case. It's preferable to be able to verify the audit letters via the seal on the WebTrust site, but Mozilla doesn't require it - we can contact the auditor directly for confirmation. - Wayne On Mon, Feb 26, 2018 at 8:29 PM, josh--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Monday, February 26, 2018 at 8:30:54 PM UTC-6, jo...@letsencrypt.org > wrote: > > We (ISRG / Let's Encrypt) have completed our 2017 WebTrust audits, the > letters are written and signed, but CPA Canada is unable to process our > final seals due to a personnel issue on their end. Nobody who can sign off > is available, and apparently it could take another 2+ weeks for them to > resolve the issue, which could bring us close to the deadline. > > > > What would the root programs like us to do if CPA Canada is not able to > perform in the required amount of time? I expect in the worst case the > seals would be less than a month late. > > > > -Josh Aas > > It has been pointed out to me that Section 8.6 of the BRs says: > > "In the event of a delay greater than three months, and if so requested by > an Application Software Supplier, the CA SHALL provide an explanatory > letter signed by the Qualified Auditor." > > That being the case, we will provide the explanatory letter if one is > requested. > ___ > 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
potential audit delay due to issue with CPA Canada
We (ISRG / Let's Encrypt) have completed our 2017 WebTrust audits, the letters are written and signed, but CPA Canada is unable to process our final seals due to a personnel issue on their end. Nobody who can sign off is available, and apparently it could take another 2+ weeks for them to resolve the issue, which could bring us close to the deadline. What would the root programs like us to do if CPA Canada is not able to perform in the required amount of time? I expect in the worst case the seals would be less than a month late. -Josh Aas ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Code signing and malware
On Tue, Feb 27, 2018 at 12:09:01AM +0100, Jakob Bohm via dev-security-policy wrote: > > Hence why an investigation is needed by the 3 CAs named in the paper > (Comodo, Digicert and Apple). They will probably have to do some deep > log inspection to figure out patterns, besides reaching out to the > researcher to see the raw data in confidence. I've just tried to contact the author and hope to provide the CAs with details. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Code signing and malware
On 26/02/2018 21:28, Ryan Sleevi wrote: On Mon, Feb 26, 2018 at 3:05 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On Mon, Feb 26, 2018 at 12:23 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 26/02/2018 10:27, Kurt Roeckx wrote: I just came across this: https://www.recordedfuture.com/code-signing-certificates/ I think the most important part of it is: "we confirmed with a high degree of certainty that the certificates are created for a specific buyer per request only and are registered using stolen corporate identities" I believe the claims there require investigation by the named CAs (Comodo and Digicert (Symantec) brands) and an appropriate incident report regarding the claimed misissuances. While I agree in theory, I don't think sufficient information has been provided to allow a CA to investigate. These are (allegedly) genuine misissuances to entities other than the identities named in the certificates, rather than technical "misissuances" in violation of formal technical requirements. These also appear to be systematic, as the alleged black market vendors claim to obtain such misissued certificates on demand. If the claims in that article are true, one or more vetting procedures obviously fall short of their required effectiveness. This may or may not be in accordance with BR and CPS minimum procedures, but it is obviously an ongoing and true danger to the relying parties at large. These claims haven't been substantiated, but with multiple CAs allegedly vulnerable, this appears to be a weakness in the EV Guidelines. I'm not sure we have sufficient information to evaluate that. The article apparently conflates EV SSL with EV CodeSigning, the latter of which is vastly different in nature and requirements than the former (and with the former being relevant to scope of the Forum's activities) The original document (linked to in the OP) states that *both* were being offered by these black market operators. Further, it does not distinguish between the potential to obtain correctly-validated certificates due to compromised infrastructure, or the pre-existing set of certificates due to compromised keys or issuance credentials. The document emphasizes that the black market sellers made claims that would be most consistent with getting new certificates on demand, but the researcher did not buy a full certificate to be inspected, and didn't publish the (public) part of the certificate he convinced the seller to demonstrate control of. It's these ambiguities that allow no reasonable conclusion to be made Hence why an investigation is needed by the 3 CAs named in the paper (Comodo, Digicert and Apple). They will probably have to do some deep log inspection to figure out patterns, besides reaching out to the researcher to see the raw data in confidence. 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
Re: Code signing and malware
On Mon, Feb 26, 2018 at 3:05 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Mon, Feb 26, 2018 at 12:23 PM, Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On 26/02/2018 10:27, Kurt Roeckx wrote: > > > >> I just came across this: > >> > >> https://www.recordedfuture.com/code-signing-certificates/ > >> > >> I think the most important part of it is: "we confirmed with a high > >> degree of certainty that the certificates are created for a specific > buyer > >> per request only and are registered using stolen corporate identities" > >> > >> > > I believe the claims there require investigation by the named CAs > > (Comodo and Digicert (Symantec) brands) and an appropriate incident > > report regarding the claimed misissuances. > > > > While I agree in theory, I don't think sufficient information has been > provided to allow a CA to investigate. > > These are (allegedly) genuine misissuances to entities other than > > the identities named in the certificates, rather than technical > > "misissuances" in violation of formal technical requirements. > > > > These also appear to be systematic, as the alleged black market > > vendors claim to obtain such misissued certificates on demand. > > > > If the claims in that article are true, one or more vetting > > procedures obviously fall short of their required effectiveness. > > This may or may not be in accordance with BR and CPS minimum > > procedures, but it is obviously an ongoing and true danger to the > > relying parties at large. > > > > > These claims haven't been substantiated, but with multiple CAs allegedly > vulnerable, this appears to be a weakness in the EV Guidelines. > I'm not sure we have sufficient information to evaluate that. The article apparently conflates EV SSL with EV CodeSigning, the latter of which is vastly different in nature and requirements than the former (and with the former being relevant to scope of the Forum's activities) Further, it does not distinguish between the potential to obtain correctly-validated certificates due to compromised infrastructure, or the pre-existing set of certificates due to compromised keys or issuance credentials. It's these ambiguities that allow no reasonable conclusion to be made ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Code signing and malware
On Mon, Feb 26, 2018 at 2:23 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 26/02/2018 10:27, Kurt Roeckx wrote: > >> I just came across this: >> >> https://www.recordedfuture.com/code-signing-certificates/ >> >> I think the most important part of it is: "we confirmed with a high >> degree of certainty that the certificates are created for a specific buyer >> per request only and are registered using stolen corporate identities" >> >> > I believe the claims there require investigation by the named CAs > (Comodo and Digicert (Symantec) brands) and an appropriate incident > report regarding the claimed misissuances. > I do not believe there is sufficient evidence to justify this, and am hesitant to begin such investigations without more meaningful information. > These are (allegedly) genuine misissuances to entities other than > the identities named in the certificates, rather than technical > "misissuances" in violation of formal technical requirements. > There are also a number of technical inconsistencies within the report (rather than the primary material) that lead to such claims being reinterpreted and potentially incorrect. > While the Mozilla root store only cares about the EV SSL subset of > these misissuances, the EV codesign misissuances may involve failure > of procedures also used for Mozilla-trusted uses (SSL and S/MIME), > and thus should be included in incident reports. > I disagree with this as well. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Code signing and malware
On 26/02/2018 10:27, Kurt Roeckx wrote: I just came across this: https://www.recordedfuture.com/code-signing-certificates/ I think the most important part of it is: "we confirmed with a high degree of certainty that the certificates are created for a specific buyer per request only and are registered using stolen corporate identities" I believe the claims there require investigation by the named CAs (Comodo and Digicert (Symantec) brands) and an appropriate incident report regarding the claimed misissuances. These are (allegedly) genuine misissuances to entities other than the identities named in the certificates, rather than technical "misissuances" in violation of formal technical requirements. These also appear to be systematic, as the alleged black market vendors claim to obtain such misissued certificates on demand. If the claims in that article are true, one or more vetting procedures obviously fall short of their required effectiveness. This may or may not be in accordance with BR and CPS minimum procedures, but it is obviously an ongoing and true danger to the relying parties at large. While the Mozilla root store only cares about the EV SSL subset of these misissuances, the EV codesign misissuances may involve failure of procedures also used for Mozilla-trusted uses (SSL and S/MIME), and thus should be included in incident reports. The claims of misissuance for EV codesign certificates (only indirectly relevant to Mozilla) are highly likely to be true, as EV codesign is only available for SmartCard/HSM/USBToken stored private keys, making theft of properly issued certificates near impossible. 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
Re: Code signing and malware
The article also claims that bad actors are selling EV SSL certificates that they obtain for real companies without their knowledge: "to guarantee the issuance and lifespan of the products, all certificates are registered using the information of real corporations. With a high degree of confidence, we believe that the legitimate business owners are unaware that their data was used in the illicit activities. It is important to note that all certificates are created for each buyer individually with the average delivery time of two to four days." Wayne On Mon, Feb 26, 2018 at 2:27 AM, Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I just came across this: > > https://www.recordedfuture.com/code-signing-certificates/ > > I think the most important part of it is: "we confirmed with a high degree > of certainty that the certificates are created for a specific buyer per > request only and are registered using stolen corporate identities" > > > Kurt > ___ > 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
Code signing and malware
I just came across this: https://www.recordedfuture.com/code-signing-certificates/ I think the most important part of it is: "we confirmed with a high degree of certainty that the certificates are created for a specific buyer per request only and are registered using stolen corporate identities" Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
