Re: Apple: Patch Management
On Monday, November 25, 2019 at 5:32:12 PM UTC-8, Apple CA wrote: > On Saturday, November 23, 2019 at 3:28:10 PM UTC-8, Matt Palmer wrote: > > [aside: this is how incident reports should be done, IMHO] > > > > On Fri, Nov 22, 2019 at 07:23:27PM -0800, Apple CA via dev-security-policy > > wrote: > > > We did not have an accurate understanding of how the vulnerability scanner > > > worked. Our understanding of its capabilities lead us to believe it was > > > scanning and detecting vulnerabilities in EJBCA. > > > > There's a reasonable chance that other CAs may have a similar situation, so > > I think it's worth digging deeper into the root causes here. Can you expand > > on how this misunderstanding regarding the vulnerability scanner came to > > pass? What was the information on which you were relying when you came to > > the understanding of the vulnerability scanner's capabilities? Were you > > misled by the vendor marketing or technical documentation, or was it an > > Apple-internal assessment that came to an inaccurate conclution? Or > > "other"? > > > > - Matt > > Thank you for your questions. Due to the Thanksgiving holiday in the US, we > expect to reply to your questions as early as the week of 02 December. In order to identify vulnerabilities, the vulnerability scanner (1) attempts to identify/profile software listening on ports and (2) compares software versions against public CVEs and proprietary data sources. EJBCA is not broadly used software, and the vulnerability scanner did not have custom EJBCA detection logic. Upon our deeper investigation, we discovered that it (1) only scans the HTTP service and not the EJBCA software, which we would consider insufficient on its own and (2) is not as effective at flagging vulnerabilities in EJBCA because CVEs are not published by EJBCA. We don’t feel we were mislead by the vendor. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: Update Minimum Versions of Audit Criteria
A concern [1] was raised about the required version of WebTrust audit criteria. After discussing with the WebTrust folks, I have changed the minimum requirement to the previous WebTrust versions instead of the current versions [2]. - Wayne [1] https://github.com/mozilla/pkipolicy/issues/197 [2] https://github.com/mozilla/pkipolicy/commit/9c25ef32d43843597864d3fbb4d9f231feb07f95 On Mon, Nov 25, 2019 at 11:39 AM Wayne Thayer wrote: > I've given the new version [1] another review, updated a few links, and > set the effective date to 1-January 2020. > > Unless there are new comments on this or any of the other changes [2], I > will have the new version published in the next few weeks. I'll also be > preparing a CA Communication to announce the new policy and specific > compliance dates. > > - Wayne > > [1] https://github.com/mozilla/pkipolicy/blob/2.7/rootstore/policy.md > [2] https://github.com/mozilla/pkipolicy/compare/master...2.7?diff=split > > On Wed, Nov 20, 2019 at 3:21 PM Wayne Thayer wrote: > >> The last change I am proposing for version 2.7 of the Mozilla Root Store >> policy is an update to the minimum versions of audit criteria that we will >> accept in audits. I have conferred with the WebTrust Task Force and was >> informed that we can update the minimum version requirements for audit >> statements received after December 2019 as follows: >> >> WebTrust for CA – instead of v2.0 use v2.2 >> WebTrust for BL+NSR – instead of v2.2 use v2.4.1 >> WebTrust for EVSSL – instead of v1.6.0 use v1.6.8 >> >> I asked the same question to ETSI representatives and was told that the >> following changes are appropriate: >> >> ETSI EN 319 411-1 - instead of v1.1.1 use v1.2.2 >> ETSI EN 319 411-2 - instead of v2.1.1 use v2.2.2 >> >> I have made these changes at >> https://github.com/mozilla/pkipolicy/commit/f605b39ccd9d1000ecebbfc028ab99aafae73d33 >> (I also update the links in a later commit) >> >> This is https://github.com/mozilla/pkipolicy/issues/197 >> >> I will greatly appreciate everyone's feedback - especially from any CAs >> or auditors for which these changes may cause problems. >> >> - Wayne >> > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
