Re: Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous Audits

2021-03-05 Thread Matt Palmer via dev-security-policy
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

Re: Summary of Camerfirma's Compliance Issues

2021-01-19 Thread Matt Palmer via dev-security-policy
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

Re: Summary of Camerfirma's Compliance Issues

2021-01-18 Thread Matt Palmer via dev-security-policy
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

Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

2020-11-16 Thread Matt Palmer via dev-security-policy
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

Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

2020-11-15 Thread Matt Palmer via dev-security-policy
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

Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

2020-11-14 Thread Matt Palmer via dev-security-policy
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

Re: TLS certificates for ECIES keys

2020-11-01 Thread Matt Palmer via dev-security-policy
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

Re: TLS certificates for ECIES keys

2020-10-29 Thread Matt Palmer via dev-security-policy
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

Re: Sectigo to Be Acquired by GI Partners

2020-10-12 Thread Matt Palmer via dev-security-policy
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

Re: Proposal for a standard proof of compromised key/revocation request format

2020-08-12 Thread Matt Palmer via dev-security-policy
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

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

2020-07-12 Thread Matt Palmer via dev-security-policy
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

Re: New Blog Post on 398-Day Certificate Lifetimes

2020-07-10 Thread Matt Palmer via dev-security-policy
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

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

2020-07-07 Thread Matt Palmer via dev-security-policy
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?

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

2020-07-05 Thread Matt Palmer via dev-security-policy
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'

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

2020-07-05 Thread Matt Palmer via dev-security-policy
On Sun, Jul 05, 2020 at 09:30:33PM +, Buschart, Rufus via dev-security-policy wrote: > > From: dev-security-policy > > On Behalf Of Matt Palmer via dev-security-policy > > Sent: Sonntag, 5. Juli 2020 06:36 > > > > On Sat, Jul 04, 2020 at 07:42:12PM -0700, P

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

2020-07-04 Thread Matt Palmer via dev-security-policy
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

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

2020-07-04 Thread Matt Palmer via dev-security-policy
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

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

2020-07-04 Thread Matt Palmer via dev-security-policy
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

Re: Proposal for a standard proof of compromised key/revocation request format

2020-06-28 Thread Matt Palmer via dev-security-policy
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

Re: Use of information collected from problem reporting addresses for marketing?

2020-06-02 Thread Matt Palmer via dev-security-policy
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

Re: GoDaddy: Failure to revoke certificate with compromised key within 24 hours

2020-05-21 Thread Matt Palmer via dev-security-policy
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;"

Re: GoDaddy: Failure to revoke certificate with compromised key within 24 hours

2020-05-20 Thread Matt Palmer via dev-security-policy
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:

Re: Digicert issued certificate with let's encrypts public key

2020-05-17 Thread Matt Palmer via dev-security-policy
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.

Re: AIA CA Issuers URL gives 403 (Microsoft)

2020-05-13 Thread Matt Palmer via dev-security-policy
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, > &

Re: AIA CA Issuers URL gives 403 (Microsoft)

2020-05-12 Thread Matt Palmer via dev-security-policy
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

Re: AIA CA Issuers URL gives 403 (Microsoft)

2020-05-12 Thread Matt Palmer via dev-security-policy
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

Re: AIA CA Issuers field

2020-05-11 Thread Matt Palmer via dev-security-policy
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

Re: GRCA: Out-of-date CPS provided in CCADB

2020-05-10 Thread Matt Palmer via dev-security-policy
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

GRCA: Out-of-date CPS provided in CCADB

2020-05-07 Thread Matt Palmer via dev-security-policy
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

Filtering on problem reporting e-mail addresses

2020-05-07 Thread Matt Palmer via dev-security-policy
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

Re: Sectigo: Failure to revoke certificate with compromised key

2020-05-05 Thread Matt Palmer via dev-security-policy
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

Re: DRAFT May 2020 CA Communication/Survey

2020-05-01 Thread Matt Palmer via dev-security-policy
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

Re: Proposal: Make readable CPSes easier to find

2020-04-20 Thread Matt Palmer via dev-security-policy
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

Proposal: Make readable CPSes easier to find

2020-04-20 Thread Matt Palmer via dev-security-policy
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

Re: Proposal: prohibit issuance of new certificates with known-compromised keys, and for related purposes

2020-04-09 Thread Matt Palmer via dev-security-policy
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 >

Re: Proposal: prohibit issuance of new certificates with known-compromised keys, and for related purposes

