RE: DigiCert ROCA fingerprint incident report

being issued. Kurt On Tue, Nov 07, 2017 at 06:20:53PM +, Jeremy Rowley via dev-security-policy wrote: > 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

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

ubject: Re: DigiCert ROCA fingerprint incident report Hi Jeremy, Have all these certificates been submitted to CT? Thanks! Alex On Tue, Nov 7, 2017 at 1:20 PM, Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists

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: 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: 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: 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: 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

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: 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: 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

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

ow? On Fri, Jun 1, 2018 at 3:38 PM, Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org> > wrote: 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 revo

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: 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: Namecheap refused to revoke certificate despite domain owner changed

validated under .5. Would Richard now need to hire a lawyer to say they own their domain name now? On Fri, Jun 1, 2018 at 3:38 PM, Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org> > wrote: This is one of the reasons I think we should require an OID spec

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: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

I think this raises a question on what level of investigation and assumption is required by the ca. Let's encrypt, for example, requires submission of the private key for revocation (https://letsencrypt.org/docs/revoking/). Is simply providing a reference rather than the key sufficient? On Dec

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: 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: Possible violation of CAA by nazwa.pl

I don’t think that’s entirely accurate. People like clear guidelines on what will happen if they do x, y, or z. This applies to both revocation and distrust. Historically, there’s times when a CA must revoke the certs and times where the browsers don’t require revocation. This leads 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: 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:

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?

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?

t: Re: How do you handle mass revocation requests? On Wed, Feb 28, 2018 at 12:37 PM, Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote: On February 2nd, 2018, we received a request fro

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

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

RE: How do you handle mass revocation requests?

Subject: Re: How do you handle mass revocation requests? On Wed, 28 Feb 2018 20:03:51 + Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > The keys were emailed to me. I'm trying to get a project together > where we self-sign a cert with each

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

Posted to cab forum accidentally instead of Mozilla dev Begin forwarded message: From: Jeremy Rowley > Date: February 28, 2018 at 2:33:41 PM MST To: Ryan Sleevi >, Geoff Keating

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?

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 third-party use cases vs. non-approved use cases. In fact, I'd postulate there's nothing wrong with Trustico holding the private keys if they were hosting the

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: 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: 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

dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: RAs and the BRs On Tue, Apr 17, 2018 at 9:21 PM, Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote: There is a wa

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-

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: 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

x [1] https://crt.sh/?id=351449246 [2] https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt On Mon, Mar 12, 2018 at 7:28 PM, Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > Thanks Alex. Sorry for the delayed response. I've been traveling today.

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: Google Trust Services Root Inclusion Request

Oh – I totally agree with you on the Google inclusion issue. Google meets the requirements for inclusion in Mozilla’s root policy so there’s no reason to exclude them. They have an audited CPS, support a community broader with certs than just Google, and have operated a CA without problems in

RE: Google Trust Services Root Inclusion Request

Maybe Jake’s opinion is not being discarded as readily as I supposed. However, Jake’s last message left me disturbed that he didn’t feel listened to. Apologies if I’m overblowing the issue, which are definitely hypothetical at this point. I did want Jake to feel like his input is an important

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

is in a personal capacity) On Wed, Sep 26, 2018 at 12:10 AM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org> > wrote: Jake's concern is legit if you believe certain assumptions. Criticizing his rationale doesn't seem correct, especially since Google does indeed have

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: 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 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

Palmer ; mozilla-dev-security-policy Subject: Re: Underscore characters I'm not sure if you're allowed to state this publicly. Has Microsoft giving you the go ahead? On Fri, Dec 28, 2018 at 1:05 AM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org

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

e second", but without any details about how or why, >or the steps being taken to ensure no deadlines are missed in the future, >doesn't really inspire confidence, and is exactly the same kind of feedback >that would be given post-incident. On Thu, Dec 27, 2018 at 1:50 PM Jeremy Rowle

RE: Underscore characters

The risk Matt identified is too nebulous of an issue to address, tbh. How do you address a moral issue? The only way I can think of to address the moral issue is to say “we promise to be good”. But the weight that carries depends on how much you trust the actor. If you trust the actor, then

RE: Underscore characters

The risk is primarily outages of major sites across the web, including certs used in Google wallet. We’re thinking that is a less than desirable result, but we weren’t sure how the Mozilla community would feel/react. We’re still considering revoking all of the certs on Jan 15th based on these

RE: Underscore characters

cy@lists.mozilla.org Subject: Re: Underscore characters On Fri, Dec 28, 2018 at 12:12:03AM +0000, 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

> 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: Transfer of QuoVadis to DigiCert

do you anticipate making? Will QuoVadis roots end up under the DigiCert CP/CPS? - Wayne On Tue, Jan 15, 2019 at 12:27 AM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> wrote: Hey all, You may have seen that DigiCert is purchasing the QuoVadis PK

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:

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

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: 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

RE: Underscore characters

I can break down the date by customer. April 30 was the last date for all customers. The actual revocation occurs sometime between Jan 15th and April 30th (still working on a per cert basis to determine this). Note that we actually have the 30 day option available and are recommending it as a

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

