RE: Pre-Incident Report - GoDaddy Serial Number Entropy

and cons of doing so. From: Wayne Thayer Sent: Friday, March 8, 2019 3:46 PM To: Ryan Sleevi Cc: Jeremy Rowley ; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Pre-Incident Report - GoDaddy Serial Number Entropy Ryan beat me to the punch. so I'll reinforce his message with my own

RE: Pre-Incident Report - GoDaddy Serial Number Entropy

If they need some help with large scale replacement, I know some people who did that recently . Joking of course, but really - with Godaddy, Google, and Apple reporting a large number of certs that have what seems to be a minor compliance issue in light of the certs all being SHA2, does

RE: Possible DigiCert in-addr.arpa Mis-issuance

Technically, the same issue could exist on the system. However, co.uk is actually blocked as a valid approval address by our system. In-addr.arpa was not blocked. Here's a status update: 1) We identified 3000 certificates where the scope was changed by validation staff based on a WHOIS document.

RE: Possible DigiCert in-addr.arpa Mis-issuance

Thanks Wayne From: Wayne Thayer Sent: Friday, March 1, 2019 10:00 AM To: Jeremy Rowley Cc: mozilla-dev-security-policy Subject: Re: Possible DigiCert in-addr.arpa Mis-issuance https://bugzilla.mozilla.org/show_bug.cgi?id=1531817 has been created to track this issue. On Wed, Feb 27

RE: Possible DigiCert in-addr.arpa Mis-issuance

st name for resolution. I wonder whether this isn't a case > that should just be treated as an invalid domain for purposes of SAN > dnsName (like .local). > > On Tue, Feb 26, 2019 at 1:05 PM Jeremy Rowley via dev-security-policy > <mailto:dev-security-policy@lists.mozilla.o

RE: Possible DigiCert in-addr.arpa Mis-issuance

happened to any domain and not just in-addr.arpa? - Cynthia On 2019-02-27 01:55, Jeremy Rowley via dev-security-policy wrote: > From our side, a validation agent weirdly scoped the domain, saying that the > domain was approved using an email to ad...@in-addr.arpa. However, the email >

RE: Possible DigiCert in-addr.arpa Mis-issuance

t; utilize a reverse-IP formatted in-addr.arpa address as though it were > a normal host name for resolution. I wonder whether this isn't a case > that should just be treated as an invalid domain for purposes of SAN > dnsName (like .local). > > On Tue, Feb 26, 2019 a

Re: Possible DigiCert in-addr.arpa Mis-issuance

Thanks Cynthia. We are investigating and will report back shortly. From: dev-security-policy on behalf of Cynthia Revström via dev-security-policy Sent: Tuesday, February 26, 2019 12:02:20 PM To: dev-security-policy@lists.mozilla.org Cc: b...@benjojo.co.uk

RE: DarkMatter Concerns

: dev-security-policy On Behalf Of Jeremy Rowley via dev-security-policy Sent: Monday, February 25, 2019 1:43 PM To: Buschart, Rufus ; mozilla-dev-security-policy Subject: RE: DarkMatter Concerns Hi all, Sorry for the delayed response. Been traveling and haven't had a chance to properly format

RE: DarkMatter Concerns

If DarkMatter is issuing from a CA that chains to a Quovadis root trusted by Mozilla, the issuance is in scope of the Mozilla policy. But that also means the cert is publicly trusted. Thus, I read it as "all TLS certs issued from the public ICA are publicly logged", which matches what Scott told

RE: DarkMatter Concerns

Hi all, Sorry for the delayed response. Been traveling and haven't had a chance to properly format my thoughts until now. As you all know, DigiCert recently acquired the Quovadis CA. As the operator of the CA, DigiCert is responsible for the issuing CA controlled by DarkMatter. DarkMatter

Re: Transfer of QuoVadis to DigiCert