2020-04-06 Thread Matt Palmer via dev-security-policy
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 > >

Revocation from the fuuutuuuuuure

2020-04-05 Thread Matt Palmer via dev-security-policy
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.

Re: Let's Encrypt: Failure to revoke key-compromised certificates within 24 hours

2020-03-30 Thread Matt Palmer via dev-security-policy
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 > process

Re: Let's Encrypt: Failure to revoke key-compromised certificates within 24 hours

2020-03-30 Thread Matt Palmer via dev-security-policy
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

Re: Let's Encrypt: Failure to revoke key-compromised certificates within 24 hours

2020-03-30 Thread Matt Palmer via dev-security-policy
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

Re: Proposal: prohibit issuance of new certificates with known-compromised keys, and for related purposes

2020-03-30 Thread Matt Palmer via dev-security-policy
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

Re: Musings on mass key-compromise revocations

2020-03-30 Thread Matt Palmer via dev-security-policy
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, and my life > --

Proposal: prohibit issuance of new certificates with known-compromised keys, and for related purposes

2020-03-30 Thread Matt Palmer via dev-security-policy
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

Musings on mass key-compromise revocations

2020-03-28 Thread Matt Palmer via dev-security-policy
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

Sectigo: Failure to revoke certificate with previously-compromised key within 24 hours

2020-03-27 Thread Matt Palmer via dev-security-policy
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

Re: Digicert: failure to revoke certificate with previously compromised key

2020-03-23 Thread Matt Palmer via dev-security-policy
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

Re: Digicert: failure to revoke certificate with previously compromised key

2020-03-23 Thread Matt Palmer via dev-security-policy
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 >

Re: Digicert: failure to revoke certificate with previously compromised key

2020-03-23 Thread Matt Palmer via dev-security-policy
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

Re: Digicert: failure to revoke certificate with previously compromised key

2020-03-23 Thread Matt Palmer via dev-security-policy
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 >

Re: QuoVadis: Failure to revoke key-compromised certificates within 24 hours

2020-03-22 Thread Matt Palmer via dev-security-policy
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

