On Fri, Mar 05, 2021 at 08:46:26AM -0800, Bruce via dev-security-policy wrote:
> At the beginning, I think that CAs will generate one or many keys, but
> will not assign them to CAs. The gap period could be days to years.
> Since the requirement says "from the time of CA key pair generation", do
On Tue, Jan 19, 2021 at 07:28:17AM -0800, Ramiro Muñoz via dev-security-policy
wrote:
> Camerfirma is not the member with the highest number of
> incidents nor the member with the most severe ones.
No, but Camerfirma's got a pretty shocking history of poor incident
response, over an extended
On Sun, Jan 17, 2021 at 12:51:29AM -0800, Ramiro Muñoz via dev-security-policy
wrote:
> We don’t ask the community to disregard the data, on the contrary we ask
> the community to analyze the data thoroughly including the impacts
> produced.
OK, I'll bite. As a member of the community, I've
On Mon, Nov 16, 2020 at 02:17:37AM +, Nick Lamb wrote:
> On Mon, 16 Nov 2020 10:13:16 +1100
> Matt Palmer via dev-security-policy
> wrote:
> > I doubt it. So far, every CA that's decided to come up with their own
> > method of proving key compromise has produc
On Sun, Nov 15, 2020 at 04:52:38AM +, Nick Lamb via dev-security-policy
wrote:
> This makes clear that the CA must have at least one of these "clearly
> specified" accepted methods which ought to actually help Matt get some
> traction.
I doubt it. So far, every CA that's decided to come up
On Sat, Nov 14, 2020 at 09:42:48PM +, Nick Lamb via dev-security-policy
wrote:
> This boilerplate does not actually achieve any of those things, and
> you've offered no evidence that it could do so. If anything it
> encourages CAs *not* to actually offer what we wanted: a clearly
> documented
On Thu, Oct 29, 2020 at 05:04:32PM -0700, Bailey Basile via dev-security-policy
wrote:
> We specifically chose not to issue Apple certificates for these keys
> because we did not want users to have to trust only Apple's assertion that
> this key is for a third party.
Can you explain how a DV
On Thu, Oct 29, 2020 at 01:56:53PM -0500, Matthew Hardeman via
dev-security-policy wrote:
> IFF the publicly trusted certificate for the special domain name is
> acquired in the normal fashion and is issued from the normal leaf
> certificate profile at LE, I don't see how the certificate could be
On Fri, Oct 09, 2020 at 06:33:22AM -0700, Tim Callan via dev-security-policy
wrote:
> We anticipate no meaningful changes required to policies, operations, or
> personnel.
[...]
> In this case the required changes are virtually nothing.
These statements concern me somewhat, as reasonable
On Wed, Aug 12, 2020 at 06:25:00PM -0700, cbon...--- via dev-security-policy
wrote:
> > I'm yet to have a CA baulk at accepting a CSR as proof of compromise. It
> > has the benefit of not having nearly as many superfluous fields as a
> > certificate, as well. In terms of being able to deal with
On Sun, Jul 12, 2020 at 10:13:59PM +0200, Oscar Conesa via dev-security-policy
wrote:
> Some CAs may want to assume a leadership role in the sector and unilaterally
> assume more additional strict security controls. That is totally legitimate.
> But it is also legitimate for other CAs to assume 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
On Mon, Jul 06, 2020 at 10:53:50AM -0700, zxzxzx9--- via
dev-security-policy wrote:
> Can't the affected CAs decide on their own whether to destroy the
> intermediate CA private key now, or in case the affected intermediate CA
> private key is later compromised, revoke the root CA instead?
On Mon, Jul 06, 2020 at 03:48:06AM +, Peter Gutmann wrote:
> Matt Palmer via dev-security-policy
> writes:
> >If you're unhappy with the way which your interests are being represented by
> >your CA, I would encourage you to speak with them.
>
> It's not the CAs, it'
On Sat, Jul 04, 2020 at 07:42:12PM -0700, Peter Bowen wrote:
> On Sat, Jul 4, 2020 at 7:12 PM Matt Palmer via dev-security-policy
> wrote:
> >
> > On Sat, Jul 04, 2020 at 08:42:03AM -0700, Mark Arnott via
> > dev-security-policy wrote:
> > > I was informed yeste
On Sat, Jul 04, 2020 at 08:42:03AM -0700, Mark Arnott via dev-security-policy
wrote:
> I was informed yesterday that I would have to replace just over 300
> certificates in 5 days because my CA is required by rules from the CA/B
> forum to revoke its subCA certificate.
The possibility of such an
On Sat, Jul 04, 2020 at 12:51:32PM -0700, Mark Arnott via dev-security-policy
wrote:
> I think that the lack of fairness comes from the fact that the CA/B forum
> only represents the view points of two interests - the CAs and the Browser
> vendors. Who represents the interests of industries and
On Sun, Jun 28, 2020 at 05:14:47AM -0700, Corey Bonnell via dev-security-policy
wrote:
> Feedback and suggestions for improvements are greatly appreciated. Even
> if this format is not adopted as a standard mechanism for providing proof
> of key compromise, I hope that by posting it here there
On Tue, Jun 02, 2020 at 06:38:12PM -0700, Benjamin Seidenberg via
dev-security-policy wrote:
> Today, I received a marketing email from one of the CAs in Mozilla's
> program (Sectigo). As far as I know, the only interactions I've ever had
> with this CA where they would have gotten my name and
On Thu, May 21, 2020 at 02:01:49PM -0700, Daniela Hood via dev-security-policy
wrote:
> After that we followed the Baseline Requirements 4.9.1 That says: "The CA
> obtains evidence that the Subscriber's Private Key corresponding to the
> Public Key in the Certificate suffered a Key Compromise;"
On Tue, May 19, 2020 at 07:33:00PM -0700, sandybar497--- via
dev-security-policy wrote:
> Here are the original headers (omitting my email)
>
> ***
>
> MIME-Version: 1.0
> Date: Thu, 7 May 2020 12:07:07 +
> Message-ID:
>
> Subject: Certificate Problem Report - compromised key
> From:
On Mon, May 18, 2020 at 03:46:46AM +, Peter Gutmann via dev-security-policy
wrote:
> I assume this is ACME that allows a key to be certified without any proof that
> the entity requesting the certificate controls it?
ACME requires a CSR to be submitted in order to get the certificate issued.
On Wed, May 13, 2020 at 08:28:03AM -0400, Ryan Sleevi wrote:
> On Tue, May 12, 2020 at 11:47 PM Matt Palmer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> > 1. As Hanno said, it's a public resource, and as such it should, in
> > general,
> &
On Tue, May 12, 2020 at 11:37:23PM -0400, Ryan Sleevi wrote:
> On Tue, May 12, 2020 at 10:30 PM Matt Palmer via dev-security-policy
> wrote:
> >
> > On Tue, May 12, 2020 at 07:35:50AM +0200, Hanno Böck via
> > dev-security-policy wrote:
> > > After communic
On Tue, May 12, 2020 at 07:35:50AM +0200, Hanno Böck via dev-security-policy
wrote:
> After communicating with Microsoft it turns out this is due to user
> agent blocking, the URLs can be accessed, but not with a wget user
> agent.
> Microsoft informed me that "the wget agent is explicitly being
On Mon, May 11, 2020 at 02:50:19PM +, Corey Bonnell via dev-security-policy
wrote:
> > * Are there rules that CAs must adhere to in regards to referencing the
> > intermediate in the AIA field? Does it need to be available? Does it
> > need to be there at all?
>
> It's optional
On Sun, May 10, 2020 at 09:16:41AM -0700, irvinfly--- via dev-security-policy
wrote:
> Hi, I'm researching the status of Taiwan GCA and coincidence to find this
> issue. I will try to find a relative staff at National Development
> Council to get back.
Coincidentally, I happened to stumble over
In trying to validate the problem reporting e-mail address for
https://crt.sh/?id=657220608, I grovelled through the CCADB CSV-o'-Doom
(freshly downloaded for that "new CSV" smell ), and the CPS link
therein refers to http://grca.nat.gov.tw/download/GPKI_CP_eng_v1.7.pdf
which, at the time of
This has happened twice now, with two different CAs, so I'm going to raise
it as a general issue.
I've had one CA reject e-mails because the HELO name wasn't to their liking
(which I was able to fix). The other, which has just started happening now,
is utterly inscrutible -- "550 Administrative
On Mon, May 04, 2020 at 08:45:34AM -0700, sandybar497--- via
dev-security-policy wrote:
> Additionally, Sectigo referred to pwnedkeys as
> some sort of authority that they say it’s not compromised.
Bless their little cotton socks, pwnedkeys is now such an authority that
Sectigo thinks I've got
On Fri, May 01, 2020 at 04:48:28PM +, Corey Bonnell via dev-security-policy
wrote:
> I have briefly reviewed and would like to ask what is the intent of Item 4
> and the associated sub-items? The Browser Alignment draft ballot is under
> discussion in the CAB Forum, so the intent behind the
On Tue, Apr 21, 2020 at 01:23:49AM -0400, Ryan Sleevi wrote:
> On Mon, Apr 20, 2020 at 10:04 PM Matt Palmer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> > 1. Make cPSuri mandatory
>
> We really don’t need to be stuffing everything into s
A major difficulty I found in trying to report compromised keys to CAs was
in finding a reporting address to use. Now, by itself, that could be solved
by making CCADB reporting addresses be authoritative, but that would also
require standardisation of reporting types, and it's a whole rabbit
On Thu, Apr 09, 2020 at 04:55:51PM +0100, Nick Lamb via dev-security-policy
wrote:
> Right-sizing of Bloom filters is an issue, but you only need to get
> ballpark accuracy. If we genuinely aren't sure if there will be a
> thousand or a billion RSA private keys compromised next year then yup
>
On Mon, Apr 06, 2020 at 12:56:02PM -0400, Ryan Sleevi wrote:
> On Mon, Mar 30, 2020 at 5:32 PM Matt Palmer via dev-security-policy
> wrote:
> > Righto, the goals are:
> >
> > * Make it a policy violation for CAs to issue a certificate using a public
> >
I've recently been taking careful notice of the revocation information that
CAs are publishing, because what little life I did have is currently under
lockdown. I've come across a rather curious behaviour that seems fairly
endemic: declarations of revocation that are effectively in the future.
On Tue, Mar 31, 2020 at 01:34:27PM +1100, Matt Palmer wrote:
> If someone would like to make the argument that it's a gray area because I
> submitted the revocation requests via ACME, rather than the CPS-provided
> e-mail address, well, I can switch to sending e-mails, but having a human
On Mon, Mar 30, 2020 at 06:01:58PM -0400, Ryan Sleevi wrote:
> On Mon, Mar 30, 2020 at 5:43 PM Matt Palmer via dev-security-policy
> wrote:
> >
> > On Mon, Mar 30, 2020 at 01:48:28PM -0700, Josh Aas via dev-security-policy
> > wrote:
> > > Matt - It would be h
On Mon, Mar 30, 2020 at 01:48:28PM -0700, Josh Aas via dev-security-policy
wrote:
> Matt - It would be helpful if you could report issues like this to the CA
> in question, not just to mdsp.
Helpful to *whom*, exactly? I don't write up these reports to be helpful to
the CA in question; I write
On Mon, Mar 30, 2020 at 10:59:02AM -0400, Ryan Sleevi wrote:
> On Mon, Mar 30, 2020 at 6:28 AM Matt Palmer via dev-security-policy
> wrote:
> It's useful to focus on the goal, rather than the precise language, or
> where you see folks getting confused or misundersta
On Sat, Mar 28, 2020 at 07:11:43PM +1100, Matt Palmer wrote:
> In concert with my (human-mediated) revocation notifications, I have been
> sending semi-automated revocation requests to Let's Encrypt, using the ACME
> protocol. This has been extremely smooth and straightforward, an
In my recent forays into mass-revocation for key compromise, one aspect that
was particularly frustrating and unnecessary was having to send revocation
requests for new certificates, issued by a CA using a private key which I
had previously reported as compromised to that same CA. Once a key is
I've been asked to provide some "big-picture" thoughts on how the process
for key compromise revocations works, doesn't work, and could be improved.
This is based on the work that I've done over the past month or so,
requesting revocation of certificates which have had their private keys
At 2020-03-20 03:02:43 UTC, I sent a notification to sslab...@sectigo.com
that certificate https://crt.sh/?id=1659219230 was using a private key with
SPKI fingerprint
4c67cc2eb491585488bab29a89899e4e997648c7047c59e99a67c6123434f1eb, which was
compromised due to being publicly disclosed. My e-mail
On Mon, Mar 23, 2020 at 06:15:00PM +, Jeremy Rowley wrote:
> There are two things worth discussing in general:
>
> 1. I’m very interested in seeing the Let’s Encrypt response to this issue
> since the biggest obstacle in trying to find all of the keys with the same
> private key is the sheer
On Mon, Mar 23, 2020 at 12:53:43PM -0400, Ryan Sleevi wrote:
> To make sure I understand the timeline correctly:
> 2020-03-20 02:05:49 UTC - Matt reports SPKI 4310b6bc0841efd7fcec6ba0ed1f36
> e7a28bf9a707ae7f7771e2cd4b6f31b5af, associated with
> https://crt.sh/?id=1760024320 , as compromised
>
On Mon, Mar 23, 2020 at 03:01:34PM +, Jeremy Rowley wrote:
> Ryan's post was the part I thought was relevant, but I understood it
> differently. The cert was issued, but we should have now revoked it (24
> hours after receiving notice). I do see your interpretation though, and
> the language
On Mon, Mar 23, 2020 at 06:14:29AM +, Jeremy Rowley wrote:
> That's not the visible consensus IMO. The visible consensus is we need to
> revoke a cert that is key compromised once we're informed the key is
> compromised for that cert
>
On Mon, Mar 23, 2020 at 02:02:18AM +, Stephen Davidson via
dev-security-policy wrote:
> Summary: The certificates noted in Matt Palmer's email below were not in
> his original problem report to QuoVadis.
While this may be true in an extremely narrow and literal sense, I don't
believe this
On Sun, Mar 22, 2020 at 07:47:49AM +0100, Hanno Böck via dev-security-policy
wrote:
> FWIW: Given that with the private key it's easily possible to revoke
> certificates from Let's Encrypt I took the key yesterday and iterated
> over all of them and called the revoke command of certbot.
Yes, I
Three certificates were reported as having private keys which had
been publicly disclosed, by e-mailing complia...@quovadisglobal.com at
2020-03-20 03:05:14 UTC. E-mail was received by a QuoVadis server at
2020-03-20 03:05:18 UTC. As of 2020-03-22 05:17:37, OCSP still shows all of
these
Certificate https://crt.sh/?id=2606438724, issued either at 2020-03-21
00:00:00 UTC (going by notBefore) or 2020-03-21 01:56:31 UTC (going by
SCTs), is using a private key with SPKI
4310b6bc0841efd7fcec6ba0ed1f36e7a28bf9a707ae7f7771e2cd4b6f31b5af, which was
reported to Digicert as compromised on
On Sat, Mar 21, 2020 at 07:20:27PM +, Nick Lamb wrote:
> On Sat, 21 Mar 2020 13:40:21 +1100
> Matt Palmer via dev-security-policy
> wrote:
> > There's also this one, which is another reuse-after-revocation, but
> > the prior history of this key suggests that there's som
On Sat, Mar 21, 2020 at 01:53:31AM +, Nick Lamb wrote:
> On Sat, 21 Mar 2020 09:25:26 +1100
> Matt Palmer via dev-security-policy
> wrote:
>
> > These two certificates:
> >
> > https://crt.sh/?id=2602048478=ocsp
> > https://crt.sh/?id=260132453
These two certificates:
https://crt.sh/?id=2602048478=ocsp
https://crt.sh/?id=2601324532=ocsp
Were issued by Let's Encrypt more than 24 hours ago, and remain unrevoked,
despite the revocation of the below two certificates, which use the same
private key, for keyCompromise prior to the
On Thu, Mar 19, 2020 at 12:33:29PM -0400, Ryan Sleevi wrote:
> I'm not sure an incident report is necessary. The CCADB policy allows both
> to be provided, and the mechanisms that CCADB uses (both for CAs and for
> Root Stores) permit a host of expressiveness (and further changes are being
>
On Thu, Mar 19, 2020 at 11:10:05AM +, arnold.ess...@t-systems.com wrote:
> Thanks for pointing it out. We changed the links so that they now refer
> to the English version of the CP and CPS.
Thanks for the quick update. Do you have an ETA for the preliminary
incident report?
- Matt
On Thu, Mar 19, 2020 at 05:30:31AM -0500, Ryan Sleevi wrote:
> On Thu, Mar 19, 2020 at 1:02 AM Matt Palmer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> > 2. If there are not explicit prohibitions already in place, *should* there
> >be?
As I understand the CCADB Policy (which is included by reference in the
Mozilla Root Store Policy), CAs are required to provide an English
translation of their CP/CPS documents, and link to them in the CCADB.
At the time of writing, the "AllCertificateRecordsReport" CSV shows the
link for the
Since I started requesting revocation for certificates with
known-compromised private keys, I've noticed a rather disturbing pattern
emerging in a few cases:
1. I find a private key on the Internet.
2. I request revocation from the CA on the basis that the private key is
compromised, and
On Tue, Mar 17, 2020 at 03:51:13PM +, Tim Hollebeek wrote:
> For what it's worth, while we generally try to accept any reasonable proof
> of key compromise, we have seen quite a large variety of things sent to
> us. This includes people actually sending us private keys in various
> forms,
On Mon, Mar 16, 2020 at 12:11:57PM -0700, Chris Kemmerer via
dev-security-policy wrote:
> On Wednesday, March 11, 2020 at 5:41:00 PM UTC-5, Matt Palmer wrote:
> > On Wed, Mar 11, 2020 at 10:46:05AM -0700, Chris Kemmerer via
> > dev-security-policy wrote:
> > > On Tuesday
On Mon, Mar 16, 2020 at 09:06:17PM +, Tim Hollebeek via dev-security-policy
wrote:
> I'd like to start a discussion about some practices among other commercial
> CAs that have recently come to my attention, which I personally find
> disturbing. While it's perfectly appropriate to have Terms
On Wed, Mar 11, 2020 at 10:46:05AM -0700, Chris Kemmerer via
dev-security-policy wrote:
> On Tuesday, March 10, 2020 at 8:44:49 PM UTC-5, Matt Palmer wrote:
> > On Tue, Mar 10, 2020 at 01:48:49PM -0700, Chris Kemmerer via
> > dev-security-policy wrote:
> > > For th
On Tue, Mar 10, 2020 at 05:53:13PM -0500, Matthew Hardeman via
dev-security-policy wrote:
> Isn't the evident answer, if reasonable compromise is not forthcoming, just
> to publish the compromised private key. There's no proof of a compromised
> private key quite as good as providing a copy of
On Tue, Mar 10, 2020 at 01:48:49PM -0700, Chris Kemmerer via
dev-security-policy wrote:
> We have updated https://bugzilla.mozilla.org/show_bug.cgi?id=1620772 with
> the findings of our current investigation.
Thanks for this update. I have... comments.
Before I get into the nitty-gritty,
On Tue, Mar 10, 2020 at 05:18:51PM -0400, Ryan Sleevi via dev-security-policy
wrote:
> I'm sympathetic to CAs wanting to filter out the noise of shoddy reports
> and shenanigans, but I'm also highly suspicious of CAs that put too
> unreasonable an onus on reporters.
If CAs want a 100% reliable
On Tue, Mar 10, 2020 at 01:25:11PM -0700, bif via dev-security-policy wrote:
> Voluntarily providing CSR is not an ideal way to prove key compromise,
> because you could've simply found this CSR somewhere (I know, I know,
> super unlikely with your Subject... but still could happen.)
Feel free
ime period.
Excuciatingly detailed timeline follows.
2020-03-06 21:48:53Z E-mail sent to report-ab...@globalsign.com:
-8<-
Date: Sat, 7 Mar 2020 08:48:53 +1100
From: Matt Palmer
To: report-ab...@globalsign.com
Subject: Problem Report for certificate(s) with compromised private key
One or more
Hi Joanna,
Thanks for responding. When can this list, or Bugzilla, expect GoDaddy's
incident report? Also, for the avoidance of further doubt, can you give an
exact timestamp at which GoDaddy considers that evidence of key compromise
was "obtained" for this certificate?
- Matt
On Mon, Mar 09,
On Mon, Mar 09, 2020 at 11:48:40AM -0700, Kathleen Wilson via
dev-security-policy wrote:
> ==Bad==
This is a *very* long list of bad things. Based on this list alone I think
it would be reasonable for Mozilla to reject this application. I'd like to
highlight the things that are practically
Date: Sun, 8 Mar 2020 13:47:54 +1100
From: Matt Palmer
To: practi...@starfieldtech.com
Subject: Problem Report for certificate(s) with compromised private key
One or more certificates issued by your CA are using a private key which has
been publicly disclosed. The list of affected certificates can
On Sat, Mar 07, 2020 at 09:07:11AM -0500, Ryan Sleevi wrote:
> Thanks. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1620772
I'll give points to SSL.com for a speedy initial response, but I'm a bit
disconcerted about this:
> The fingerpint of the claimed Debian weak key was not included
The BRs, s4.9.1.1, state that a CA has up to five days to revoke a
certificate where:
> The CA is made aware of a demonstrated or proven method that exposes the
> Subscriber's Private Key to compromise, methods have been developed that
> can easily calculate it based on the Public Key (such as a
(Pre) Certificate https://crt.sh/?id=2531502044 has been issued with a known
weak key, specifically Debian weak key 2048/i386/rnd/pid17691. I believe
this issuance to be in contravention of SSL.com's CPS, version 1.8, section
6.1.1.2, which states "SSL.com shall reject a certificate request if
On Tue, Mar 03, 2020 at 01:53:49PM -0800, Clint Wilson wrote:
> On Mar 3, 2020, at 1:41 PM, Matt Palmer via dev-security-policy
> wrote:
> > On Tue, Mar 03, 2020 at 11:55:24AM -0800, Clint Wilson via
> > dev-security-policy wrote:
> >> For additional informat
On Tue, Mar 03, 2020 at 01:27:59PM -0700, Wayne Thayer via dev-security-policy
wrote:
> I'd like to ask for input from the community: is this a requirement that we
> should add to the Mozilla policy at this time (effective September 1, 2020)?
I don't see any reason not to.
- Matt
On Tue, Mar 03, 2020 at 11:55:24AM -0800, Clint Wilson via dev-security-policy
wrote:
> For additional information, please see
> https://support.apple.com/en-us/HT211025.
I have a question regarding this part:
> TLS server certificates issued on or after September 1, 2020 00:00 GMT/UTC
> must
On Mon, Mar 02, 2020 at 07:48:23PM +, Corey Bonnell wrote:
> I do think there's value in developing some standard mechanism to request
> revocation/demonstrate possession of the private key.
Interestingly, there (more-or-less) is one these days, as part of ACME. It
requires the usual amount
On Mon, Mar 02, 2020 at 07:35:06PM +, Nick Lamb wrote:
> On Mon, 2 Mar 2020 13:48:55 +1100
> Matt Palmer via dev-security-policy
> wrote:
> > In my specific case, I've been providing a JWS[1] signed by the
> > compromised private key, and CAs are telling me that they can'
Between 26 Feb 2020 00:48:11 UTC and 26 Feb 2020 21:10:18 UTC, I sent three
Certificate Problem Reports to sslab...@sectigo.com, reporting that
certificates issued by then were using keys which have been compromised due
to being publicly disclosed. As of the time of writing, I have not received
a
On Sun, Mar 01, 2020 at 11:14:12PM -0500, Ryan Sleevi wrote:
> On Sun, Mar 1, 2020 at 9:49 PM Matt Palmer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> > The BRs, in s4.9.1.1, say:
> >
> > > The CA SHALL revoke a Certifica
The BRs, in s4.9.1.1, say:
> The CA SHALL revoke a Certificate within 24 hours if one or more of the
> following occurs:
>
> [...]
> 3. The CA obtains evidence that the Subscriber's Private Key
> corresponding to the Public Key in the Certificate suffered a Key
> Compromise
I've come to have
On Fri, Dec 06, 2019 at 07:08:46PM -0800, Apple CA via dev-security-policy
wrote:
> On Saturday, November 23, 2019 at 3:28:10 PM UTC-8, Matt Palmer wrote:
> > [aside: this is how incident reports should be done, IMHO]
> >
> > On Fri, Nov 22, 2019 at 07:23:27PM -0800, Appl
[aside: this is how incident reports should be done, IMHO]
On Fri, Nov 22, 2019 at 07:23:27PM -0800, Apple CA via dev-security-policy
wrote:
> We did not have an accurate understanding of how the vulnerability scanner
> worked. Our understanding of its capabilities lead us to believe it was
>
On Tue, Oct 22, 2019 at 03:35:52PM -0700, Kirk Hall via dev-security-policy
wrote:
> I also have a question for Mozilla on the removal of the EV UI.
This is a mischaracterisation. The EV UI has not been removed, it has been
moved to a new location.
> So my question to Mozilla is, why did
On Tue, Oct 08, 2019 at 07:16:59PM -0700, Paul Walsh via dev-security-policy
wrote:
> Why isn’t anyone’s head blowing up over the Let’s Encrypt stats?
Because those stats don't show anything worth blowing up ones head over. I
don't see anything in them that indicates that those 14,000
On Thu, Oct 03, 2019 at 05:36:50PM -0700, Ronald Crane via dev-security-policy
wrote:
>
> On 10/3/2019 2:09 PM, Ryan Sleevi via dev-security-policy wrote:
> > [snip]
> > > I guess I wasn't specific enough. I am looking for a good study that
> > > supports the proposition that the Internet
On Thu, Sep 05, 2019 at 03:38:24PM -0700, browserpadlock--- via
dev-security-policy wrote:
> On Thursday, September 5, 2019 at 12:16:13 PM UTC-4, Jonathan Rudenberg wrote:
> > On Wed, Sep 4, 2019, at 14:53, browserpadlock--- via dev-security-policy
> > wrote:
> > > It seems that the Certificate
On Wed, Sep 04, 2019 at 03:50:40PM +0200, Kurt Roeckx via dev-security-policy
wrote:
> On 2019-09-04 14:14, Matt Palmer wrote:
> > If EV information is of use in anti-phishing efforts, then it would be best
> > for the providers of anti-phishing services to team up with
On Tue, Sep 03, 2019 at 06:16:23PM -0700, Kirk Hall via dev-security-policy
wrote:
> However, I did receive authority to post the following statement from
> someone who works for a major browser phishing filter (but without
> disclosing the person's name or company). Here is the authorized
>
On Thu, Aug 29, 2019 at 02:14:10PM -0700, Kirk Hall via dev-security-policy
wrote:
> For EV certificates, the appeal for website owners over the past 10 years
> has been that they get a distinctive EV UI that they believe protects
> their consumers and their brands (again, don't argue with me but
On Wed, Aug 28, 2019 at 11:51:37AM -0700, Josef Schneider via
dev-security-policy wrote:
> Am Dienstag, 27. August 2019 00:48:38 UTC+2 schrieb Matt Palmer:
> > On Mon, Aug 26, 2019 at 05:39:14AM -0700, Josef Schneider via
> > dev-security-policy wrote:
> > > Sure I can re
On Mon, Aug 26, 2019 at 05:39:14AM -0700, Josef Schneider via
dev-security-policy wrote:
> Sure I can register a company and get an EV certificate for that company.
> But can I do this completely anonymous like getting a DV cert?
Yes.
> Nobody is arguing that EV certificates are perfect and
On Sun, Aug 18, 2019 at 09:14:52AM +0200, Paul van Brouwershaven wrote:
> On Sun, 18 Aug 2019, 07:18 Matt Palmer via dev-security-policy, <
> dev-security-policy@lists.mozilla.org> wrote:
> > On Thu, Aug 15, 2019 at 05:58:56PM +, Doug Beattie via
> > dev-security-polic
On Sun, Aug 18, 2019 at 01:35:55PM -0700, Daniel Marschall via
dev-security-policy wrote:
> Am Sonntag, 18. August 2019 07:18:56 UTC+2 schrieb Matt Palmer:
> > [...] From what I can see so far,
> > browser vendors aren't "ending" EV certificates, a couple of them
On Fri, Aug 16, 2019 at 12:42:35PM -0700, tim--- via dev-security-policy wrote:
> That’s where EV certificates can help. Data shows that websites with EV
> certificates have a very low incidence of phishing.
[...]
> This research validates the results of an earlier study of 3,494 encrypted
>
On Fri, Aug 16, 2019 at 01:37:40PM +, Doug Beattie via dev-security-policy
wrote:
> DB: Yes, that's true. I was saying that phishing sites don't use EV, not
> that EV sites don't get phished
>
> Surely this shows that EV is not needed to make phishing work, not that EV
> reduces phishing?
On Thu, Aug 15, 2019 at 05:58:56PM +, Doug Beattie via dev-security-policy
wrote:
> Shouldn’t the large enterprises that see a value in identity (as
> does GlobalSign) drive the need for ending EV certificates?
Can you point me to the in-progress discussion in the CA/B Forum lists
that is
On Fri, Aug 16, 2019 at 03:15:39PM -0700, Daniel Marschall via
dev-security-policy wrote:
> (2) I am a pro EV person, and I do not have any financial benefit from EV
> certificates. I do not own EV certificates, instead my own websites use
> Let's Encrypt DV certificates. But when I visit
1 - 100 of 306 matches
Mail list logo