We havent discussed any root removal yet internally. However, we definitely wont be removing the ones used for qwacs. From: dev-security-policy on behalf of westmail24--- via dev-security-policy Sent: Thursday, January 17, 2019 6:55:23 AM To:

RE: Transfer of QuoVadis to DigiCert

term, we plan on operating Quovadis under its existing CPS and with its existing practices. From: Wayne Thayer Sent: Tuesday, January 15, 2019 9:10 AM To: Jeremy Rowley Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Transfer of QuoVadis to DigiCert Thanks Jeremy. To be clear

Transfer of QuoVadis to DigiCert

Hey all, You may have seen that DigiCert is purchasing the QuoVadis PKI from WISeKey, including all public root operations. With the closing date drawing closer, I wanted to start the discussion and give the Mozilla community the notice required under Section 8 of the Mozilla CA policy. Let

RE: AlwaysOnSSL web security issues

Yes – we will do so. We’ve encouraged all customers to not generate key pairs for TLS certs on behalf of third parties in the past. A reminder would be useful. From: Wayne Thayer Sent: Thursday, January 10, 2019 1:18 PM To: Jeremy Rowley Cc: Alex Gaynor ; Buschart, Rufus ; Alex Cohn ; Hanno

RE: AlwaysOnSSL web security issues

A couple of thoughts: 1) CertCenter is not a CA or RA. They have a custom named ICA that is hosted and operated by DigiCert. All validation, issuance, and linting is performed by DigiCert prior to issuance. 2) Lots of cert customers have insecure websites. This indicates CAs should scan

RE: Underscore characters

>> I think Matt provided a pretty clear moral hazard here - of customers >> suggesting their CAs didn't do enough (e.g. should have tried harder to >> intentionally violated by not revoking). One significant way to mitigating >> that risk is to take meaningful steps to ensure that "We couldn't

RE: Underscore characters

> I don't think there's *any* result from all this that everyone would > consider desirable -- otherwise we wouldn't need to have this conversation. + 1 to that. > I'm not sure I'd call it "leniency", but I think you're definitely asking > for "special treatment" -- pre-judgment on a potential

RE: Underscore characters

rove. Thanks Ryan. This post was really nice. Appreciate it. From: Ryan Sleevi Sent: Thursday, December 27, 2018 7:15 PM To: Jeremy Rowley Cc: James Burton ; Ryan Sleevi ; mozilla-dev-security-policy Subject: Re: Underscore characters On Thu, Dec 27, 2018 at 6:56 PM Jeremy Rowley

RE: Underscore characters

Treading carefully… Mozilla is the only browser related to the discussion. Probably sufficient to say that the revocation/no-revoke decision is entirely dependent on the results of this thread. From: James Burton Sent: Thursday, December 27, 2018 6:07 PM To: Jeremy Rowley Cc: Matt

RE: Underscore characters

cy@lists.mozilla.org Subject: Re: Underscore characters On Fri, Dec 28, 2018 at 12:12:03AM +, Jeremy Rowley via dev-security-policy wrote: > This is very helpful. If I had those two options, we'd just revoke all > the certs, screw outages. Unfortunately, the options are much broader th

RE: Underscore characters

ompany has provided should be the guiding light? From: Ryan Sleevi Sent: Thursday, December 27, 2018 1:16 PM To: Jeremy Rowley Cc: mozilla-dev-security-policy Subject: Re: Underscore characters I'm not trying to throw you under the bus here, but I think it's helpful if you could hi

RE: Use cases of publicly-trusted certificates

It clearly wasn't understood by everyone. That's why we had two ballots on it, one of them failing to address the issue. You can just look through the long discussions on the topic to see people didn't agree. -Original Message- From: dev-security-policy On Behalf Of Jakob Bohm via

RE: Underscore characters

This is very helpful. If I had those two options, we'd just revoke all the certs, screw outages. Unfortunately, the options are much broader than that. If I could know what the risk v. benefit is, then you can make a better decision? DigiCert distrusted - all revoked. DigiCert gets some mar on its

RE: Underscore characters

