Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

On Tuesday, June 20, 2017 at 2:15:57 PM UTC-5, annie nguyen wrote: > Dropbox, GitHub, Spotify and Discord (among others) have done the same > thing for years: they embed SSL certificates and private keys into their > applications so that, for example, open.spotify.com can talk to a local >

Re: Symantec response to Google proposal

On 20/06/2017 08:08, Gervase Markham wrote: On 20/06/17 01:21, Jakob Bohm wrote: 2. For any certificate bundle that needs to be incorporated into the Mozilla root stores, a significant period (3 to 6 months at least) will be needed between acceptance by Mozilla and actual trust by

Re: [EXT] Mozilla requirements of Symantec

On 20/06/2017 09:05, Ryan Sleevi wrote: On Mon, Jun 19, 2017 at 7:01 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: NSS until fairly recently was in fact used for code signing of Firefox extensions using the public PKI (this is why there is a defunct

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

For your information: I have reported this issue to Spotify on Monday (yesterday) through their official vulnerability disclosure channel (HackerOne). The (not-yet-public) issue was assigned ID 241222. In the report I have included all the necessary (technical) details, including citations of

Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable

> Moral of the story, if you have to ask if it's a disclosure, you are better > safe than sorry and keeping the info under close wraps until you confirm it. I think it's better it was disclosed than had it not been disclosed at all. While I agree to an extent that there could have been more

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

[CC'ing rev...@digicert.com, as per https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o03WrzBC=Q00028] Annie, "but these have been known about and deemed acceptable for years" Known about by whom? Deemed acceptable by whom? Until

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

Previous certificates for GitHub and Dropbox have been revoked for this reason. If this problem has been reintroduced, they similarly need to be revoked. On Tue, Jun 20, 2017 at 4:57 PM annie nguyen via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi! > > I'm not sure

Re: Audit Reminder Email Summary

Forwarded Message Subject: Summary of June 2017 Audit Reminder Emails Date: Tue, 20 Jun 2017 19:00:06 + (GMT) Mozilla: Audit Reminder Root Certificates: Atos TrustedRoot 2011 Standard Audit:

Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable

On Tuesday, June 20, 2017 at 12:52:02 PM UTC-4, Lee wrote: > On 6/20/17, mfisch--- via dev-security-policy > wrote: > > On Monday, June 19, 2017 at 7:37:23 PM UTC-4, Matt Palmer wrote: > >> On Sun, Jun 18, 2017 at 08:17:07AM -0700, troy.fridley--- via > >>

When are public applications embedding certificates pointing to 127.0.0.1 OK?

Hi! I'm not sure if this is the correct place to ask (I'm not sure where else I would ask). I'm so sorry if this message is unwanted. Earlier this week, a certificate for a domain resolving to 127.0.0.1 in a Cisco application was revoked, because it was deemed to have been compromised. Dropbox,

Re: Root Store Policy 2.5: Call For Review and Phase-In Periods

Hi Doug, On 20/06/17 16:31, Doug Beattie wrote: > I'd like to recommend a phase in of the requirement for technically > constrained CAs that issue Secure email certificates. For those following along at home, that is this change: https://github.com/mozilla/pkipolicy/issues/69

Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable

On Tuesday, June 20, 2017 at 2:27:10 PM UTC-4, mfi...@fortmesa.com wrote: > On Tuesday, June 20, 2017 at 2:06:00 PM UTC-4, Jonathan Rudenberg wrote: > > > On Jun 20, 2017, at 10:36, mfisch--- via dev-security-policy > > > wrote: > > > > > > On Monday, June

Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable

On Tuesday, June 20, 2017 at 2:06:00 PM UTC-4, Jonathan Rudenberg wrote: > > On Jun 20, 2017, at 10:36, mfisch--- via dev-security-policy > > wrote: > > > > On Monday, June 19, 2017 at 7:37:23 PM UTC-4, Matt Palmer wrote: > >> On Sun, Jun 18, 2017 at

Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable

> On Jun 20, 2017, at 10:36, mfisch--- via dev-security-policy > wrote: > > On Monday, June 19, 2017 at 7:37:23 PM UTC-4, Matt Palmer wrote: >> On Sun, Jun 18, 2017 at 08:17:07AM -0700, troy.fridley--- via >> dev-security-policy wrote: >>> If you should

Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nick, I misspoke in my reply. The certificate has been revoked and it has not been re-issued. We have filed a post-stopping defect (Cisco Bug ID CSCve90409) against the product to ensure that the issue is not re-introduced. The certificate in

Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable

On 6/20/17, mfisch--- via dev-security-policy wrote: > On Monday, June 19, 2017 at 7:37:23 PM UTC-4, Matt Palmer wrote: >> On Sun, Jun 18, 2017 at 08:17:07AM -0700, troy.fridley--- via >> dev-security-policy wrote: >> > If you should find such an issue again

Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable

On Monday, June 19, 2017 at 7:37:23 PM UTC-4, Matt Palmer wrote: > On Sun, Jun 18, 2017 at 08:17:07AM -0700, troy.fridley--- via > dev-security-policy wrote: > > If you should find such an issue again in a Cisco owned domain, please > > report it to ps...@cisco.com and we will ensure that prompt

RE: Root Store Policy 2.5: Call For Review and Phase-In Periods

H Gerv, I'd like to recommend a phase in of the requirement for technically constrained CAs that issue Secure email certificates. We have 2 customers that can issue Secure Email certificates that are not technically constrained with name Constraints (the EKU is constrained to Secure Email and

Re: ETSI auditors still not performing full annual audits?

Thanks, Kathleen, for raising these issues. At a high level, this highlights an interesting concern. If we, as the broader community, lack the expertise to appropriate review and consume the audit reports as intended, it may signal a question about whether or not we should consider consuming ETSI

Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable

On Tuesday, 20 June 2017 05:50:06 UTC+1, Matthew Hardeman wrote: > The right balance is probably revoking when misuse is shown. Plus education. Robin has stated that there _are_ suitable CA products for this use case in existence today, but if I didn't know it stands to reason that at least

Re: [EXT] Mozilla requirements of Symantec

On Mon, Jun 19, 2017 at 7:01 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > NSS until fairly recently was in fact used for code signing of Firefox > extensions using the public PKI (this is why there is a defunct code > signing trust bit in the NSS root

Re: Symantec response to Google proposal

On 20/06/17 01:21, Jakob Bohm wrote: > 2. For any certificate bundle that needs to be incorporated into the > Mozilla root stores, a significant period (3 to 6 months at least) > will be needed between acceptance by Mozilla and actual trust by > Mozilla users. Not if the roots were