Re: Apple: Patch Management

2019-12-06 Thread Apple CA via dev-security-policy
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 
dev-security-policy mailing list

Re: Policy 2.7 Proposal: Update Minimum Versions of Audit Criteria

2019-12-06 Thread Wayne Thayer via dev-security-policy
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


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]
> [2]
> 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
>> (I also update the links in a later commit)
>> This is
>> 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