This is accurate. We have the technical capability and policy ability to revoke the certificates. What we were hoping was a discussion based on impact of the revocation so we could hear what we should do. Blind obedience isn't my favorite answer, but it's an option. The guidance so far is file an

RE: Underscore characters

so far. The response from the browsers is public - that they cannot make that determination. Does that mean we have our answer? Revoke is the only acceptable response? From: James Burton Sent: Thursday, December 27, 2018 2:24 PM To: Ryan Sleevi Cc: Jeremy Rowley ; mozilla-dev-security

RE: Underscore characters

to do to mitigate when we miss the Jan 15ht deadline?” instead. Apologies for the confusion there. Jeremy From: Ryan Sleevi Sent: Wednesday, December 26, 2018 10:00 AM To: Jeremy Rowley Cc: dev-security-policy@lists.mozilla.org Subject: Re: Underscore characters On Wed, Dec 26, 2018 at

RE: Underscore characters

olicy Sent: Thursday, December 20, 2018 4:54 PM To: dev-security-policy@lists.mozilla.org Subject: Re: Underscore characters On Thu, Dec 20, 2018 at 10:34:21PM +0000, Jeremy Rowley via dev-security-policy wrote: > Here’s the first of the companies. Figured I’d do one and see if it has the > info

RE: Statement on the Sunset of Underscore Characters

But this part isn't true "Browsers are not capable of granting 'exceptions' to the Baseline Requirements", at least for Mozilla. See the Mozilla auditor requirements for example. Perhaps better stated that they don't have to implement the standards they don't like? -Original Message-

RE: Underscore characters

detail is required or if you’d like additional info included? Thanks! Jeremy From: Wayne Thayer Sent: Thursday, December 20, 2018 12:25 PM To: Ryan Sleevi Cc: Jeremy Rowley ; mozilla-dev-security-policy Subject: Re: Underscore characters Jeremy, It's good to hear that you do

RE: Underscore characters

To: Ryan Sleevi Cc: Jeremy Rowley ; mozilla-dev-security-policy Subject: Re: Underscore characters Jeremy, It's good to hear that you do believe you can provide the necessary level of information prior to 15-Jan. Given that, I'm now thinking of this as if it were a normal incident except

RE: Underscore characters

Rowley Cc: r...@sleevi.com; mozilla-dev-security-policy Subject: Re: Underscore characters Jeremy, On Wed, Dec 19, 2018 at 10:55 PM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org> > wrote: Done: https://bugzilla.mozilla.org/show_bug.cgi?id=1

RE: Underscore characters

Done: https://bugzilla.mozilla.org/show_bug.cgi?id=1515564 It ended up being about 1200 certs total that we are hearing can’t be replaced because of blackout periods. From: Ryan Sleevi Sent: Wednesday, December 19, 2018 11:05 AM To: Jeremy Rowley Cc: r...@sleevi.com; mozilla-dev

RE: Underscore characters

about what the risk associated with underscore characters is. Could you please explain the risk to the community in a revocation delay as the “unreasonable” argument isn’t really supported without that understanding. From: Ryan Sleevi Sent: Wednesday, December 19, 2018 7:17 AM To: Jeremy Rowley

RE: Underscore characters

, but I doubt it materially alters the conversation and outcome. From: Ryan Sleevi Sent: Tuesday, December 18, 2018 7:35 PM To: Jeremy Rowley Cc: mozilla-dev-security-policy Subject: Re: Underscore characters Jeremy, It seems like any answer for what it "might" look li

RE: Underscore characters

The total number of certs impacted is about 2200. Just more info. -Original Message- From: dev-security-policy On Behalf Of Jeremy Rowley via dev-security-policy Sent: Tuesday, December 18, 2018 3:28 PM To: mozilla-dev-security-policy Subject: Underscore characters We're looking

RE: DigiCert Assured ID Root CA and Global Root CA EV Request