Hey all, Here’s the first of the companies. Figured I’d do one and see if it has the information you want. https://bugzilla.mozilla.org/show_bug.cgi?id=1515788 I think this answers all of your questions (except Ryan’s question about remediation). Could you let me know if more

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

11:13 AM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org> > wrote: Hey Matt, The trust stores are always free to ignore the CAB Forum mandates and make their own rules. Mozilla has in the past (see the Mozilla audit criteria exception for other aud

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: 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: 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: DigiCert Assured ID Root CA and Global Root CA EV Request

* The TERENA SSL CA 3 subordinate has misissued a number of certificates [3], most of which are not revoked. - We can revoke these. I have no issue remediating them. I didn’t realize these were an ongoing concern. * DigiCert’s response in this bug states “We were under the impression

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

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: CA Communication: Underscores in dNSNames

Communication: Underscores in dNSNames On Fri, Dec 7, 2018 at 2:00 PM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org> > wrote: This isn't a CA-issue because the risk associated with non-compliance isn't defined yet. https://www.mozilla.org/en-US

RE: CA Communication: Underscores in dNSNames

in dNSNames On Fri, Dec 7, 2018 at 2:00 PM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org> > wrote: This isn't a CA-issue because the risk associated with non-compliance isn't defined yet. https://www.mozilla.org/en-US/about/governance/policies/se

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: AlwaysOnSSL web security issues

that we should be terribly worried about. I would encourage DigiCert to ask CertCenter to discontinue the practice of generating private keys for their customers. - Wayne On Thu, Jan 10, 2019 at 11:00 AM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>>

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: Underscore characters

ue for them, or their CA, in the first place. CAs that aren't able to demonstrate steps towards that in future discussions are unlikely to be looked upon too favorably if there are future incident reports. On Tue, Dec 18, 2018 at 5:43 PM Jeremy Rowley via dev-security-policy mailto:dev-security-po

RE: Underscore characters

er becomes an issue for them, or their CA, in the first place. CAs that aren't able to demonstrate steps towards that in future discussions are unlikely to be looked upon too favorably if there are future incident reports. On Tue, Dec 18, 2018 at 5:43 PM Jeremy Rowley via dev-security-policy mailto

RE: Underscore characters

CAs to take clear steps to work to resolve these issues with their customers, so that it never becomes an issue for them, or their CA, in the first place. CAs that aren't able to demonstrate steps towards that in future discussions are unlikely to be looked upon too favorably if there are future

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: 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: 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

, 2019 at 10:52 PM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org> > wrote: Hi Cynthia, We've figured out what happened with your certificate but are still looking at whether other certificates were issued using the same process. I don't have

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 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: 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

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: Pre-Incident Report - GoDaddy Serial Number Entropy

No one wants to paint a target on their back. If I announce we're 100% compliant with everything, that's asking to be shot in the face. You're welcome to look at ours. I think we fully comply with 7.1 (I've double checked everything) and would love to find out if we're not. I like the feedback and

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: Pre-Incident Report - GoDaddy Serial Number Entropy

solutions that move us in that direction. - Wayne [1] https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation On Fri, Mar 8, 2019 at 3:40 PM Ryan Sleevi via dev-security-policy mailto:dev-security-policy@lists.mozilla.org> > wrote: On Fri, Mar 8, 2019 at 4:35 PM Jeremy Rowley

RE: GoDaddy Revocation Disclosure

One item that I think could bear a useful discussion from these incident reports is how the community can get more involved in discussing and helping with incident reports. For example, the 63 bit serial number issue is leading to a lot of certs potentially being revoked with little benefit to

RE: GoDaddy Revocation Disclosure

the incident. Jeremy From: Ryan Sleevi Sent: Tuesday, March 12, 2019 2:31 PM To: Jeremy Rowley Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: GoDaddy Revocation Disclosure On Tue, Mar 12, 2019 at 4:17 PM Jeremy Rowley via dev-security-policy mailto:dev-security

RE: Arabtec Holding public key? [Weird Digicert issued cert]

I don't mind filling in details. We have a system that permits creation of certificates without a CSR that works by extracting the key from an existing cert, validating the domain/org information, and creating a new certificate based on the contents of the old certificate. The system was

RE: Arabtec Holding public key? [Weird Digicert issued cert]

shutting off the no-CSR path because we figured the issuance of these certs created a potential PR concern, even if there isn't a real security risk. -Original Message- From: dev-security-policy On Behalf Of Jeremy Rowley via dev-security-policy Sent: Friday, April 12, 2019 10:56 AM

RE: Arabtec Holding public key? [Weird Digicert issued cert]

A possibility. They could have pasted something in the root chain. Note that the required handshake would have caught that if it'd been implemented. Overall it doesn't matter too much if was malicious or innocent, the cert holder can't do anything without the private key. -Original

RE: Arabtec Holding public key? [Weird Digicert issued cert]

path because we figured the issuance of these certs created a potential PR concern, even if there isn't a real security risk. -Original Message- From: dev-security-policy mailto:dev-security-policy-boun...@lists.mozilla.org> > On Behalf Of Jeremy Rowley via dev-security-policy Sent: F

<    1   2   3   >