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 m
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 Mozilla
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.
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
ough 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 at 1:05 PM Jeremy Rowley via dev-security-policy
> <mailto:
have 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
attempting to
> 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).
>
&g
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
Subje
: 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 f
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 m
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 contro
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: mozilla-dev-secur
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, in
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 me
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
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 website
>> 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 r
> 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 i
concrete and quantifiable steps as to how to improve.
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
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
o: dev-security-policy@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 op
formation the company 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
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 dev
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
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
i
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
pects from these incident reports timing-wise.
-Original Message-----
From: dev-security-policy On
Behalf Of Jeremy Rowley via dev-security-policy
Sent: Thursday, December 27, 2018 11:47 AM
To: r...@sleevi.com
Cc: dev-security-policy@lists.mozilla.org
Subject: RE: Underscore characters
The
: Ryan Sleevi
Sent: Thursday, December 27, 2018 11:24 AM
To: Jeremy Rowley
Cc: r...@sleevi.com; dev-security-policy@lists.mozilla.org
Subject: Re: Underscore characters
On Wed, Dec 26, 2018 at 1:03 PM Jeremy Rowley mailto:jeremy.row...@digicert.com> > wrote:
Much better to trea
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
Behalf Of Matt Palmer via dev-security-policy
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 +, Jeremy Rowley via dev-security-policy
wrote:
> Hereâs the first of the companies. Figured Iâd
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-
F
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 y
: 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 incid
eremy 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
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
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
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
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 a
We're looking at the feasibility of replacing the certificates with
underscore characters by Jan 15th. Revoking all of the certificates will
cause pretty bad outages. We're prepared to revoke them but would like to
discuss (before the date) what should happen if we don't revoke. There are
about 15
l s/MIME policy.
Thanks Wayne. I can 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
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 policy?
018 at 5:54 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 an
Now that the Symantec TLS distrust is essentially behind us, we're working
on migrating all of the s/MIME certificates to DigiCert hierarchies. Once
this is complete, the browsers can remove the legacy Symantec roots
completely. In my new compliance role, I'm looking at how to create a
smooth, but
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 du
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, Decemb
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
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 in
isk is a loss of the
root...probably less so. Pushing the question back to the CA without better
discussion by the browsers makes finding a solution or understanding the
risks impossible.
-Original Message-
From: dev-security-policy On
Behalf Of Jeremy Rowley via dev-security-policy
Sent
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
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 pos
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
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
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
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 in
Jake's concern is legit if you believe certain assumptions. Criticizing his
rationale doesn't seem correct, especially since Google does indeed have a
root store. Although not traditional, Google runs a store of blacklisted CAs
(see Symantec), which is every bit as effective as controlling CA compl
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: dev-security-policy@
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
con
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
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 timeline
We want to share the latest update on the Symantec distrust plan and seek
input from the community. Below is a high level summary:
The majority of root program operators plan to either partially or fully
distrust Symantec roots by Q3 CY 2018, and no later than Q2 CY 2019. All
TLS certificates
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.
>
, 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&g
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 in the
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
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 wo
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: mozilla-dev-secu
*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 Thay
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 ser
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: Tuesday, April 24, 2018 7:12 AM
To: mozilla-dev-security-pol...@lists.mozi
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
Sent: Wednesday, April 18, 2018 1:18 PM
To: Jeremy Rowley
Cc: mozilla-dev-security-policy
Subject: Re: RAs and the BRs
On Tue
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
cynical
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 ce
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-
From:
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 C
ng 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
Sent: Monday, March 12, 2018 6:55 PM
To: Jeremy Rowley
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert .oni
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 dev-security-policy wrote:
>> Wayne and I have posted a M
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 descript
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 hour
as 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 third-pa
Posted to cab forum accidentally instead of Mozilla dev
Begin forwarded message:
From: Jeremy Rowley
mailto:jeremy.row...@digicert.com>>
Date: February 28, 2018 at 2:33:41 PM MST
To: Ryan Sleevi mailto:sle...@google.com>>, Geoff Keating
mailto:geo...@apple.com>>
Cc: CA/Br
Yep - that was you. Thanks a ton. We posted 10 CSRs so far. Is this what you
were thinking?
-Original Message-
From: Nick Lamb
Sent: Wednesday, February 28, 2018 2:37 PM
To: dev-security-policy@lists.mozilla.org
Cc: Jeremy Rowley
Subject: Re: How do you handle mass revocation requests
ring 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.
>
>
>
> On Feb
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 t
om of the
community in what we do.
Iâm happy to share any of the details I can.
Jeremy
From: Ryan Sleevi
Sent: Wednesday, February 28, 2018 11:58 AM
To: Jeremy Rowley
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: How do you handle mass revocation requests?
---
From: Peter Bowen
Sent: Wednesday, February 28, 2018 12:14 PM
To: Jeremy Rowley
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-policy
wrote:
> Once we were alerte
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 p
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 e
I was planning on posting something about this later today. Give me a couple
hours to drink a lot of caffeine, and I'll update the entire community.
-Original Message-
From: dev-security-policy
On Behalf Of Richard Moore via dev-security-policy
Sent: Wednesday, February 28, 2018 6:43 AM
T
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
Cc: mozilla-d
Iâm pretty sure EA revoked the cert.
> On Dec 25, 2017, at 9:23 AM, Hanno Böck wrote:
>
> On Mon, 25 Dec 2017 14:43:21 +
> Jeremy Rowley via dev-security-policy
> wrote:
>
>> Without the private key, im not sure how we're supposed to confirm
>> key
mU5G8b_nfn9Hilet-VRsCIqD2QrmBC8XvVEQJ1FYtdHiQVDvhxWG-dP8Or2sZg7A3vFdA%3D%3D&u=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
compromise.
___
de
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 account.
>
> the public certificate is atta
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
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 certi
...@sleevi.com;
douglas.beat...@gmail.com; mozilla-dev-security-pol...@lists.mozilla.org; Paul
Wouters ; Ben Laurie ; Jeremy Rowley
Subject: Re: Anomalous Certificate Issuances based on historic CAA records
Right, and to my point:
Each transparency mechanism has to be specific to the
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
Cc: douglas.beat...@gmail.com; mozilla-dev-security-pol
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
2017-
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 f
IMO - This is the correct interpretation. Yourca could disuse the wildcard
cert for *.example.com but could not issue a cert with multiple SANs containing
both *.example.com and example.com.
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=
We had a conversation with the tg registry, and it looks like the TLD was
compromised until Nov 10. Here's a snippet:
TG Registry (FR): Nous sommes C.A.F.E Informatique & Télécommunications,
gestionnaire technique du .tg. Nous rĂ©pondons Ă vos requĂȘtes avec l'accord
de l'ART&P, le gestionnaire admi
101 - 200 of 465 matches
Mail list logo