confirm we will revoke all mis-issued certs. From: Wayne Thayer Sent: Thursday, December 13, 2018 5:34 PM To: Jeremy Rowley Cc: Ryan Sleevi ; mozilla-dev-security-policy Subject: Re: DigiCert Assured ID Root CA and Global Root CA EV Request My main concern with this request

RE: s/MIME certs and authentication

This is one of the reasons I wanted to raise the issue. Issuing the cert and delivering to the email seems like a pretty common way to verify email certs (either you have access to the email or you don't), but this is backwards from TLS. Is this particular process a violation of the Mozilla

RE: Underscore characters and DigiCert

4 PM Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hey all, > > We're working towards revoking certs with underscore characters in the > domain name, per SC12, but I had a question about legacy Symantec > systems and Mozill

Underscore characters and DigiCert

Hey all, We're working towards revoking certs with underscore characters in the domain name, per SC12, but I had a question about legacy Symantec systems and Mozilla. These particular roots are no longer trusted for TLS certs in Google or Mozilla, which means the applicability of the BRs is

Re: SSL private key for *.alipcsec.com embedded in PC client executables

I think pretty much every ca will accept a signed file in lieu of an actual key. Generally provide the key just means some proof of compromise the ca can replicate. From: dev-security-policy on behalf of Matt Palmer via dev-security-policy Sent: Monday,

RE: CA Communication: Underscores in dNSNames

because the CA isn’t operational anymore. Telling people to go have the CA cover the risk when those are the two options seems like we’re avoiding the public discussion. From: Ryan Sleevi Sent: Friday, December 7, 2018 2:26 PM To: Jeremy Rowley Cc: mozilla-dev-security-policy Subject: Re: CA

RE: CA Communication: Underscores in dNSNames

That’s not well defined as there are various grades below that. Is the plan to remove any CA that doesn’t comply with this requirement? From: Ryan Sleevi Sent: Friday, December 7, 2018 2:26 PM To: Jeremy Rowley Cc: mozilla-dev-security-policy Subject: Re: CA Communication: Underscores

Re: CA Communication: Underscores in dNSNames

Personally, i think you should continue the discussion here. Although you can bring it up to whichever ca you use, the reality is that without the browsers knowing why the certs cant be replaced and the number, theres no way to gauge their reaction to a non compliance. The penalties may include

RE: DigiCert Assured ID Root CA and Global Root CA EV Request

We can revoke them all by then. The question is do the browsers really want us to? Since we started a public discussion, here's the details: There are several prominent websites that use certs with underscore characters in connection with major operations. I was hoping to get permission to

DigiCert incident report

Hi all, We issued a single certificate that contained an internal domain. This certificate was discovered on Oct 16th and revoked on the 17th. We filed the bug report here: https://bugzilla.mozilla.org/show_bug.cgi?id=1500621 but are also posting the list for awareness. Tl;dr. Two validation

RE: Google Trust Services Root Inclusion Request

part of this discussion board. Not saying anyone made him feel otherwise intentionally of course, but his last message seemed frustrated. From: Ryan Sleevi Sent: Wednesday, September 26, 2018 10:49 AM To: Jeremy Rowley Cc: Ryan Sleevi ; mozilla-dev-security-policy Subject: Re: Google Trust

RE: Google Trust Services Root Inclusion Request

raised. From: Wayne Thayer Sent: Wednesday, September 26, 2018 3:39 PM To: Ryan Sleevi Cc: Jeremy Rowley ; mozilla-dev-security-policy Subject: Re: Google Trust Services Root Inclusion Request I'm disputing the conclusion that is being drawn from Jake's concerns, rather than

RE: Google Trust Services Root Inclusion Request

I also should also emphasize that I’m speaking as Jeremy Rowley, not as DigiCert. Note that I didn’t say Google controlled the policy. However, as a module peer, Google does have significant influence over the policy and what CAs are trusted by Mozilla. Although everyone can participate

RE: New certificate from compromised key

Thanks. We've revoked the cert and are looking into what happened and will post more information as we figure out what happened. -Original Message- From: dev-security-policy On Behalf Of Hanno Böck via dev-security-policy Sent: Friday, August 17, 2018 7:16 PM To:

Issuance with improper domain validation

I posted this to Bugzilla last night. Basically, we had an issue with validation that resulted in some certs issuing without proper (post-Aug 1) domain verification. Still working out how many. The major reason was lack of training by the validation staff combined with a lack of strict document

RE: Possible violation of CAA by nazwa.pl

with the browser and public From: Ryan Sleevi Sent: Saturday, July 28, 2018 8:25 PM To: Jeremy Rowley Cc: Jakob Bohm ; Tim Hollebeek ; mozilla-dev-security-pol...@lists.mozilla.org; r...@sleevi.com Subject: Re: Possible violation of CAA by nazwa.pl On Sat, Jul 28, 2018 at 2:17 PM Jeremy

RE: Possible violation of CAA by nazwa.pl

I think the desire to categorize these is more to make sense of where the distrust line is. No one wants to end up on the same boat as Symantec, and there aren't clear guidelines on how to prevent that from happening to a CA. Pretty much every CA mis-issues at some point on an infinite

Re: Disallowed company name

Punctuation differences are not enough to register a name in the us, or at least in the jurisdictions here I’m aware of. > On Jun 4, 2018, at 1:04 AM, Ryan Hurst via dev-security-policy > wrote: > > I apologize, I originally wrote in haste and did not clearly state what I > was suggesting.

RE: Namecheap refused to revoke certificate despite domain owner changed

June 1, 2018 5:17 PM To: Jeremy Rowley Cc: mozilla-dev-security-policy ; Jakob Bohm ; Wayne Thayer Subject: Re: Namecheap refused to revoke certificate despite domain owner changed On Fri, Jun 1, 2018 at 2:38 PM, Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org

RE: Namecheap refused to revoke certificate despite domain owner changed

the CA from supporting it. From: Ryan Sleevi Sent: Friday, June 1, 2018 4:08 PM To: Jeremy Rowley Cc: r...@sleevi.com; Wayne Thayer ; Jakob Bohm ; mozilla-dev-security-policy Subject: Re: Namecheap refused to revoke certificate despite domain owner changed Yes, as mentioned

RE: Namecheap refused to revoke certificate despite domain owner changed

Which is yet another reason why removing method 1 and method 5 was a good idea. Do any of the other methods share the same problem? Maybe IP address verification right now. From: Ryan Sleevi Sent: Friday, June 1, 2018 2:51 PM To: Jeremy Rowley Cc: Wayne Thayer ; Jakob Bohm ; mozilla-dev

RE: Namecheap refused to revoke certificate despite domain owner changed

This is one of the reasons I think we should require an OID specifying the validation method be included in the cert. Then you can require the CA support revocation using the same validation process as was used to confirm certificate authorization. With each cert logged in CT, everyone in the

RE: Disallowed company name

Can you point to a jurisdiction that allows you to register the same name? I've never seen an example where it's permitted. Maybe the UK? -Original Message- From: dev-security-policy On Behalf Of Ryan Hurst via dev-security-policy Sent: Friday, June 1, 2018 9:28 AM To:

Re: Disallowed company name

*Some cas. I don’t think the 18 month requirement is a universal position and may not even be a majority view. I think there’s other ideas that are better and add more value than simply extending the time a company is required to exist to get the cert. > On May 31, 2018, at 4:40 PM, Wayne

CT Log deprecation

Hi everyone, I posted our announcement about deprecation of Symantec CT logs over on the Google list a while ago. I figured I'd post something here as well so the community is aware of our plans. As part of our infrastructure consolidation DigiCert will be EOLing legacy Symantec CT log

RE: Transforming a trade name into ASCII in the O field of an OV cert

That is correct. We use transliteration of non-latin names through a system recognized by ISO per Appendix D(1)(3) -Original Message- From: dev-security-policy On Behalf Of cbonnell--- via dev-security-policy Sent:

RE: RAs and the BRs

that I review the RA practices and did the 3% review (regardless of the results), then the CA escapes oversight on its validation process. From: Wayne Thayer <wtha...@mozilla.com> Sent: Wednesday, April 18, 2018 1:18 PM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: mozilla-

RAs and the BRs

There is a way to get zero-validation certs, totally legit, under the BRs. Currently, the BRs permit pretty much free delegation of Registration Authorities for everything except domain verification. Without RA audit requirements or even a requirement that the CA monitor/control the RA, the

RE: Policy 2.6 Proposal: Require CAs to support problem reports via email

I believe the intent of the certificate problem reporting in the BRs is to encourage CAs to accept and respond to issues. Although the intent is not specifically stated, my reasoning is based on the fact the BRs requiring CAs to maintain a 24x7 ability to respond, a 24 hour ability to process

RE: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)

