Dear Steven,
CA certificates can have a validity longer than 398 days. The policy
applies to the validity period of TLS server certificates. At the CA level,
it will be enforced as a compliance issue in the root store when we accept
or remove a root CA in the "publicly trusted" root store. It will
On Tuesday, July 14, 2020 at 2:13:30 PM UTC-4, Ben Wilson wrote:
> Hi Christian,
> I think your concern is about how our code will enforce this. Because our
> policy only applies to roots that are built in, our intent is to have our
> code apply this restriction only to certificates that chain
Hi Christian,
I think your concern is about how our code will enforce this. Because our
policy only applies to roots that are built in, our intent is to have our
code apply this restriction only to certificates that chain up to built-in
roots.
Thanks,
Ben
On Mon, Jul 13, 2020 at 10:37 PM
Am 09.07.2020 um 17:46 schrieb Ben Wilson via dev-security-policy:
https://blog.mozilla.org/security/2020/07/09/reducing-tls-certificate-lifespans-to-398-days/
Hi,
blog post should clarify if this is valid for certificates issued by
preinstalled root CAs only or also for CAs installed by
On Sat, 11 Jul 2020 11:06:56 +1000
Matt Palmer via dev-security-policy
wrote:
> A histogram of the number of certificates grouped by their notBefore
> date is going to show a heck of a bump on August 31, I'll wager.
> Will be interesting to correlate notBefore with SCTs.
I expect there will be a
On Fri, Jul 10, 2020 at 10:48:39AM -0600, Ben Wilson via dev-security-policy
wrote:
> Some people have asked whether two-year certificates existing on August 31
> would remain valid. The answer is yes. Those certificates will remain
> valid until they expire. The change only applies to
t; Sent: Friday, July 10, 2020 12:49 PM
> To: mozilla-dev-security-policy
>
> Subject: Re: New Blog Post on 398-Day Certificate Lifetimes
>
> Some people have asked whether two-year certificates existing on August 31
> would remain valid. The answer is yes. Those certificates wil
Ben,
For the avoidance of doubt, I assume this means Sept 1, 00:00 UTC.
-Original Message-
From: dev-security-policy On
Behalf Of Ben Wilson via dev-security-policy
Sent: Friday, July 10, 2020 12:49 PM
To: mozilla-dev-security-policy
Subject: Re: New Blog Post on 398-Day Certificate
Some people have asked whether two-year certificates existing on August 31
would remain valid. The answer is yes. Those certificates will remain
valid until they expire. The change only applies to certificates issued on
or after Sept. 1, 2020.
___
Just to depersonalize it a bit so it's not only Ryan responding - what Ryan
is saying is correct. Mozilla's blog post uses the phrase "impersonating a
website" to describe non-phishing attacks, such as performing active MITM
attacks that modify or replace (or surveil) data in flight, or relying on
>
> Now that I have proven beyond a shadow of a doubt that we are talking
> about phishing, feel free to debate the merits of my points raised in my
> original email.
>
Thanks Paul. I think you're the only person I've encountered who refers to
key compromise as phishing, but I don't think we'll
Ryan,
If you said “Mozilla is making this change and there’s nothing you can say or
do to change that” I would accept those words, as I did with Ben’s response.
But you engaged after Ben’s response, so I’d like to respond to your comments.
Here’s some common ground… we both believe that there
I’m not sure how that answered my question? Nothing about the post seems to
be about phishing, which is not surprising, since certificates have nothing
to do with phishing, but your response just talks more about phishing.
It seems you may be misinterpreting “security risks” as “phishing“, since
Thanks, Paul, for your comments and concerns regarding our reasons 2 and 3,
and the costs vs. benefits of going to a 398-day certificate lifetime.
We'll keep those in mind as we move forward. In response, the security of
our users is the primary concern for Mozilla. So while we recognize there
Good question. And I can see why you might ask that question.
The community lead of PhishTank mistakenly said that submissions should only be
made for URLs that are used to steal' credentials. This helps to demonstrate a
misconception. While this might have been ok in the past, it’s not today.
On Thu, Jul 9, 2020 at 1:04 PM Paul Walsh via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> According to Google, spear phishing
I didn't see phishing mentioned in Mozilla's post, which is unsurprising,
since certificates have nothing to do with phishing. Did I overlook
Ugh, some poor language/typos but I”m sure people can navigate them. Sorry
about that.
> On Jul 9, 2020, at 10:04 AM, Paul Walsh wrote:
>
> Thanks Ben,
>
> I’ve only had half a cup of coffee this am, so it’s possible I’m not yet
> awake :)
>
> I have a question about reasons 2 and 3 as
Thanks Ben,
I’ve only had half a cup of coffee this am, so it’s possible I’m not yet awake
:)
I have a question about reasons 2 and 3 as they’re closely related to the
attack vector.
According to Google, spear phishing attacks have a shelf life of 7 minutes
while bulk campaigns have a shelf
All,
This is just to let everyone know that I posted a new Mozilla Security blog
post this morning. Here is the link>
https://blog.mozilla.org/security/2020/07/09/reducing-tls-certificate-lifespans-to-398-days/
As I note at the end of the blog post, we continue to seek safeguarding
secure browsing
19 matches
Mail list logo