Re: Paessler (was Re: Let's Encrypt: Failure to revoke key-compromised certificates within 24 hours)

2020-03-22 Thread Matt Palmer via dev-security-policy
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

QuoVadis: Failure to revoke key-compromised certificates within 24 hours

2020-03-21 Thread Matt Palmer via dev-security-policy
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

Digicert: failure to revoke certificate with previously compromised key

2020-03-21 Thread Matt Palmer via dev-security-policy
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

Re: Paessler (was Re: Let's Encrypt: Failure to revoke key-compromised certificates within 24 hours)

2020-03-21 Thread Matt Palmer via dev-security-policy
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

Re: Let's Encrypt: Failure to revoke key-compromised certificates within 24 hours

2020-03-20 Thread Matt Palmer via dev-security-policy
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

Let's Encrypt: Failure to revoke key-compromised certificates within 24 hours

2020-03-20 Thread Matt Palmer via dev-security-policy
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

Re: DFN-Verein: CPS/CP link in CCADB not in English

2020-03-19 Thread Matt Palmer via dev-security-policy
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 >

Re: DFN-Verein: CPS/CP link in CCADB not in English

2020-03-19 Thread Matt Palmer via dev-security-policy
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

Re: Is issuing a certificate for a previously-reported compromised private key misissuance?

2020-03-19 Thread Matt Palmer via dev-security-policy
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?

DFN-Verein: CPS/CP link in CCADB not in English

2020-03-19 Thread Matt Palmer via dev-security-policy
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

Is issuing a certificate for a previously-reported compromised private key misissuance?

2020-03-19 Thread Matt Palmer via dev-security-policy
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

Re: Acceptable forms of evidence for key compromise

2020-03-17 Thread Matt Palmer via dev-security-policy
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,

Re: ssl.com: Certificate with Debian weak key

2020-03-16 Thread Matt Palmer via dev-security-policy
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, March 10, 2020 at

Re: Terms and Conditions that use technical measures to make it difficult to change CAs

2020-03-16 Thread Matt Palmer via dev-security-policy
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

Re: ssl.com: Certificate with Debian weak key

2020-03-11 Thread Matt Palmer via dev-security-policy
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 the purpose of identifying

Re: GoDaddy: Failure to revoke key-compromised certificate within 24 hours

2020-03-10 Thread Matt Palmer via dev-security-policy
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

Re: ssl.com: Certificate with Debian weak key

2020-03-10 Thread Matt Palmer via dev-security-policy
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,

Re: key compromise revocation methods [was: GoDaddy: Failure to revoke key-compromised certificate within 24 hours]

2020-03-10 Thread Matt Palmer via dev-security-policy
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

Re: CSRs as a means of attesting key compromise [was: GoDaddy: Failure to revoke key-compromised certificate within 24 hours]

2020-03-10 Thread Matt Palmer via dev-security-policy
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

GlobalSign: Failure to revoke certificate with compromised private key within 24 hours

2020-03-09 Thread Matt Palmer via dev-security-policy
A certificate with a publicly-disclosed private key was reported to GlobalSign for revocation within the BR-mandated 24 hour period, however the revocation took place over 46 hours after the report was sent. Several requests for information I had already provided were made by GlobalSign, however

Re: GoDaddy: Failure to revoke key-compromised certificate within 24 hours

2020-03-09 Thread Matt Palmer via dev-security-policy
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,

Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009

2020-03-09 Thread Matt Palmer via dev-security-policy
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

GoDaddy: Failure to revoke key-compromised certificate within 24 hours

2020-03-08 Thread Matt Palmer via dev-security-policy
Following a problem report sent to the CPS-specified address, evidence of key compromise for a private key used in a certificate issued by GoDaddy has not been revoked within the 24 hour timeframe required by the Baseline Requirements s4.9.1.1. Whilst GoDaddy did provide a response within 24

Re: ssl.com: Certificate with Debian weak key

2020-03-07 Thread Matt Palmer via dev-security-policy
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

When is a "weak key" a "compromised key"?

2020-03-06 Thread Matt Palmer via dev-security-policy
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

ssl.com: Certificate with Debian weak key

2020-03-06 Thread Matt Palmer via dev-security-policy
(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

Re: About upcoming limits on trusted certificates

2020-03-03 Thread Matt Palmer via dev-security-policy
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

Re: About upcoming limits on trusted certificates

2020-03-03 Thread Matt Palmer via dev-security-policy
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

Re: About upcoming limits on trusted certificates

2020-03-03 Thread Matt Palmer via dev-security-policy
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

Re: Acceptable forms of evidence for key compromise

2020-03-02 Thread Matt Palmer via dev-security-policy
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

Re: Acceptable forms of evidence for key compromise

2020-03-02 Thread Matt Palmer via dev-security-policy
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'

Sectigo: Failure to process revocation request within 24 hours

2020-03-01 Thread Matt Palmer via dev-security-policy
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

Re: Acceptable forms of evidence for key compromise

2020-03-01 Thread Matt Palmer via dev-security-policy
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

Acceptable forms of evidence for key compromise

2020-03-01 Thread Matt Palmer via dev-security-policy
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

Re: Apple: Patch Management

2019-12-09 Thread Matt Palmer via dev-security-policy
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, Apple CA via

Re: Apple: Patch Management

2019-11-23 Thread Matt Palmer via dev-security-policy
[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 >

Re: Firefox removes UI for site identity

2019-10-22 Thread Matt Palmer via dev-security-policy
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

Re: Website owner survey data on identity, browser UIs, and the EV UI

2019-10-08 Thread Matt Palmer via dev-security-policy
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

Re: Re: [FORGED] Re: Website owner survey data on identity, browser UIs, and the EV UI

2019-10-03 Thread Matt Palmer via dev-security-policy
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

Re: An honest viewpoint: Move Extended Validation Information out of the URL bar

2019-09-07 Thread Matt Palmer via dev-security-policy
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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

2019-09-04 Thread Matt Palmer via dev-security-policy
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 CAs to describe > > the

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

2019-09-04 Thread Matt Palmer via dev-security-policy
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 >

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

2019-08-29 Thread Matt Palmer via dev-security-policy
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

Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

2019-08-28 Thread Matt Palmer via dev-security-policy
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 register a company and get

Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

2019-08-26 Thread Matt Palmer via dev-security-policy
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

Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

2019-08-18 Thread Matt Palmer via dev-security-policy
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

Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

2019-08-18 Thread Matt Palmer via dev-security-policy
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 are merely > > modifying their

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

2019-08-17 Thread Matt Palmer via dev-security-policy
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 >

Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

2019-08-17 Thread Matt Palmer via dev-security-policy
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?

Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

2019-08-17 Thread Matt Palmer via dev-security-policy
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

  1   2   3   >