If you don't specify by EKU, the exercise of determining intent becomes impossible as illustrated by our (many) attempts to define a server cert in CAB Forum. Better to list the EKUs allowed and not allowed in the same cert than rely on another intent requirement. -Original Message-

RE: DigiCert .onion certificates without Tor Service Descriptor Hash extension

True. I can tell you our process was not followed in this case, primarily because of the Symantec transaction. Ideally, when we add new products (or when a CAB Forum requirement changes), we: 1. Add the mandatory criteria to our compliance engine 2. Add the new cert to our issuing

RE: DigiCert .onion certificates without Tor Service Descriptor Hash extension

it, but I doubt there's strong incentives to change the guidelines right now. We'll modify to include it. -Original Message- From: Alex Cohn <a...@alexcohn.com> Sent: Monday, March 12, 2018 6:55 PM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: mozilla-dev-security-pol...@lists

Re: Mozilla Security Blog re Symantec TLS Certs

Same question. Does this mean the key used to sign the digicert roots is subject to the distrust without exception? > On Mar 13, 2018, at 1:36 PM, Kai Engert via dev-security-policy > wrote: > >> On 12.03.2018 22:19, Kathleen Wilson via

RE: DigiCert .onion certificates without Tor Service Descriptor Hash extension

Thanks Alex. Sorry for the delayed response. I've been traveling today. We're reaching out to each of the customers and getting their cert replaced. Looking into this, we did not correctly implement the ballot: 1. We didn't add a check to our backend system too verify the cert included a

