I'm surprised any CA has heartburn over the EKU changes. Microsoft has required
them in end entity certificates for quite some time. From the MS policy:
"Effective February 1, 2017, all end-entity certificates must contain the EKU
for the purpose that the CA issued the certificate to the custome
One suggestion on incident reports is to define "regularly update" as some
period of time as non-responses can result in additional incident reports.
Maybe something along the lines of "the greater of every 7 days, the time
period specified in the next update field by Mozilla, or the time perio
Hey Wayne,
I think there might be confusion on how the notification is supposed to happen.
Is notification through CCADB sufficient? We've uploaded all of the Sub CAs to
CCADB including the technically constrained ICAs. Each one that is
hosted/operated by itself is marked that way using the Su
The CAB forum specifies that OCSP responses MUST conform to RFC5019 or RFC
6960. The requirements do not specific which RFC to follow when processing
requests, but I think you can imply that either one is required, right?
Section 2.1.1. specifies that:
Clients MUST use SHA1 as the hashing a
(And, for the record, none of that legacy infrastructure that would Ryan
mentions taking years to update exists anymore. Yay for shutting down legacy
systems!)
-Original Message-
From: dev-security-policy On
Behalf Of Jeremy Rowley via dev-security-policy
Sent: Friday, October 4, 2019
Will this permit either verification of the email address or the domain part?
For example, some organizations may verify their entire domain space and then
confirm contractors using a random value sent to the email address itself. They
don't need the entire domain space in those cases, but they
I did flag that part as wearing my personal hat š.
The Trust Italia Sub CA is an example of where confusion may arise in the
policy and where the complexity arises in these relationships. This was not
necessarily a ānewā CA from what I understood. This is also why I qualified the
shut down in 2
r
customers, such as for white label CAs.
So thatās why Iām struggling to understand the use case, or the challenges,
with at least requiring domain-part validation by the CA.
On Fri, Oct 4, 2019 at 8:09 PM Jeremy Rowley via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org>>
Are both roots trusted in the Mozilla root store? If so, could you say that
Mozilla has approved of the root not-withstanding the non-compliance? If root 2
did go through the public review process and had the public look at the
certificate and still got embedded, then Mozilla perhaps signed off
Yeah - I like the visibility here since I know I often forget to post the
incident to the Mozilla list as well as post the bug.
IMO - it's up to the CA to decide if they want to sign something in violation
of the BRs and then it's up the browsers on what the action taken in response
is. I ackn
-policy On
Behalf Of Jeremy Rowley via dev-security-policy
Sent: Monday, October 7, 2019 10:21 AM
To: r...@sleevi.com
Cc: mozilla-dev-security-policy
Subject: RE: CAs cross-signing roots whose subjects don't comply with the BRs
Yeah - I like the visibility here since I know I often forget to pos
Interesting. I can't tell with the Netlock certificate, but the other three
non-EKU intermediates look like replacements for intermediates that were issued
before the policy date and then reissued after the compliance date. The
industry has established that renewal and new issuance are identica
Speaking from a personal perspective -
This all makes sense, and, to be honest, the spectrum/grade idea isnāt a good
or robust. Implementing something like that requires too many judgment
questions about whether a CA belongs in box x vs. box y and what is the
difference between those two boxes.
Tackling Sub CA renewals/issuance from a compliance perspective is difficult
because of the number of manual components involved. You have the key ceremony,
the scripting, and all of the formal process involved. Because the root is
stored in an offline state and only brought out for a very inten
I think requiring publication of profiles for certs is a good idea. Itās part
of what Iāve wanted to publish as part of our CPS. You can see most of our
profiles here:
https://content.digicert.com/wp-content/uploads/2019/07/Digicert-Certificate-Profiles.pdf,
but it doesnāt include ICAs right no
Question, is there any prohibition against demonstration of domain control
being delegated to a third party or even the CA itself? I don't think so, but
figured we've discussed differences in interpretation a lot lately so wanted to
see if people agreed.
Section 3.2.2.4.7 in the CAB/F requires
I like this approach. You could either add a page in the policy document or
include the information in the management assertion letter (or auditor letter)
that gives information about the auditorās credentials and background. I also
like the idea of summary on what the auditor followed up on fro
A mistake in the BRs (I wrote the language unfortunately so shame on me for not
matching the other sections of org name or the given name). There's no
certificate that ever contains all of these fields. How would you ever have
that?
There's no requirement that the OU field information relate to
Jeremy Rowley via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org>>
wrote:
A mistake in the BRs (I wrote the language unfortunately so shame on me for not
matching the other sections of org name or the given name). There's no
certificate that ever contains all of these
Should anything be mentioned about the allowed algorithms? That's the largest
change to the policy and confirming the AlgorithmIdentifiers in each case may
take some time.
-Original Message-
From: dev-security-policy On
Behalf Of Wayne Thayer via dev-security-policy
Sent: Thursday, De
I think this statement is not accurate: "As a result, CAs donāt pursue
automation, or when they support it, neither promote nor require it." I know
very few CAs who want to spend extra resources on manual validations and just
as few who don't support some level of automation. The manual methods
Yes - please share the details with me as I am very surprised to hear that. I
know the DigiCert agreements I've seen don't permit revocation because of
termination so whoever (if anyone) is saying that is contradicting the actual
agreement. Threatening revocation because of termination or revok
Yeah - I've wanted to do this for a long time. If the domain is only good for
30 days, why would we issue even a 1-year cert? If it's good for 13 months, why
not tie the cert validity to that? I guess because they could have transferred
the domain (which just means you need additional caps)? It'
What about issues other than audits? For example, with certain locations
closing, key ceremonies may become impossible, leading to downed CRLs/OCSP for
intermediates. There's also a potential issue with trusted roles even being
able to access the data center if something goes down and Sub CAs ca
That's not the visible consensus IMO. The visible consensus is we need to
revoke a cert that is key compromised once we're informed the key is
compromised for that cert
(https://groups.google.com/forum/m/#!topic/mozilla.dev.security.policy/1ftkqbsnEU4).
The certificate you mentioned was issued
Hey Matt,
Ryan's post was the part I thought was relevant, but I understood it
differently. The cert was issued, but we should have now revoked it (24 hours
after receiving notice). I do see your interpretation though, and the language
does support 24 hours after issuing the new cert. What I n
disclosures need to be affiliated
with actual certs.
From: Ryan Sleevi
Sent: Monday, March 23, 2020 10:54 AM
To: Jeremy Rowley
Cc: Matt Palmer ; Mozilla
Subject: Re: Digicert: failure to revoke certificate with previously
compromised key
On Mon, Mar 23, 2020 at 11:01 AM Jeremy Rowley via dev
Subject: Re: Auditing of CA facilities in lockdown because of an environmental
disaster/pandemic
On Fri, Mar 20, 2020 at 4:15 PM Jeremy Rowley via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org>>
wrote:
What about issues other than audits? For example, with certain loc
Hey all,
The key used to sign SCTs for the CT2 log was compromised yesterday at 7pm
through the Salt root bug. The remaining logs remain uncompromised and run on
separate infrastructure. We discovered the compromise today and are working to
turn that log into read only mode so that no new SCTs
timestamp before May 2 still be considered trusted?
Alex
On Sun, May 3, 2020 at 6:19 PM Jeremy Rowley via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org>>
wrote:
Hey all,
The key used to sign SCTs for the CT2 log was compromised yesterday at 7pm
through the Salt root bu
if it was included in
the tree before that time. However, that is the reason to include multiple SCTs
in the same log.
-Original Message-
From: dev-security-policy On
Behalf Of Jeremy Rowley via dev-security-policy
Sent: Sunday, May 3, 2020 5:27 PM
To: Alex Cohn
Cc: Mozilla
Subject: R
;>
Cc: Mozilla
mailto:mozilla-dev-security-pol...@lists.mozilla.org>>
Subject: Re: CT2 log signing key compromise
The timestamp on a SCT is fully controlled by the signer, so why should SCTs
bearing a timestamp before May 2 still be considered trusted?
Alex
On Sun, May 3, 2020 at 6:19 P
other
DigiCert infrastructure.
Thanks,
Ian Carroll
On Sun, May 3, 2020 at 4:19 PM Jeremy Rowley via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org>>
wrote:
Hey all,
The key used to sign SCTs for the CT2 log was compromised yesterday at 7pm
through the Salt root bu
Yes, but only for embedded SCTs. For revocation or extension served SCTs, you
could end up with different timestamps depending on how the CA is set up. On
top of that, for embedded SCTs, you'd need to route the cert through a separate
singing service that used the compromised key. For that to ha
I thought I posted on this a while ago, but I can't seem to find the post. It
may have been CAB Forum (where the archives are nearly useless). The conclusion
from that is the CSR isn't required as part of the issuance process because
there isn't a risk without having actual control over the priv
x27;s encrypts public key
Jeremy Rowley via dev-security-policy
writes:
>For those interested, the short of what happened is that we had an old
>service where you could replace existing certificates by having
>DigiCert connect to a site and replace the certificate with a key taken
>from
I think your list of 23 is wrong. For example, bug 1550645 is just waiting for
Mozilla closure. It looks like 1605804 is in the same boat.
-Original Message-
From: dev-security-policy On
Behalf Of Matthias van de Meent via dev-security-policy
Sent: Monday, May 18, 2020 1:04 PM
To: MDSP
)
-Original Message-
From: dev-security-policy On
Behalf Of Jeremy Rowley via dev-security-policy
Sent: Monday, May 18, 2020 1:52 PM
To: Mozilla
Subject: RE: Status of the bugzilla bug list
I think your list of 23 is wrong. For example, bug 1550645 is just waiting for
Mozilla closure. It
Yes - that's been well established. See
https://bugzilla.mozilla.org/show_bug.cgi?id=1639801 (where Ryan reminded me
that this has been discussed and resolved with actual language in the BRs)
-Original Message-
From: dev-security-policy On
Behalf Of Kurt Roeckx via dev-security-policy
Is there a way to filter out the revoked and non-TLS/SMIME ICAs?
-Original Message-
From: dev-security-policy On
Behalf Of Rob Stradling via dev-security-policy
Sent: Wednesday, June 17, 2020 5:07 AM
To: dev-security-policy
Subject: crt.sh: CA Issuers monitor (was Re: CA Issuer AIA UR
uot; . Very top of the page ;)
e.g.
https://crt.sh/ca-issuers?trustedExclude=expired%2Conecrl&trustedBy=Mozilla&trustedFor=Server+Authentication&dir=v&sort=2&rootOwner=&url=&content=&contentType=
On Wed, Jun 17, 2020 at 5:18 PM Jeremy Rowley via dev-security-polic
That's accurate, but the real question goes back to a discussion we previously
had at the CAB forum that I don't think was answered - what is a locality vs. a
state vs. an address?
In Sept 2019, we put in code that requires this be checked against however map
software defines it, allowing loca
Threatening distrust over a discussion about applicability of requirements
seems contrary to Mozilla's open discussion policy, and I don't think that
should be an answer while there are still open questions about the language in
4.9.9. Separating out the security risk from the applicability of t
:51 AM
To: Jeremy Rowley
Cc: Mozilla
Subject: Re: Question about the issuance of OCSP Responder Certificates by
technically constrained CAs
On Thu, Jul 2, 2020 at 1:33 PM Jeremy Rowley via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org>>
wrote:
Threatening distrust
This is a good question. I read the requirements as applying only to CRLs and
OCSP published after the effective date since the BRs always say explicitly
when they apply to items before the effective date.
I also read this language:
If a CRL entry is for a Certificate not subject to these Requi
-boun...@lists.mozilla.org>>
on behalf of Jeremy Rowley via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org>>
Sent: 30 September 2020 17:41
To: Mozilla
mailto:mozilla-dev-security-pol...@lists.mozilla.org>>
Subject: RE: Mandatory reasonCode analysis
CAUTION: Th
Should this limit on reuse also apply to s/MIME? Right now, the 825 day limit
in Mozilla policy only applies to TLS certs with email verification of s/MIME
being allowed for infinity time. The first draft of the language looked like
it may change this while the newer language puts back the TLS
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 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
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
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 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
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 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
---
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
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
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
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
?
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
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
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
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
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
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
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
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
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:
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
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
, 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
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
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
*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
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
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
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
.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
, 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
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.
>
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
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
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 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
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@
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
* 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
1 - 100 of 314 matches
Mail list logo
