Hi Lijun,
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
would b
On Tue, Mar 5, 2019 at 9:01 AM Scott Rea via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> 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 <
dev-security-policy@lists.mozilla.org> wrote:
[...]
> All of Google, Amazon, and Microsoft are in the program. All of these have
> or had significant business with at least the US DOD and
ring 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 <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Hi All,
>>
>> For anyone using https://misissued.com/ I wa
Hi All,
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
misissued
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.
Alex
On Thu, Jan 10, 2019 at 4:43 AM Buschart, Rufus via dev-securit
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 c
Hi Andy,
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 over
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.
Alex
On Mon, Jun 18, 2018 at 9:53 AM Rob Stradling vi
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.
Alex
On Fri, Apr 13, 2018 at 12:39 PM, Jakob Bohm via dev-security-policy <
dev-securit
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 abilit
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.
Alex
On Wed, Apr 11, 2018 at 2:48 PM, Matthew Hardeman via de
ey to be exploited.
> So, while 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
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
ld make much more sense.
>
> -Tim
>
> > -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
> > Sent: Monday, April
Afternoon all!
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.
Ale
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?
Alex
On Thu, Mar 1, 2018 at 10:28 AM, Hanno Böck via dev-security-policy <
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.
Alex
On Thu, Mar 1, 2018 at 10:15 AM, Kai Engert via dev-security-policy <
dev-security-polic
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.
Alex
On Wed, Feb 28, 20
ystem risk, or in general complexity risk.
Alex
On Wed, Feb 28, 2018 at 11:54 AM, Tom Ritter wrote:
> On 27 February 2018 at 10:23, Alex Gaynor via dev-security-policy
> wrote:
> > A reasonable compromise that jumps out to me is allowing extensions to
> make
> > an otherw
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.
Alex
On Tue, Feb 27, 201
Hey Tim,
A piece I think I'm missing is what you see as the incentive for CAs to aim
for an "A" rather than being happy to have a "B". It reminds me of the old
joke: What do you call the Dr^W CA who graduated with a C average? Dr.^W
trusted to assert www-wide identity :-)
That said, given the iss
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.
Alex
On Sat, Jan 20, 2018 at 12:00 PM, Peter Bowen via dev-security-policy <
dev-security-policy@lis
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 d
y 100% eventually), we can increasingly
rely on objective measures to judge across CAs.
Alex
On Thu, Jan 18, 2018 at 4:23 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 17/01/18 14:54, Alex Gaynor wrote:> In summary, I think we should
&g
Hi Wayne,
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.
Alex
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.).
Lest anyone th
Hi Jeremy,
Have all these certificates been submitted to CT?
Thanks!
Alex
On Tue, Nov 7, 2017 at 1:20 PM, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hey everyone,
>
>
>
> Here's the DigiCert incident report about the ROCA fingerprints. Note that
> th
Thank you for writing this up.
Do any of the other CAs with trusted server certificates intend to publish
similar reports? (Based on CT logs that'd be Comodo, Symantec, and
GlobalSign).
Alex
On Tue, Oct 24, 2017 at 12:28 PM, Daymion Reynolds via dev-security-policy <
dev-security-policy@lists.mo
Hi all,
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:
https://crocs.fi.muni.cz/public/papers/rsa_ccs17
Ther
It also protects consumers of the Mozilla Root Program who are not using it
with a browser -- I know it has been expressed before that that's not a
totally supported use case, but nonetheless it is _extremely_ common to use
a derivative of the Mozilla trust store with verifies like OpenSSL, which
d
https://crt.sh/mozilla-certvalidations?group=version&id=896972 is a very
informative graph for me -- this is the number of validations performed by
Firefox for certs under this CA. It looks like at the absolute peak, there
were 1000 validations in a day. That's very little value for our users, in
r
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?
Alex
On Fri, Sep 15, 2017 at 10:35 AM, Inigo
any weak key certs issued prior to our July 20 fix will
> expire in at most 37 days.
>
> On Monday, September 11, 2017 at 8:24:49 AM UTC-5, Alex Gaynor wrote:
> > Hi Josh,
> >
> > Does Let's Encrypt plan to implement any systematic or programmatic fixes
> > to en
Hi Josh,
Does Let's Encrypt plan to implement any systematic or programmatic fixes
to ensure certificates are promptly revoked in the future?
Did you perform a scan of all your issued certificates to see if any others
were effected?
Alex
On Sat, Sep 9, 2017 at 8:14 PM, josh--- via dev-security-
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
Hi Ben,
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.
Alex
On Tue, Aug 29, 2017 at 12:43 PM, Ben Wilson via dev-security-p
Hi Arno,
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.
Alex
On Thu, Aug 17, 2017 at 9:07 AM, Arno Fiedler via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Am M
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.
Alex
On Fri, Aug 11, 2017 at 10:26 AM, Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wro
Hi Josh,
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?
Alex
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
is about to
My apologies, it was pointed out to me off list that two of these are
pre-certs for other certs in that batch.
Alex
On Thu, Aug 10, 2017 at 12:19 PM, Alex Gaynor wrote:
> Hi IdenTrust,
>
> When you say that the remaining two are pre-certificates, are you
> asserting that no c
ity-policy <
dev-security-policy@lists.mozilla.org> wrote:
> 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 parti
(Whoops, accidentally originally CC'd to m.d.s originally! Original mail
was to IdenTrust)
Hi,
The following certificates appear to be misissued:
https://crt.sh/?id=77893170&opt=cablint
https://crt.sh/?id=77947625&opt=cablint
https://crt.sh/?id=78102129&opt=cablint
https://crt.sh/?id=92235995&op
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 DV
<
dev-security-policy@lists.mozilla.org> wrote:
> Some people seemed to require 24-hour revocation of these, which I also
> find possibly excessive.
>
> On 08/08/2017 20:28, Alex Gaynor wrote:
>
>> I think you're largely objecting to a strawman, no one is prop
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.
Alex
On Tue, Aug 8, 2017 at 2:25 PM, Jakob Bohm via dev-security-po
Hi all,
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?
Alex
On Mon, Jul 31, 2017 at 10:14 AM, Alex Gaynor wrote:
> I've been attempting to report a bunch of mis
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
noticing.
Alex
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
what
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 you
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).
Alex
On Sun, Aug 6, 2017 at 8:38 PM, Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.or
I think it's reasonable to consider mistakes in StartCom's new PKI of this
nature to be a part of "continuing pattern of behavior" from their previous
PKI, and not something which should be considered in isolation. In that
context, I'm not sure comparisons with other CAs which were "first time
offe
Ouch. Thanks for clarifying.
Alex
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 Wils
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.
Alex
On Thu, Aug 3, 2017 at 10:38
From RFC6962:
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 mor
Hi Jeremy,
Will the certificates being issued for Symantec starting December 1st be
issued under the existing DC roots, or under new roots?
Alex
On Wed, Aug 2, 2017 at 5:12 PM, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hi everyone,
>
>
>
> Today, Di
I've been attempting to report a bunch of miss-issued certificates this
weekend (hobbies are important!) I've primarily been using
https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o03WrzBC&QuestionId=Q00028
as my reference (without which I
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:
1) C
DV certs from this time frame to CT.
Alex
On Thu, Jul 27, 2017 at 11:53 AM, Rick Andrews via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Wednesday, July 26, 2017 at 10:20:08 AM UTC-7, Alex Gaynor wrote:
> > On Tue, Jul 25, 2017 at 4:28
On Tue, Jul 25, 2017 at 4:28 PM, Rick Andrews via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> 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 requir
Hi Mark,
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.
Alex
On Tu
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
wrote:
> 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 proposed
> a schedule targe
Hi Steve,
Thank you for this update on Symantec's progress. I have a few follow-up
questions:
1) Did any of the RFP respondents indicate that they could provide the
Managed
CA solution in the timeframe originally proposed by Google? (August 8th)
Alternatively, is December 1st, 2017 the earl
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.
Alex
On Wed, Jul 19, 2017 at 10:08 AM, Rob Stradling via dev-security-policy <
d
Morning all,
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.
https://crt.sh/?id=124094761&opt=cablint
On Fri, Jul 14, 2017 at 10:03 AM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Fri, Jul 14, 2017 at 9:44 AM, Hanno Böck via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > So there are several questions and possible situatio
Hey Ben,
Take a look at the thread "Disclosing unconstrained emailProtection
intermediates to CCADB" by Rob, it explains the change and has the relevant
dates by which CAs must comply.
Alex
On Tue, Jul 11, 2017 at 3:21 PM, Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.or
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 a
Hi all,
I wanted to call some attention to a few intermediates which have been
hanging out in the "Audit required" section for quite a while:
https://crt.sh/mozilla-disclosures#disclosureincomplete
Specifically, the TurkTrust and Firmaprofesional ones. Both have issues
open in Bugzilla:
- https:
On Wed, Jul 5, 2017 at 7:51 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> 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
su
te I haven't seen.
>
> Tavis.
>
>
> On Thu, Jun 22, 2017 at 6:15 AM, Alex Gaynor wrote:
>
>> 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 10
at this URL a couple of days
> ago. This submitted many of the certs to the Dodo and Rocketeer logs.
>
> However, it didn't manage to build chains for all of them. I haven't yet
> had a chance to investigate why.
>
>
> Tavis.
>>
>> On Mon, Jun 19, 201
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 8M certs you probably want t
It was also pointed out to me that as Symantec have indicated they sent out
an RFP, any companies which are considering responding may be hesitant to
post.
Alex
On Tue, Jun 6, 2017 at 10:16 AM, Gervase Markham wrote:
> On 06/06/17 15:12, Alex Gaynor wrote:
> > I suspect many of us
On Tue, Jun 6, 2017 at 10:02 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 02/06/17 15:53, Gervase Markham wrote:
> > https://www.symantec.com/connect/blogs/symantec-s-
> response-google-s-subca-proposal
>
> I'm slightly surprised to see no engage
On Tue, Jun 6, 2017 at 9:05 AM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Tue, Jun 6, 2017 at 5:13 AM, Gervase Markham via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > On 05/06/17 14:29, Alex
Happy Monday!
Another week, another set of intermediate certs that have shown up in CT
without having been properly disclosed:
https://crt.sh/mozilla-disclosures#undisclosed
There are four intermediates here, and with exception of the StartCom one,
they were all issued more than a year ago.
As I
Fewer round trips, if you can include everything in a single response.
Alex
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 <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On 16/05/17 15:41, Ryan Sleevi vi
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
to
Hi Ryan,
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.
Alex
On Tue, May 16, 2017 at 10:22 AM, Ryan Sleevi wrote:
>
>
> On Tue, May 16, 2017 at 7:58 AM, Peter Gutmann
> wrote:
>
>> Ryan Sleevi writes:
>>
>> >I
ay 11, 2017 at 11:57 AM, Alex Gaynor via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>> Ryan,
>>>
>>> I think you've correctly highlighted that there's a problem -- the
>>> Mozilla
>>> CA store is
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 to
May 2017, at 19:27, Gervase Markham wrote:
> >
> > On 11/05/17 18:05, Alex Gaynor wrote:
> >> I don't think Cory's arguing against browsers making use of these types
> of
> >> remediations, he just wants the non-browser clients to be able to
> >>
On Thu, May 11, 2017 at 1:03 PM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> 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
Ryan,
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).
Unfortunately, w
Thanks Kurt.
Alex
On Mon, May 8, 2017 at 11:22 AM, Kurt Roeckx via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 2017-05-08 15:31, Alex Gaynor wrote:
>
>> I'm not the best way to phrase this, so please forgive the bluntness, but
>> I
&g
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
no
Hi Rick,
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
many of
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
leads
Hi all,
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:
https://crt.sh/?q=54EFD2977D89EDE24DDC3797CEB5A80668B3905788B58FB1AC6893EF4B78A24A
https://crt.sh/?q=D7D90D0FCFB5CDEC5754
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
ens
Hi Gerv,
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 v
(I work for Mozilla, but this email doesn't necessarily reflect the views
of Mozilla).
Hi Steve,
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 custom
On Thu, Apr 27, 2017 at 3:52 PM, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> 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 c
1 - 100 of 104 matches
Mail list logo