RE: How do you handle mass revocation requests?

1) Not all of the certificates being revoked use the Symantec hierarchy. There are some certs that use the DigiCert replacement hierarchy. Not many though. 2) Sorry my wording was strange. It almost always is. What I meant, is Trustico specifically asked for the certs to be revoked within 24

Re: How do you handle mass revocation requests?

ut the cause of this incident. Has DigiCert received proof of compromise of all 50k in the meantime? On 28.2.18 22:42, Jeremy Rowley via dev-security-policy wrote: We don't have a process to prevent third parties from storing private keys. I'm not sure how that would even work considering the approved

Fwd: [cabfpub] How do you handle mass revocation requests?

Posted to cab forum accidentally instead of Mozilla dev Begin forwarded message: From: Jeremy Rowley <jeremy.row...@digicert.com<mailto:jeremy.row...@digicert.com>> Date: February 28, 2018 at 2:33:41 PM MST To: Ryan Sleevi <sle...@google.com<mailto:sle...@google.com>&

RE: How do you handle mass revocation requests?

Yep - that was you. Thanks a ton. We posted 10 CSRs so far. Is this what you were thinking? -Original Message- From: Nick Lamb <n...@tlrmx.org> Sent: Wednesday, February 28, 2018 2:37 PM To: dev-security-policy@lists.mozilla.org Cc: Jeremy Rowley <jeremy.row...@digicert.com>

RE: How do you handle mass revocation requests?

