> It's been an on-going question for me, since the use case (as a software
> developer) is quite real: if you serve a site over HTTPS and it needs to
> communicate with a local client application then you need this (or, you
> need to manage your own CA, and ask every person to install a
> certifica
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
> instanc
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
Mozil
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 code
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 the
> 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 opt
[CC'ing rev...@digicert.com, as per
https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o03WrzBC&QuestionId=Q00028]
Annie,
"but these have been known about and deemed acceptable for years"
Known about by whom? Deemed acceptable by whom?
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 if
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:
https://www.mydqs.com/kunden/kundendatenbank.html?aoemydqs%5BrequestId%5D=europev
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
> >> dev-security-policy wrote:
> >> > If you
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,
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
https://github.com/
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 19, 2017 at 7:37:23 PM UTC-4, Matt Palm
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 08:17:07AM -0700, troy.fridley--- via
> >> d
> 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 find such an issue again in a Cisco owne
-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 q
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 in a Cisco owned domain, please
>> > re
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 a
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
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
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 som
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 st
22 matches
Mail list logo