Re: Apple OCSP responders return responses with incorrect issuer

2019-10-17 Thread Apple CA via dev-security-policy
On October 17, Apple submitted an incident report: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1588001#c3, which is reposted 
below. 

Incident Report

1. How your CA first became aware of the problem (e.g. via a problem report 
submitted to your Problem Reporting Mechanism, a discussion in 
mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the 
time and date.

On 03-October-2019 at 13:51 PT, we were notified via a problem report submitted 
to our Problem Reporting Mechanism that our OCSP responders were returning 
signed responses with incorrect issuer. 

2. A timeline of the actions your CA took in response. A timeline is a 
date-and-time-stamped sequence of all relevant events. This may include events 
before the incident was reported, such as when a particular requirement became 
applicable, or a document changed, or a bug was introduced, or an audit was 
done.

03-October-2019 at 13:51 PT - We were notified via a problem report submitted 
to our Problem Reporting Mechanism that our OCSP responders were returning 
signed responses with incorrect issuer.

03-October-2019 at 13:52 PT - The compliance team read the problem report and 
began pulling the appropriate people together to begin the investigation.

03-October-2019 at 14:15 PT - Investigation began to confirm the reported 
behavior. 

03-October-2019 at 16:15 PT -  Based on an initial investigation, we determined 
that in some cases when the OCSP service receives a request it can’t process, 
it returns a status of unknown signed with a default OCSP responder, which is 
not always signed by the CA that issued the certificate whose revocation status 
is being checked.

03-October-2019 at 19:21 - Notified DigiCert (Root vendor).

03-October-2019 at 20:10 - We responded to the reporter with an initial 
acknowledgement and a commitment to investigate further and respond with more 
details within 24 hours of the report being submitted.

04-October-2019 at 10:10 PT - Notified Sectigo (Root vendor).

04-October-2019 at 11:26 PT - Notified Ernst & Young (WebTrust assessors).

04-October-2019 at 13:48 PT - We provided a preliminary report on our findings 
to the individual who filed the problem report.

07-October-2019 at 14:15 PT - We began rolling out a fix to our OCSP service. 
The fix was to disable the default OCSP responder so that the responses are 
always signed by the CA that issued the certificate whose revocation status is 
being checked. Disabling the default OCSP responder ensures that the responder 
will reply ‘unauthorized’  (as per RFC 6960) for all unknown issuers. The 
issuer may be unknown if the OCSP service cannot identify the issuer, such as 
when an OCSP client uses a hash algorithm for CertID that the OCSP service does 
not support or when the request indicates an unrecognized issuer that is not 
served by our OCSP service.

10-October-2019 at 19:38 PT  - Posted initial incident report to Bugzilla.

17-October-2019 - The fix has been pushed out to the majority of our production 
OCSP service and scheduled for completion by 18-October-2019.

3. Whether your CA has stopped, or has not yet stopped, issuing certificates 
with the problem. A statement that you have will be considered a pledge to the 
community; a statement that you have not requires an explanation.

No non-compliant certificates were issued. The OCSP fix has been pushed out to 
the majority of our production OCSP service and scheduled for completion by 
18-October-2019.

4. A summary of the problematic certificates. For each problem: number of 
certs, and the date the first and last certs with that problem were issued.

No non-compliant certificates were issued.

5. The complete certificate data for the problematic certificates. The 
recommended way to provide this is to ensure each certificate is logged to CT 
and then list the fingerprints or crt.sh IDs, either in the report or as an 
attached spreadsheet, with one list per distinct problem.

No non-compliant certificates were issued.

6. Explanation about how and why the mistakes were made or bugs introduced, and 
how they avoided detection until now.

When the OCSP service was first set up in 2012, the OCSP service software did 
not allow the default OCSP responder to be disabled. We began issuing publicly 
trusted TLS certificates in 2014 and the default OCSP responder was not 
disabled. We did not identify this as an issue because our test cases did not 
address scenarios in which our OCSP service could not identify the issuer and 
thus signs the response with the default OCSP responder.

The default OCSP responder is only used when the OCSP service cannot identify 
the issuer. This may occur when an OCSP client uses a hash algorithm for CertID 
that the OCSP service does not support or when the request indicates an 
unrecognized issuer that is not served by our OCSP service. 

We were aware of section 4.9.9 of the Baseline Requirements that states that 
OCSP responses must “Be signed by 

Re: Germany's cyber-security agency [BSI] recommends Firefox as most secure browser

2019-10-17 Thread Jonathan Rudenberg via dev-security-policy
Hi Kirk,

On Thu, Oct 17, 2019, at 19:53, Kirk Hall via dev-security-policy wrote:
> I hope the Mozilla community will celebrate this honor, but will also 
> reconsider its proposal to drop support for EV certificates – that 
> would mean that Firefox no longer meets all BSI requirements for a 
> secure browser.

I'm not sure where you're getting this information, there has been no proposal 
to drop support for EV certificates. Can you point me to your source for this?

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Entrust Root Certification Authority - G4 Inclusion Request

2019-10-17 Thread Wayne Thayer via dev-security-policy
Having received no further comments, I have recommended approval of this
request in bug 1480510.

- Wayne

On Tue, Oct 8, 2019 at 4:23 PM Wayne Thayer  wrote:

> On Mon, Oct 7, 2019 at 9:09 AM Bruce via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On Monday, July 29, 2019 at 5:22:19 PM UTC-4, Bruce wrote:
>>
>> > We will update section 4.2 and 9.12.3 in the next release of the CPS.
>>
>> The CPS Has been updated to address the above issues, see
>> https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/ssl-cps-english-20190930-version-36.pdf
>> .
>>
>> I've verified these updates.
>
> This request has been in discussion for quite a while now. Please post any
> further comments by next Tuesday 15-October, and I will plan to end the
> discussion period at that time.
>
> - Wayne
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Germany's cyber-security agency [BSI] recommends Firefox as most secure browser

2019-10-17 Thread Kirk Hall via dev-security-policy
Congratulations to Mozilla and its Firefox team! Here is a ZDNet article [1] 
from today: 

“Germany's cyber-security agency [BSI] recommends Firefox as most secure 
browser”
“Germany's BSI tested Firefox, Chrome, IE, and Edge. Firefox was only browser 
to pass all minimum requirements for mandatory security features”

BSI (translated as the Federal Office for Information Security) is “the German 
upper-level federal agency in charge of managing computer and communication 
security for the German government. Its areas of expertise and responsibility 
include the security of computer applications, critical infrastructure 
protection, Internet security, cryptography, counter eavesdropping, 
certification of security products and the accreditation of security test 
laboratories.” [2]  

BSI found that Firefox is the *only* browser to support *all* of the BSI 
requirements for a secure browser.  Here is what the ZDNet article says about 
EV certificates:

According to the BSI's new guide, to be considered "secure," a modern browser 
must satisfy these minimum requirements: ***

- *Must support extended validation (EV) certificates*

Here is what Sec. 2.1b) of the full BSI report says:  

The web browser MUST meet the following requirements for certificates and their 
verification:
— A list of certificates of trusted certificate issuers (CA Certificates) MUST 
be provided.
— Certificates with domain-based validation (Domain Validated-Zertrifikate, 
DV), with Organization-based validation (Organizational-Validated-Zertifikate, 
OV) and certificates with Extended Validation Certificates MUST be supported.

I hope the Mozilla community will celebrate this honor, but will also 
reconsider its proposal to drop support for EV certificates – that would mean 
that Firefox no longer meets all BSI requirements for a secure browser.

[1] 
https://www.zdnet.com/article/germanys-cyber-security-agency-recommends-firefox-as-most-secure-browser/
 
[2] https://en.wikipedia.org/wiki/Federal_Office_for_Information_Security
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy