On 13.03.2018 15:59, Peter Bowen wrote:
>>
>> Which companies, other than Apple and Google, benefit from DigiCert
>> running the Manager Partner Infrastructure and from DigiCert being part
>> of the exclusion list?
>
> An unlimited set. Any company who purchases a certificate from
> DigiCert
On 13.03.2018 15:35, Ryan Sleevi via dev-security-policy wrote:
>
>> Are the DigiCert transition CAs, which are part of the exclusion list,
>> and which you say are used for "Managed Partner Infrastructure",
>> strictly limited to support the needs of the Apple and Google companies?
>
>
> No.
On 12.03.2018 22:19, Kathleen Wilson via dev-security-policy wrote:
> Wayne and I have posted a Mozilla Security Blog regarding the current
> plan for distrusting the Symantec TLS certs.
>
> https://blog.mozilla.org/security/2018/03/12/distrust-symantec-tls-certificates/
Hello Kathleen and
On 12.03.2018 22:19, Kathleen Wilson via dev-security-policy wrote:
> Wayne and I have posted a Mozilla Security Blog regarding the current
> plan for distrusting the Symantec TLS certs.
>
> https://blog.mozilla.org/security/2018/03/12/distrust-symantec-tls-certificates/
Hello Kathleen and
On 01.03.2018 18:45, Ryan Sleevi via dev-security-policy wrote:
>>
>> The point of my question is to clarify, if the DigiCert transition Roots
>> are completely separate from the Apple/Google subCA whitelisting
>> requirements.
>>
>
> I'm not sure how to interpret the Apple/Google question, but
Hello Ryan,
thanks again for this response. The situation appears very complex. I
might follow up with a couple of clarification questions, that are
hopefully simple to answer. Let me start with this one:
Chromium will whitelist the SPKIs of a "CN=DigiCert Transition ECC Root"
and a "CN=DigiCert
In my opinion, Mozilla's and Google's plans to distrust the Thawte,
RapidSSL, GeoTrust, Verisign, and Symantec branded CAs in the browser,
should be interpreted as a recommendation to eventually distrust them
for all server authentication uses.
If a CA gets distrusted for https, then I think it's
Ryan,
thanks for highlighting that I missed a few Roots.
So originally, the October 2017 announcemend had mentioned:
- GeoTrust Global CA
- GeoTrust Primary Certification Authority - G2
- GeoTrust Primary Certification Authority - G3
Looking at the data available at
On 13.02.2018 18:10, Ryan Sleevi wrote:
>
> On Tue, Feb 13, 2018 at 11:30 AM, Kai Engert <k...@kuix.de
> <mailto:k...@kuix.de>> wrote:
>
> A couple more comments below:
>
> On 12.02.2018 19:13, Ryan Sleevi wrote:
> >
> > You're aski
Hello Ryan,
thanks a lot for your very helpfull response!
A couple more comments below:
On 12.02.2018 19:13, Ryan Sleevi wrote:
> A separate question which would be good to clarified: What about
> environments, which want to distrust all old Symantec roots in October
> 2018, but
On 09.02.2018 22:20, Ryan Sleevi wrote:
> As a small clarification - while Chrome has included the certificates,
> as noted in the readme, the whitelist is based on SPKI. This was
> intentional, to avoid situations of interoperability issues.
Hi Ryan,
IIUC, the current implementation in Firefox
On 16.10.2017 19:32, Gervase Markham via dev-security-policy wrote:
> The subCAs that we know of that fall into this category belong to Google
> and Apple. If there are any other subCAs that fall into this category,
> please let us know immediately. Google has one such subCA; Apple has seven.
On 16.10.2017 20:26, Eric Mill via dev-security-policy wrote:
> Adding code to Firefox to support the distrust of specified subCAs seems
> like it would be a good long-term investment for Mozilla, as it would give
> Mozilla a lot more flexibility during future distrust events.
I think this isn't
On 16.10.2017 19:33, Gervase Markham via dev-security-policy wrote:
> As per previous discussions and
> https://wiki.mozilla.org/CA:Symantec_Issues, a consensus proposal[0] was
> reached among multiple browser makers for a graduated distrust of
> Symantec roots.
>
> Here is Mozilla’s planned
On 01.11.2017 00:58, Jeremy Rowley via dev-security-policy wrote:
> A couple of points of clarification (as it seems to have stirred some
> questions)
> 1. Migration to the DigiCert issuing and validation process only applies to
> certs intended for browser use, meaning the infrastructure may
On 16.10.2017 19:32, Gervase Markham via dev-security-policy wrote:
>
> Here is Mozilla’s planned timeline for the graduated distrust of
> Symantec roots (subject to change):
>
> * January 2018 (Firefox 58): Notices in the Developer Console will warn
> about Symantec certificates issued before
On Mon, 2017-07-03 at 20:47 -0400, Ryan Sleevi wrote:
> On Mon, Jul 3, 2017 at 11:53 AM, Kai Engert <k...@kuix.de> wrote:
>
> > > > I suspect, means anyone could plug
> > > > in a modern CI
> >
> > CI meaning Continuous Integration ?
> >
On Wed, 2017-06-28 at 15:08 -0700, Ryan Sleevi via dev-security-policy wrote:
> On Wednesday, June 28, 2017 at 5:29:19 PM UTC-4, Gervase Markham wrote:
> > Well, the fact that we now use Git,
NSS and the root store don't use Git, it uses HG/Mercurial.
> > I suspect, means anyone could plug
> >
On Mon, 2017-07-03 at 15:12 +0100, Gervase Markham wrote:
>
> > I think the new format should be as complete as possible, including both
> > trust
> > and distrust information, including EV and description of rules for partial
> > distrust.
>
> I agree, as long as we can stay away from defining
On Fri, 2017-06-30 at 18:46 +, David Adrian wrote:
> Censys validates certificates against multiple root stores. At the end of
> the day, what we want is a reliable and repeatable way to get an up-to-date
> version of a root store in PEM format.
Can you please clarify if you're talking about
Hello Gerv,
given that today we don't have a single place where all of Mozilla's certificate
trust decisions can be found, introducing that would be a helpful.
I think the new format should be as complete as possible, including both trust
and distrust information, including EV and description of
Are there existing rules, in the CABForum BRs, or in the Mozilla CA policy, that
define under which circumstances the private key of an actively used EV approved
root CA may be transferred to a different company, that hasn't been audited for
EV compliance?
As soon as the private key has been
On Mon, 2016-01-11 at 19:45 +0100, Jakob Bohm wrote:
> He is obviously referring to the fact that refusing to encrypt using
> the MiTM certificate would force users to access their e-mails (etc.)
> using unencrypted connections (plain HTTP, plain IMAP, plain POP3
> etc.), thus exposing themselves
On Sat, 2016-01-09 at 14:11 +, Peter Gutmann wrote:
> That would have some pretty bad consequences. With the MITM CA cert enabled,
> Borat [0] can read every Kazakh user's email, but no-one else can. With the
> MITM CA blacklisted, Borat can still read every Kazakh user's email, but so
> can
I think several separate points need to be discussed.
(a) Inclusion as trustworthy for the global Internet
You might have seen this article, which, to my surprise, can no longer be found
on the site itself, so here is an archived copy:
The earlier comments on this list have shown that S/MIME is in active use (e.g.
in communication between different academic instutions), and that a decision to
remove the S/MIME trust bit from the Mozilla CA list would mean a functional
regression for those users.
In my opinion, the discussion
On Mon, 2015-09-07 at 13:58 +0100, Gervase Markham wrote:
> On 04/09/15 14:09, Phillip Hallam-Baker wrote:
> > Has Mozilla stopped supporting Thunderbird?
>
> No. Mozilla-the-project still develops and supports Thunderbird.
>
> I had thought this was about code signing only, but reading back, I
On Fri, 2015-09-04 at 14:26 +0200, Hubert Kario wrote:
> On Thursday 03 September 2015 11:22:26 Kathleen Wilson wrote:
> > 2) Remove included root certs that only have the Code Signing trust
> > bit enabled. To our knowledge, no one is using such root certs via
> > the NSS root store.
>
> I'm not
On Fri, 2015-09-04 at 11:25 +0200, Kurt Roeckx wrote:
> On 2015-09-03 20:22, Kathleen Wilson wrote:
> > 2) Remove included root certs that only have the Code Signing trust bit
> > enabled. To our knowledge, no one is using such root certs via the NSS
> > root store.
>
> I'm wondering how you
This is a suggestion for stricter rules regarding the creation of
intermediate CA certificates that are issued by root CA certificates
included in the Mozilla CA list.
Every CA organization should be ultimately responsible that the
intermediate CA certificates they create will never be used in a
On Tue, 2015-03-24 at 14:52 -0400, Daniel Micay wrote:
Thoughts?
I think it's a good policy, but like the current policies it cannot
really be enforced because there is no way to validate compliance.
At least there'd be clarity about the immediate removal on discovery.
Kai
On Mon, 2015-03-23 at 17:47 -0500, Richard Barnes wrote:
It has been discovered that an intermediate CA under the CNNIC root has
mis-issued certificates for some Google domains. Full details can be found
in blog posts by Google [0] and Mozilla [1]. We would like to discuss what
further
Hubert, what's your conclusion of your analysis?
Thanks
Kai
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
I'd like to bring your attention to
https://bugzilla.mozilla.org/show_bug.cgi?id=966350
because I haven't seen any public discussion related to this request
yet.
I'm quoting subsets from the bug (please refer to the above link for the
full statement):
At the end of 2013, Symantec issued a cert
34 matches
Mail list logo