place to prevent resellers from storing private keys so casually? On Wednesday, February 28, 2018 at 12:38:16 PM UTC-5, Jeremy Rowley wrote: > Hi everyone, > > > > I wanted to share an incident report regarding the revocation of > certain certificates ordered through a reseller.

RE: How do you handle mass revocation requests?

The keys were emailed to me. I'm trying to get a project together where we self-sign a cert with each of the keys and publish them. That way there's evidence to the community of the compromise without simply listing 23k private keys. Someone on Reddit suggested that, which I really appreciated. I

RE: How do you handle mass revocation requests?

isdom of the community in what we do. I’m happy to share any of the details I can. Jeremy From: Ryan Sleevi <r...@sleevi.com> Sent: Wednesday, February 28, 2018 11:58 AM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: mozilla-dev-security-pol...@lists.mozilla.org Subjec

RE: How do you handle mass revocation requests?

Bowen <pzbo...@gmail.com> Sent: Wednesday, February 28, 2018 12:14 PM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: How do you handle mass revocation requests? On Wed, Feb 28, 2018 at 9:37 AM, Jeremy Rowley via dev-security-

RE: How do you handle mass revocation requests?

I believe transparency is the best policy. I think it'd be helpful to the community if we could post the email exchange about the revocation. We can redact the agreement termination portions if you'd like, but that'd give a lot more clarity around what's going on. Do I have your permission to

How do you handle mass revocation requests?

Hi everyone, I wanted to share an incident report regarding the revocation of certain certificates ordered through a reseller. On February 2nd, 2018, we received a request from Trustico to mass revoke all certificates that had been ordered by end users through Trustico. Unfortunately, the

RE: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

BTW - this certificate was revoked. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Mark Steward via dev-security-policy Sent: Friday, December 29, 2017 11:30 AM To: Matthew Hardeman

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

I’m pretty sure EA revoked the cert. > On Dec 25, 2017, at 9:23 AM, Hanno Böck <ha...@hboeck.de> wrote: > > On Mon, 25 Dec 2017 14:43:21 + > Jeremy Rowley via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > >> Without the private

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

9HqE9sy8JeWu-_M70XHnI_NyNgcaCS24Q2mU5G8b_nfn9Hilet-VRsCIqD2QrmBC8XvVEQJ1FYtdHiQVDvhxWG-dP8Or2sZg7A3vFdA%3D%3D=https%3A%2F%2Fimgur.com%2Fv5vqedX On Monday, 25 December 2017 16:44:03 UTC+2, Jeremy Rowley wrote: Without the private key, im not sure how we're supposed to confirm key

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

Without the private key, im not sure how we're supposed to confirm key compromise. > On Dec 25, 2017, at 3:32 AM, Adrian R. via dev-security-policy > wrote: > > The BattleNet app needs to be installed and running, i am logged in with a > battlenet

RE: CA generated keys

I think key escrow services are pretty rare related to TLS certs. However, there's lots of CAs and services that escrow signing keys for s/MIME certs. Although, I'm not sure how companies can claim non-repudiation if they've escrowed the signing key, a lot of enterprises use dual-use keys and want

RE: DigiCert-Symantec Announcement

Hi everyone, We met the December 1 deadline of integrating with Symantec systems, and all validation and issuance of TLS certificates is currently flowing through DigiCert’s backend. Initial results appear generally positive, with the validation staff processing orders and delivering

RE: Anomalous Certificate Issuances based on historic CAA records

leb...@digicert.com> Cc: Wayne Thayer <wtha...@mozilla.com>; r...@sleevi.com; douglas.beat...@gmail.com; mozilla-dev-security-pol...@lists.mozilla.org; Paul Wouters <p...@nohats.ca>; Ben Laurie <b...@google.com>; Jeremy Rowley <jeremy.row...@digicert.com> Subject: Re: Anomalo

RE: Anomalous Certificate Issuances based on historic CAA records

