Entropy is required in serial numbers to protect against weak hash
functions -- historically exploitation of MD5's weakness was possible
because CAs used sequential serial numbers, thus allowing an attacker to
pre-compute hash prefixes, because they could predict future data that
On Tue, Mar 5, 2019 at 9:01 AM Scott Rea via dev-security-policy <
> I have addressed most if not all of the various technical comments in this
> list in respect to DarkMatter’s Roots submission and it might be helpful if
> I summarize here the raised
(Writing in my personal capacity)
On Tue, Feb 26, 2019 at 7:31 PM Matthew Hardeman via dev-security-policy <
> All of Google, Amazon, and Microsoft are in the program. All of these have
> or had significant business with at least the US DOD
a link for the record here, for others finding this
> in the future?
> On Mon, Jan 28, 2019 at 10:05 AM Alex Gaynor via dev-security-policy <
> email@example.com> wrote:
>> Hi All,
>> For anyone using https://misissued.com/ I wanted
For anyone using https://misissued.com/ I wanted to provide a quick FYI
about some database maintenance. The database was nearing its storage
capacity limit, and so I deleted all certificates from it that had expired
before 2019. The main consequence of this is that you can't use
The Mozilla policy does not prohibit backdating, except when it's used to
evade time-based policy controls.
Backdating certs by a few hours is a relatively common practice to minimize
breakages for consumers with busted clocks.
On Thu, Jan 10, 2019 at 4:43 AM Buschart, Rufus via
A broader issue is that a lot of the certs listed on these pages are
publicly-trusted, but not by the Mozilla Root Program, that is to say,
Microsoft or Apple (or occasionally Adobe) trusts them.
misissued.com (which is currently erroring on all requests ) tried to
address this by only showing
Just so I follow, this is something you're proactively sharing, right? As
far as I can tell, there's no violation of any Mozilla Root Program rules
here, just an issue that caused interstitials in Chrome.
Either way, I appreciate your sharing.
You mentioned the issue was do to some
Sorry -- digging into that 500 was on my plate, but there was a logging bug
on errors... and then some poor docs for the framework I'm using... and
before you know it, the yak stack was piled high. I'll cycle around to that
again this evening.
On Mon, Jun 18, 2018 at 9:53 AM Rob Stradling
Are you saying that's what actually happened, or that we should all pretend
that's what happened?
Because I don't believe anyone from GoDaddy has made such a claim, and we
ought not put words in their mouths.
On Fri, Apr 13, 2018 at 12:39 PM, Jakob Bohm via dev-security-policy <
All that proves is the entire EV model cannot possibly accomplish what CAs
claims (with respect to phishing and other similar concerns). To whit:
- Two companies can validly possess trademarks for the same name in the
United States (and I assume other jurisdictions)
- A CA, or anyone else's
I disagree on what this is evidence of:
It's evidence that the claimed benefits of EV (by CA, WRT phishing) do not
match the technical reality. As Ryan noted, as far as I'm aware this
certificate violates neither the BRs, nor the EVG.
On Wed, Apr 11, 2018 at 2:48 PM, Matthew Hardeman via
e there are certainly advantages to indiscriminately logging all
> final certificates, there are downsides to weigh as well, at least for ones
> not (yet?) deployed on publicly-accessible web servers.
> On 4/5/18, 3:08 PM, "dev-security-policy on behalf of Alex Gay
There's two separable questions here:
1) Should CAs log final certificates after they issue a certificate with
embedded SCTs: My answer, yes.
2) Should CAs issue final certificates if they discover they are misissued
after logging the pre-certificate.
The answers to (1) and (2) do not need to be
That would make much more sense.
> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+tim.hollebeek=digicert....@lists.mozilla.org] On Behalf Of Alex
> > Gaynor via dev-security-policy
A month ago a new BR rule went into effect, putting a maximum validity
period of 825 days on newly issued certificates.
Truthfully, I was expecting tons of CAs to screw up, forget to implement
it, or have no technical controls, and there to be tons of miss-issuance.
To me delight,
Mozilla currently doesn't have any policy with respect to Certificate
Transparency, so I think diving in on this particular point is putting the
cart before the horse :-)
Currently Firefox does not check/require SCT presence nor does the Mozilla
root program require certificates to be logged.
For the Trustico folks:
While I imagine you're quite busy remediating this serious issue: Can you
state whether it would be possible to access any of the private keys you
store using this root shell?
On Thu, Mar 1, 2018 at 10:28 AM, Hanno Böck via dev-security-policy <
Is it practical to remove the Symantec root certificates and (temporarily)
add the Google and Apple intermediates to the trust store? This should
facilitate removing trust in Symantec without disruption.
On Thu, Mar 1, 2018 at 10:15 AM, Kai Engert via dev-security-policy <
I would say that at the point that Trustico emailed them to DigiCert they
necessarily became compromised -- while Trustico may (or may not) have been
authorized to escrowing the keys by the subscriber, the subscriber did not
authorize them to be emailed around, presumably.
On Wed, Feb 28,
A reasonable compromise that jumps out to me is allowing extensions to make
an otherwise-secure connection fail, but not allow them to rehabilitate an
insecure connection. This would allow experimenting with stricter controls
while avoiding some of the really scary risks.
On Tue, Feb 27,
If I may give a shorter answer than Peter: for authentication purposes (as
used in the WebPKI with non-RSA-key-exchange ciphersuites in TLS) there is
no current deprecation plans for 2048-bit RSA.
On Sat, Jan 20, 2018 at 12:00 PM, Peter Bowen via dev-security-policy <
I guess it depends how you define "Certificate on the ADN" -- TLS-SNI-01
performs a DNS lookup for the ADN, connects to that IP, and initiatives a
TLS connection with the .acme.invalid SNI value.
Certificates don't exist on Domain Names if we think really hard about it,
but servers with IPs that
Self-assessment is insufficient :-)
That's why we require audits, review issued certificates for technical
violations, and attempt to empower domain owners to identify misissuance.
As we move to a world with greater participation of public CAs in
Certificate Transparency (hopefully 100%
After some time thinking about it, I struggled to articulate what the right
rules for inclusion were.
So I decided to approach this from a different perspective: which is that I
think we should design our other policies and requirements for CAs around
what we'd expect for organizations
It would come at the expense of a more streamlined and secure approach
(e.g. the ALPN proposal on the acme-wg list), which once standardized I
assume Let's Encrypt (and other ACME CAs) would want to fully migrate to.
On Mon, Jan 15, 2018 at 9:27 AM, Gervase Markham via dev-security-policy <
Can you share what the working group has been brainstorming on?
Near as I can tell, this is a validly issued EV cert, for a valid KY
company. If "Stripe, Inc of Kentucky" were in a distinct industry from this
Stripe there wouldn't even be a trademark claim (I'm not a lawyer, etc.).
Have all these certificates been submitted to CT?
On Tue, Nov 7, 2017 at 1:20 PM, Jeremy Rowley via dev-security-policy <
> Hey everyone,
> Here's the DigiCert incident report about the ROCA fingerprints. Note that
Today researchers announced a vulnerability they discovered in RSA keys
generated by a particular piece of firmware, which allows practical
factorization of the private key given just the public key.
Full details of the research here:
I'm fairly confused by your answers, if the only thing you tested in
production was CT, why was the system issuing non-compliant certs? Why did
production CT testing come before having established, tested, and verified
a compliant certificate profile?
On Fri, Sep 15, 2017 at 10:35 AM, Inigo
I'd like to push a bit harder on searching for more systemic remediations.
"We forgot to get around to revoking it" is a pretty common element of CAs'
post-mortems, I think it'd be good for us to dig deeper.
For example, does Let's Encrypt have a runbook that gets used on
misissuance reports? Is
I believe it's important to consider more than just the issues themselves,
and to look at a CA's response to the issues. In the past weeks, we've done
a lot of really fantastic work to push CAs on publishing more comprehensive
post-mortems, and several CAs have distinguished themselves with timely
I'm not sure it should matter that a CA _does_ only issue client certs --
in the DigiNotar-style situation for which this rule was envisioned, the
relevant thing is whether the cert is _capable_ of issuing server certs.
On Tue, Aug 29, 2017 at 12:43 PM, Ben Wilson via
Tools like https://github.com/alex/ct-tools or
https://github.com/grahamedgecombe/ct-submit can be used to manually submit
specific certificates to CT logs.
On Thu, Aug 17, 2017 at 9:07 AM, Arno Fiedler via dev-security-policy <
Have they fixed whatever issue there is with their PKI infrastructure that
leads to this issue? From skimming, I see this pool contains certs issued
as recently as one month ago.
On Fri, Aug 11, 2017 at 10:26 AM, Ben Wilson via dev-security-policy <
Given that these were all caught by cablint, has Let's Encrypt considered
integrating it into your issuance pipeline, or automatically monitoring
crt.sh (which runs cablint) for these issues so they don't need to be
caught manually by researchers?
On Thu, Aug 10, 2017 at 11:00 PM,
This is a great point, re:automated issuance systems like ACME. I've
suggested to the Let's Encrypt folks the idea of a "should I re-issue"
endpoint that clients can poll. This would give CAs a programatic ability
to broadcast to subscribers that they should reissue now because the cert
> On Thursday, August 10, 2017 at 12:23:55 AM UTC-4, Lee wrote:
> > What's it going to take for mozilla to set up near real-time
> > monitoring/auditing of certs showing up in ct logs?
> > Lee
As a friend of mine sagely points out, fundamentally the current incentives
for a CA are, "Issuing certs gets us money, not issuing certs does not get
us anything". That's an incentive structure that badly needs correction --
CAs should be accountable for what they issue.
Without speaking to
(Whoops, accidentally originally CC'd to m.d.s originally! Original mail
was to IdenTrust)
The following certificates appear to be misissued:
I'm not really sure I agree that there should be multiple tiers of
revocation, but just to go along with the thought experiment..
If there were, "key compromise" is definitely not the only case I'd want on
the more aggressive schedule, I'd also want to include cases where there
was a failure in
It's from the BRs 184.108.40.206:
The CA SHALL revoke a Certificate within 24 hours if one or more of
the following occurs:
It's also not a penalty on the CA, it's a remediation step for them to
On Tue, Aug 8, 2017 at 2:43 PM, Jakob Bohm via dev-security-policy <
I think you're largely objecting to a strawman, no one is proposing
revoking trust in any of these threads.
The only CAs that have ever had _any_ penalty applied to them have been for
grotesque abuse of the trust vested in them.
On Tue, Aug 8, 2017 at 2:25 PM, Jakob Bohm via
Following up on this thread, 8 days ago I emailed Camerfirma, I have not
heard back from them, nor have they taken any action. What is the
appropriate next step here?
On Mon, Jul 31, 2017 at 10:14 AM, Alex Gaynor wrote:
> I've been attempting to report a
Luckily we have tools like certlint, which can be run on certificates to
catch this stuff!
I'd feel very differently if CAs were starting these threads because they'd
caught issues with certlint, than the fact that independent researchers are
On Tue, Aug 8, 2017 at 7:52 AM, Jakob
This methodology of "letting everyone decide which parts of the spec/BRs
aren't important" doesn't make sense. If there's something wrong with the
spec, let's fix it! (Perhaps X.509 validation needs its own equivalent of
the "fetch" specification). Giving each CA unilateral authority to ignore
You seem to be suggesting that the thoroughness of testing is somehow
related to how long it takes.
I'd expect any serious (or even not particularly serious...) to have a
comprehensive automated test suite that can verify that the software is
regression free and correct in minutes or hours. If
Sorry, you're right -- I'd misunderstood the issue with Python. (FWIW, I'm
one of the maintainers of the Python ssl module, and I anticipate us having
a fix for IDNs by the next release).
On Sun, Aug 6, 2017 at 8:38 PM, Nick Lamb via dev-security-policy <
Ouch. Thanks for clarifying.
On Thu, Aug 3, 2017 at 10:46 AM, Ben Wilson wrote:
> There are over 300 publicly visible servers, according to Censys.IO.
> *From:* Alex Gaynor [mailto:agay...@mozilla.com]
> *Sent:* Thursday, August 3, 2017 8:42 AM
> *To:* Ben
If I'm reading this correctly, these certificates are for internal
services, not publicly accessible. Could they add their intermediate
directly to these trust stores, allowing you to revoke it?
Failing that, it sounds like OneCRL would be an appropriate remedy.
On Thu, Aug 3, 2017 at
The signature on the TBSCertificate indicates the certificate
authority's intent to issue a certificate. This intent is considered
binding (i.e., misissuance of the Precertificate is considered equal
to misissuance of the final certificate).
I don't think this text could be any
Will the certificates being issued for Symantec starting December 1st be
issued under the existing DC roots, or under new roots?
On Wed, Aug 2, 2017 at 5:12 PM, Jeremy Rowley via dev-security-policy <
> Hi everyone,
Frankly I was surprised to see Chromium reverse course on this -- they have
a history of aggressive leadership in their handling of CA failures, it's a
little disappointing to see them abandon that.
I'd strongly advocate for us perusing an earlier date -- December 1st at
the latest. Reasons:
Just to be explicit: your count includes certificates which, with high
probability have already been replaced, because it does not subtract names
for which new certificates have been issued?
I realize it may seem like I'm putting a lot of emphasis on this one
number, but given that it's the basis
On Tue, Jul 25, 2017 at 4:28 PM, Rick Andrews via dev-security-policy <
> Symantec has proposed timing changes that are consistent with the scope of
> distrust of the original SubCA proposal as proposed by Google and endorsed
> by Mozilla, which
Are you saying you do intend to revoke all of these certificates in the
next 24 hours?
While subscribers are allowed to continue using bad certificates as long as
they desire, the BRs require CAs to revoke non-compliant certificates
within 24 hours of becoming aware of them.
Following up on this (and really several other threads). The BRs require
mis-issued certs to be revoked with 24 hours of the CA becoming aware. CAs
are required to track m.d.s.p. per the Mozilla Root Policy, so really
notifying this list _ought_ to qualify as notifying the CAs.
In any event, here
On Thu, Jul 20, 2017 at 11:00 AM, Steve Medin
> 1) *December 1, 2017 is the earliest credible date that any RFP
> respondent can provide the Managed CA solution proposed by Google, assuming
> a start date of August 1, 2017. Only one RFP respondent initially
Thank you for this update on Symantec's progress. I have a few follow-up
1) Did any of the RFP respondents indicate that they could provide the
CA solution in the timeframe originally proposed by Google? (August 8th)
Alternatively, is December 1st, 2017 the
I think there might be a bug in your SQL, one of the offending certs is
issued by "C=US, O=U.S. Government, OU=Department of Homeland Security,
OU=Certification Authorities, OU=DHS CA4", who are revoked using OneCRL.
On Wed, Jul 19, 2017 at 10:08 AM, Rob Stradling via dev-security-policy <
I'd like to report the following instance of miss-issuance:
All of the following contain a URI in a dNSName SAN entry. These
certificates are neither revoked, nor expired, and all are from CAs
currently trusted by the Mozilla Root Program.
On Fri, Jul 14, 2017 at 10:03 AM, Ryan Sleevi via dev-security-policy <
> On Fri, Jul 14, 2017 at 9:44 AM, Hanno Böck via dev-security-policy <
> firstname.lastname@example.org> wrote:
> > So there are several questions and possible
Is this a correct summary:
- The report included here is supposed to fulfill the network security test
portion of the BRs
- This report does not attest to BR compliance (or non-compliance)
- To complete an application for the Mozilla Root Program, WoSign would be
required to additionally provide
I wanted to call some attention to a few intermediates which have been
hanging out in the "Audit required" section for quite a while:
Specifically, the TurkTrust and Firmaprofesional ones. Both have issues
open in Bugzilla:
On Wed, Jul 5, 2017 at 7:51 AM, Gervase Markham via dev-security-policy <
> I agree crypto algorithms are not "gotta catch 'em all", but the
> algorithm is ECDH, which NSS must implement anyway to support P-256 and
> P-384, and a curve is just another
I'll take the opposite side: let's disallow it before it's use expands :-)
P-521 isn't great, and there's really no value in proliferation of crypto
algorithms, as someone told me: "Ciphersuites aren't pokemon, you shouldn't
try to catch 'em all". There's no real use cases P-521 enables, and not
I definitely consider increased visibility into the vast iceberg that is
the public PKI to be a good thing!
What set of intermediates are you using? If it's reasonably complete, I
doubt we'll do any better than you, though maybe someone here has a
particularly clever technique for processing
One of my hobbies is keeping track of publicly trusted (by any of the major
root programs) CAs, for which there are no logged certificates. There's
over 1000 of these. In the last day, presumably as a result of these
efforts, 50-100 CAs were removed from the list.
On Thu, Jun 22,
If you're interested in playing around with submitting them yourself, or
checking if they're already submitted, I've got some random tools for
working with CT: https://github.com/alex/ct-tools
Specifically ct-tools check will get what you
want. It's all serial, so for
On Tue, Jun 6, 2017 at 10:02 AM, Gervase Markham via dev-security-policy <
> On 02/06/17 15:53, Gervase Markham wrote:
> > https://www.symantec.com/connect/blogs/symantec-s-
> I'm slightly surprised to see no
On Tue, Jun 6, 2017 at 9:05 AM, Ryan Sleevi via dev-security-policy <
> On Tue, Jun 6, 2017 at 5:13 AM, Gervase Markham via dev-security-policy <
> email@example.com> wrote:
> > On 05/06/17 14:29, Alex Gaynor wrote:
> > > As I've
Another week, another set of intermediate certs that have shown up in CT
without having been properly disclosed:
There are four intermediates here, and with exception of the StartCom one,
they were all issued more than a year ago.
Fewer round trips, if you can include everything in a single response.
On Tue, May 16, 2017 at 11:11 AM, Ryan Sleevi wrote:
> On Tue, May 16, 2017 at 11:00 AM, Rob Stradling via dev-security-policy <
> firstname.lastname@example.org> wrote:
>> On 16/05/17
While the internet is moderately good at handling a single cross-sign
(modulo the challenges we had with 1024-bit root deprecation due to a bug
in OpenSSL's path building -- now fixed), as we extend the chains, it seems
evident to me that server operators are unlikely to configure their servers
I've lost the thread on how this addresses Cory's original problem
statement, if you could spell that out that'd be very helpful.
On Tue, May 16, 2017 at 10:22 AM, Ryan Sleevi wrote:
> On Tue, May 16, 2017 at 7:58 AM, Peter Gutmann
, 2017 at 11:57 AM, Alex Gaynor via dev-security-policy <
>> email@example.com> wrote:
>>> I think you've correctly highlighted that there's a problem -- the
>>> CA store is "designed&
Once upon a time I would said "yes, we should totally encourage people to
lovingly craft their perfect trust store, to reduce their risk profile".
Now, not so much.
As we've seen in numerous discussions, customers of CAs, particularly large
enterprises and vendors (think payment terminals) love
I think you left this a bit implicit Cory, so I figured it's worth spelling
out: the strength of Mozilla's CA program, as a tool for making the web
stronger, comes from having people using it, that's the carrot that forces
people to meet our standards (also the fact that as a transparent, root
On Thu, May 11, 2017 at 1:03 PM, Gervase Markham via dev-security-policy <
> Hi Cory,
> On 11/05/17 15:21, Cory Benfield wrote:
> > While I’m very supportive of this kind of remediation, it is not a
> remediation that non-browser implementations can
I think you've correctly highlighted that there's a problem -- the Mozilla
CA store is "designed" to be consumed from NSS, and CA-specific
remediations are a part of that (hash algorithms, maximum certificate
lifetimes, and any number of other important technical controls).
On Mon, May 8, 2017 at 11:22 AM, Kurt Roeckx via dev-security-policy <
> On 2017-05-08 15:31, Alex Gaynor wrote:
>> I'm not the best way to phrase this, so please forgive the bluntness, but
>> think it'd be appropriate to
I'm not the best way to phrase this, so please forgive the bluntness, but I
think it'd be appropriate to ask at this point if Symantec has disclosed
all necessary intermediates (I believe this would be defined as: chain to
their roots in our trust store, are not expired, are not revoked, and are
Does Symantec plan to introduce new facts into the conversation, or is all
the information we are currently considering accurate and complete?
If there's no new information, I don't see why the community of
participants in m.d.s.p. should pause. I think it's a point of pride for
It is clear to me from reading this that there is a significant gap between
Symantec's perspective on the severity of the issues discussed and the
perspective of many m.d.s.p. participants. Hopefully this email will serve
to highlight some specific areas that contribute to this gap, and which
This morning Symantec disclosed ~20 new intermediate certs. I went through
these and identified 7 of them which are a) not revoked, b) not expired, c)
lack a BR audit:
I know several CAs are using certlint (https://github.com/awslabs/certlint)
as a pre-issuance check that the cert they're about to issue doesn't have
any programmatically detectable deficiencies; if it doesn't already cover
some of these cases, it'd be great to add them as a technical means for
One idea that occurred to me (maybe novel, though I doubt it), is requiring
mandatory _timely_ CT submission for intermediates/cross signatures. That
is, to be compliant an issuers's (SCT-timestamp - cert-not-before) must be
less than some period, perhaps 3 days. This would ensure rapid
(I work for Mozilla, but this email doesn't necessarily reflect the views
I appreciate Symantec taking the time to put this together. There's a lot
of unpack here, so I wanted to zoom in on one portion of it.
When discussing the feedback you received from enterprise
On Thu, Apr 27, 2017 at 3:52 PM, Jeremy Rowley via dev-security-policy <
> Your post made me realize that we never publicly posted the status of these
> last few CAs. Sorry about that. Here's the plan:
> 1. ABB - ABB was supposed to be technically
+1 on removal, that paragraph doesn't square with current ideas about
what's problematic in the WebPKI; as you've noted wildcards and DV are
really orthogonal concerns.
On Thu, Apr 20, 2017 at 9:02 AM, Gervase Markham via dev-security-policy <
Tiny nit-picky follow up question. You said: "it's technically not
feasible. This is because Symantec does not have access to our customers'
TLS server private keys.".
X.509 certificates can of course be used for things besides TLS, when you
say "TLS server private keys", is that
I don't think it's a good idea to design our system around the idea of
"What would a user be looking for if they read the cert chain manually".
For example, in the US, if such a government agency chose to use a
Government CA (as a user might reasonably expect!), their users would all
Mail list logo