elop more 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
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.
, 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
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
PS changes 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 Q
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
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>>
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
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 the
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.m
o: dev-security-policy@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 op
is. The statement "We'll miss the first
>deadline, but we'll hit the 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 feedb
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
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 d
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
The original incident report contained all of the details of the initial
filing. The additional, separated reports are trickling in as I get enough
info to post something in reply to the updated questions. As the questions
asked have changed from the original 7 in the Mozilla incident report, g
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 audits
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
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 detail
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
r
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
out of it, having the same
conversations we've been having in 2018. The best way to prevent that is for
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 dem
that is for
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
ssues 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 incident
reports.
On Tue, Dec 18, 2018 at 5:
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
* 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 fro
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
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
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/p
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
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 pa
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 th
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 do
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
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 confusi
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
.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 specifying the
vali
ertificate 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 a
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
, Apr 17, 2018 at 9:21 PM, Jeremy Rowley via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org> > wrote:
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
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
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
wrote:
> Thanks Alex. Sorry for the delayed response. I've been traveling today.
> We're reaching out to each of the customers and getting th
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/Browser Forum Public Dis
?
On Wed, 28 Feb 2018 20:03:51 +
Jeremy Rowley via dev-security-policy
wrote:
> 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
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
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
On Wed, Feb 28, 2018 at 12:37 PM, Jeremy Rowley via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org> > wrote:
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, th
---
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
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
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
I think we can be more transparent about CAA records without requiring CT. I
donât have a solution, but more transparency about processing CAA records
couldnât hurt.
From: Ryan Sleevi [mailto:r...@sleevi.com]
Sent: Thursday, November 30, 2017 3:12 PM
To: Tim Hollebeek
Cc: Wayne Thayer ; r..
...@lists.mozilla.org
Subject: Re: Anomalous Certificate Issuances based on historic CAA records
This whole conversation makes me wonder if CAA Transparency should be a thing.
On 29 November 2017 at 20:44, Jeremy Rowley via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org
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 314 matches
Mail list logo