be a more useful tools for researchers if there was a good way to make the record check results more publicly available. Jeremy From: Ben Laurie [mailto:b...@google.com] Sent: Wednesday, November 29, 2017 3:01 PM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: douglas.beat...@gma

RE: Anomalous Certificate Issuances based on historic CAA records

The Thawte records aren't showing any CAA record preventing wildcards either. Here's the Thawte CAA record logs for the domain: 2017-09-13 05:25:09.117 [pool-3058695-thread-1] [] INFO c.s.s.r.service.CAAV2CheckService - Lookup domain: trnava-vuc.sk type: 257 result: 4 lookupTimeout: 500

DigiCert/Symantec updates

Hey everyone, I wanted to give the community and update on how the DigiCert-Symantec transition is going and make everyone aware of a few issues I recently created on Bugzilla. First, the good news. DigiCert has started validating and issuing certificates through the Symantec platform

RE: DigiCert ROCA fingerprint incident report

that patch is installed, we will repeat our scans for any additional vulnerable certificates that were issued in the interim. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Jeremy Rowley via dev-security-p

RE: DigiCert ROCA fingerprint incident report

: Kurt Roeckx [mailto:k...@roeckx.be] Sent: Tuesday, November 7, 2017 11:38 AM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: DigiCert ROCA fingerprint incident report Hi, What I miss is what has been done to prevent new ones from

RE: DigiCert ROCA fingerprint incident report

I believe so – I asked that they all be logged, but I’ll need to double check whether it got done. From: Alex Gaynor [mailto:agay...@mozilla.com] Sent: Tuesday, November 7, 2017 11:23 AM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: mozilla-dev-security-pol...@lists.mozilla.org S

DigiCert ROCA fingerprint incident report

Hey everyone, Here's the DigiCert incident report about the ROCA fingerprints. Note that these were all issued by Symantec (ie, before the transaction closed). We became aware of the issue when it was posted to the mailing list. However, at that time, the certs were not operated by

RE: Incident Report : GoDaddy certificates with ROCA Fingerprint

Hey Alex - we intend to publish a report for the former Symantec certs. For now, here's what I know: 1) The scope was 15 TLS certs. We became aware of the certs through your posting. 2) We are revoking all 15 certs. I'm still waiting for their serial numbers. We kicked off the 24 hour

RE: Statement on DigiCert’s Proposed Purchase of Symantec

ity-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of Jeremy Rowley via dev-security-policy Sent: Tuesday, October 31, 2017 2:08 PM To: Gervase Markham <g...@mozilla.org>; mozilla-dev-security-pol...@lists.mozilla.org Subject: RE: Stateme

RE: DRAFT November 2017 CA Communication

Some initial thoughts 1. I'm a bit confused by bullet #2 in the survey. Wasn't it already the Mozilla policy that CAs could only use the blessed 10 methods of validation? I thought this was communicated in the previous letter? 2. On bullet #3, I'm reading the wording to mean either 1) disclosed

RE: Proposed policy change: require private pre-notification of 3rd party subCAs

Assuming the rule applies only to externally run third parties, I think it's an excellent idea, but perhaps it should be a public pre-notification? As you mentioned, the relationship will become transparent through CCDAB submission and the audit report, so what's the advantage of keeping it

RE: DigiCert-Symantec Announcement

gt; Cc: Ryan Sleevi <r...@sleevi.com>; mozilla-dev-security-pol...@lists.mozilla.org; Jeremy Rowley <jeremy.row...@digicert.com> Subject: Re: DigiCert-Symantec Announcement On Sun, Sep 24, 2017 at 12:40 PM, Peter Bowen <pzbo...@gmail.com <mailto:pzbo...@gmail.com>

RE: DigiCert-Symantec Announcement

could create one. I know my team would prefer it as the Global Trust G2 root is our primary SHA2 root. -Original Message- From: Peter Bowen [mailto:pzbo...@gmail.com] Sent: Wednesday, September 20, 2017 10:21 AM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: mozilla-dev-securi

<    1   2   3   4   >