Part 2 of 2
On Wednesday, March 6, 2019 7:51 PM, Ryan Sleevi wrote:>
>DarkMatter response to the serial number issue has demonstrated
>that DarkMatter did not do the expected due diligence to investigate
>and understand the issue.
Your statement as Google's representative is quite di
Dear Ryan,
A fair and transparent public discussion requires full disclosure of each
participant's motivations and ultimate agenda. Whether in CABForum, or
Mozilla-dev-security-policy, I represent the viewpoints of my employer
DarkMatter and passionately believe in our unflagging efforts to pr
Part 1 of 2:
Dear Ryan,
A fair and transparent public discussion requires full disclosure of each
participant's motivations and ultimate agenda. Whether in CABForum, or
Mozilla-dev-security-policy, I represent the viewpoints of my employer
DarkMatter and passionately believe in our unflagging
Benjamin Gabriel via dev-security-policy:
> Dear Ryan,
>
> A fair and transparent public discussion requires full disclosure of each
> participant's motivations and ultimate agenda.
It would be neat if you could tone down your rhetoric a bit and refrain
from ad-hominem attacks. That would help t
On 2019-03-07 06:14, Benjamin Gabriel via dev-security-policy wrote:
Until such time as we have been formally advised by your employer (Google),
that you no longer represent their views in CABForum, or in this
Mozilla-dev-security-policy forum, we will proceed on the basis that all of
your st
Exactly what I was thinking
On 2019-03-07 09:21, Georg Koppen via dev-security-policy wrote:
Benjamin Gabriel via dev-security-policy:
Dear Ryan,
A fair and transparent public discussion requires full disclosure of each
participant's motivations and ultimate agenda.
It would be neat if you c
On Thu, Mar 07, 2019 at 05:17:07AM +, Benjamin Gabriel via
dev-security-policy wrote:
> On Wednesday, March 6, 2019 7:51 PM, Ryan Sleevi wrote:>
> >DarkMatter response to the serial number issue has demonstrated
> >that DarkMatter did not do the expected due diligence to investigate
>
Benjamin,
There is one theme in all of your responses and it's perfectly clear that
you feel strongly that this discussion as a whole is an attack not only on
DarkMatter's operations but on the United Arab Emirates sovereignty right
to able to have a root included in the Mozilla root store and use
Benjamin,
There is one theme in all of your responses and it's perfectly clear that
you feel strongly that this discussion as a whole is an attack not only on
DarkMatter's operations but on the United Arab Emirates sovereignty right
to able to have a root included in the Mozilla root store and use
On 07/03/2019 05:14, Benjamin Gabriel via dev-security-policy wrote:
> Part 1 of 2:
>
> Dear Ryan,
>
> A fair and transparent public discussion requires full disclosure of each
> participant's motivations and ultimate agenda. Whether in CABForum, or
> Mozilla-dev-security-policy, I represent t
I would just like to remind you all the universally accepted concept of
"Presumption of innocence". Quoting from
https://en.wikipedia.org/wiki/Presumption_of_innocence:
>The presumption of innocence is the legal principle that one is considered
>innocent unless proven guilty. It was traditional
I would just like to remind you all the universally accepted concept of
"Presumption of innocence". Quoting from
https://en.wikipedia.org/wiki/Presumption_of_innocence:
>The presumption of innocence is the legal principle that one is considered
>innocent unless proven guilty. It was traditiona
Thanks Wayne,
This comment is made entirely in my personal capacity, and should not be
assumed to reflect the views of my employer...
Upfront disclaimer: I don’t think I have an answer, but I hope I can help
define the problem.
Your question takes me back to the early days of CAs, when it took
[Writing in a personal capacity, these views do not represent those of my
employer]
On Wednesday, March 6, 2019 at 7:51:21 AM UTC-8, Ryan Sleevi wrote:
>
> As it relates to TLS certificates, which is the purpose of discussion for
> this root inclusion, could you highlight or explain why "citizen
This thread is full of strong policy reasons why DarkMatter’s intermediates
should no longer be trusted. Those reasons alone would be enough for
expeditious action. The risks to users discovered from recent reporting
reinforces them.
I hope we don’t see too long of a delay before the root store
On Thu, Mar 7, 2019 at 9:52 AM Jaime Hablutzel via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I would just like to remind you all the universally accepted concept of
> "Presumption of innocence". Quoting from
> https://en.wikipedia.org/wiki/Presumption_of_innocence:
>
>
I would like to repeat my call for establishing a set of empirical requirements
that take into account the context of DarkMatter's current position in the
industry as well as their specific request for the inclusion of a specific root
CA.
While I don't necessarily fully support the method with
On Thu, Mar 7, 2019 at 12:09 AM Benjamin Gabriel via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> A fair and transparent public discussion requires full disclosure of each
> participant's motivations and ultimate agenda. Whether in CABForum, or
> Mozilla-dev-security-poli
On Thu, Mar 7, 2019 at 10:18 AM nadim--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I think we're all choosing to kid ourselves here if we continue to say
> that the underlying impetus for this discussion isn't primarily
> sociopolitical. The sooner an end is put to
On Thu, Mar 7, 2019, 4:29 PM Ryan Sleevi wrote:
>
> On Thu, Mar 7, 2019 at 10:18 AM nadim--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> I think we're all choosing to kid ourselves here if we continue to say
>> that the underlying impetus for this discussion isn
Is the issue that a Dark Matter business unit may influence the Dark Matter
Trust Services (a separate unit, but part of the same company) to issue
certificates for malicious purposes?
or is it a holistic corporate ethics issue (in regards to Mozilla community
safety) of a Mozilla-trusted serv
On Thu, Mar 7, 2019 at 9:18 AM nadim--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I would like to repeat my call for establishing a set of empirical
> requirements that take into account the context of DarkMatter's current
> position in the industry as well as their
On Thu, Mar 7, 2019 at 10:10 AM Ken Myers (personal capacity) via
dev-security-policy wrote:
> Is the issue that a Dark Matter business unit may influence the Dark
> Matter Trust Services (a separate unit, but part of the same company) to
> issue certificates for malicious purposes?
>
> or is it
On Thu, Mar 7, 2019 at 4:20 AM James Burton via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> There isn't any monopoly that prevents citizens and organizations in the
> United Arab Emirates to get certificates from CAs and they are not
> expensive. Let's Encrypt provides
On Thu, Mar 7, 2019 at 10:20 AM Matthew Hardeman
wrote:
>
> Let's Encrypt does not quite provide certificates to everyone around the
> world. They do prevent issuance to and revoke prior certificates for those
> on the United States various SDN (specially designated nationals) lists.
> For examp
Let's Encrypt issues domain validation certificates and anyone with a
suitable domain name (e.g. .com, .net, .org ) can get one of these
certificates just by proving control over the domain by using the DNS or "
/.well-known/pki-validation" directory as stated in the CAB Forum baseline
require
I mean country location of the individual doesn't matter. They could be for
example be using a VPN to connect to Google Cloud instance and get a
certificate that way.
Thank you,
Burton
On Thu, Mar 7, 2019 at 4:53 PM James Burton wrote:
> Let's Encrypt issues domain validation certificates and
G’day Folks,
My apologies, I have been airborne without connectivity and it appears I have a
LOT of dialogue to catch up on.
At DarkMatter, we are passionate about what we do (as I know most folks
contributing here are also - just by very nature of the time and effort taken
to engage). The ope
On Thu, Mar 7, 2019 at 10:54 AM James Burton wrote:
> Let's Encrypt issues domain validation certificates and anyone with a
> suitable domain name (e.g. .com, .net, .org ) can get one of these
> certificates just by proving control over the domain by using the DNS or "
> /.well-known/pki-val
Let's be realistic, anyone can obtain a domain validated certificate from
Let's Encrypt and there is nothing really we can do to prevent this from
happening. Methods exist.
Thank you,
Burton
On Thu, Mar 7, 2019 at 4:59 PM Matthew Hardeman wrote:
>
> On Thu, Mar 7, 2019 at 10:54 AM James Burton
On Thu, Mar 7, 2019 at 11:11 AM James Burton wrote:
> Let's be realistic, anyone can obtain a domain validated certificate from
> Let's Encrypt and there is nothing really we can do to prevent this from
> happening. Methods exist.
>
I am continuing to engage in this tangent only in as far as it
I'm talking about someone from a restricted country using a undocumented
domain name to obtain a Let's Encrypt certificate and there is nothing that
can be done about it. We can't predict the future.
Thank you,
Burton
On Thu, Mar 7, 2019 at 5:23 PM Matthew Hardeman wrote:
>
> On Thu, Mar 7, 20
Nadim and Matthew,
Can you explain and provide examples for how this "set of empirical
requirements" differs from the objective requirements that currently exist?
Nadim, your latest suggestion sounds different from your earlier suggestion
that Mozilla provide a "set of unambiguous statements for
On Thu, Mar 7, 2019 at 9:20 AM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> What the people of the UAE don't have today is the ability to acquire
> globally trusted certificates from a business in their own legal
> jurisdiction who would be able to p
This thread is intended to be a catalog of general issues that come/came
up at various points in the DarkMatter discussions, but which are not
about DarkMatter specifically.
Each response in this thread should have a subject line of the single
issue it discusses and should not mention DarkMatt
On Thursday, March 7, 2019 at 11:20:54 AM UTC-5, Matthew Hardeman wrote:
> On Thu, Mar 7, 2019 at 4:20 AM James Burton via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> >
> > There isn't any monopoly that prevents citizens and organizations in the
> > United Arab Emirat
On Thursday, March 7, 2019 at 12:30:03 PM UTC-5, James Burton wrote:
> I'm talking about someone from a restricted country using a undocumented
> domain name to obtain a Let's Encrypt certificate and there is nothing that
> can be done about it.
Until they get caught and their certificates revoke
On 3/7/19 6:59 PM, Jaime Hablutzel via dev-security-policy wrote:
> So the following holds true and (from my point of view) very critical
> indeed. Quoting Benjamin Gabriel:
>
>> ...that sovereign nations have the fundamental right to provide
>> digital services to their own citizens, utilizing th
In the cause of the other discussion it was revealed that EJBCA by PrimeKey
has apparently:
1. Made serial numbers with 63 bits of entropy the default. Which is
not in compliance with the BRs for globally trusted CAs and SubCAs.
2. Mislead CAs to believe this setting actually provided 64 bit
On Thu, Mar 7, 2019 at 11:29 AM James Burton wrote:
> I'm talking about someone from a restricted country using a undocumented
> domain name to obtain a Let's Encrypt certificate and there is nothing that
> can be done about it. We can't predict the future.
>
So your assertion, then, is that whe
On Thu, Mar 7, 2019 at 11:33 AM Wayne Thayer wrote:
> Nadim and Matthew,
>
> Can you explain and provide examples for how this "set of empirical
> requirements" differs from the objective requirements that currently exist?
>
Hi, Wayne,
I think the matter of whether or not I could or should opin
Currently the Mozilla root program contains a large number of roots that
are apparently single-nation CA programs serving their local community
almost exclusively, including by providing certificates that they can
use to serve content with the rest of the world.
For purposes of this, I define a
Do you believe there is new information or insight you’re providing from
the last time this was discussed and decided?
For example:
https://groups.google.com/forum/m/#!searchin/mozilla.dev.security.policy/Government$20CAs/mozilla.dev.security.policy/JP1gk7atwjg
https://groups.google.com/forum/m/#
On Wed, Mar 06, 2019 at 08:56:47PM -0800, astronut--- via dev-security-policy
wrote:
> Setting aside the discussion about DarkMatter specifically, here are some
> ways in which having a CA in a new jurisdiction that isn't currently
> represented in the ecosystem can bring value:
>
> * Allow users
On Thu, Mar 7, 2019 at 11:55 AM Wayne Thayer wrote:
This line of thinking seems to conflate a few different issues.
>
That is true. I apologize for that, but also feel that some of these
different issues and how they'd play out in relation with this current
matter and ultimately with the inclus
On Thu, Mar 07, 2019 at 03:39:46AM -0800, nadim--- via dev-security-policy
wrote:
> I think we're all choosing to kid ourselves here if we continue to say
> that the underlying impetus for this discussion isn't primarily
> sociopolitical.
You're free to think whatever you like. You're *wrong*, b
On Thu, Mar 07, 2019 at 04:59:16PM +, Scott Rea via dev-security-policy
wrote:
> I am committed to a respectful dialogue, and I too (as others have already
> suggested here) would appreciate clear and definitive criteria in respect
> to what Mozilla requires to enable DM Trust Services to demo
On Thu, Mar 7, 2019 at 5:14 PM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> Whilst those are all good points, I don't see how any of them require the
> CA
> to control an unconstrained intermediate CA certificate (or a root
> certificate). All of those t
On Thu, Mar 07, 2019 at 10:20:34AM -0600, Matthew Hardeman wrote:
> Let's Encrypt does not quite provide certificates to everyone around the
> world. They do prevent issuance to and revoke prior certificates for those
> on the United States various SDN (specially designated nationals) lists.
> For
On Thu, Mar 7, 2019 at 5:35 PM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> In the face of exterior political force, the people of the UAE couldn't get
> *globally trusted* certificates full-stop. Off the top of my head, all of
> the widely-adopted web P
On Thu, Mar 07, 2019 at 05:30:24PM -0600, Matthew Hardeman wrote:
> On Thu, Mar 7, 2019 at 5:14 PM Matt Palmer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> > Whilst those are all good points, I don't see how any of them require the
> > CA
> > to control an unconstrain
Jakob Bohm via dev-security-policy
writes:
>This raises 3 derived concerns:
And a fourth, which has been overlooked during all the bikeshedding...
actually I'll call it question 0, since that's what it should have been:
0. Given that the value of 64 bits was pulled out of thin air (or possibly
On Thu, Mar 7, 2019 at 7:47 PM Peter Gutmann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> 0. Given that the value of 64 bits was pulled out of thin air (or possibly
>less well-lit regions), does it really matter whether it's 63 bits, 64
>bits, 65 3/8th bits,
As of 9pm AZ on 3/6/2019 GoDaddy started researching the 64bit certificate
Serial Number issue. We have identified a significant quantity of certificates
(> 1.8million) not meeting the 64bit serial number requirement. We are still
performing accounting so certificate quantity is expected to chan
Practical question:
How does the update to CABLint/Zlint work?
If a CA is choosing to issue certs with serial numbers with exactly 64 bits
of entropy, approximately 50% of the time there will be a certificate with
an 8 byte encoding of the serial number, as the high-order bit of the first
byte wi
Matthew Hardeman writes:
>Can the CA's agent just request the cert, review the to-be-signed certificate
>data, and reject and retry until they land on a prime? Then issue that
>certificate?
>
>Does current policy address that? Should it?
Yeah, you can get arbitrarily silly with this. For examp
On Thursday, March 7, 2019 at 10:17:21 AM UTC-5, Ryan Sleevi wrote:
> On Thu, Mar 7, 2019 at 9:52 AM Jaime Hablutzel via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > I would just like to remind you all the universally accepted concept of
> > "Presumption of innocence
On Thu, Mar 7, 2019 at 8:14 PM Peter Gutmann
wrote:
>
> As I said above, you can get arbitrarily silly with this. I'm sure if we
> looked at other CA's code at the insane level of nitpickyness that
> DarkMatter's use of EJBCA has been examined, we'd find reasons why their
> implementations are n
I wrote:
As I said above, you can get arbitrarily silly with this. I'm sure if we
looked at other CA's code at the insane level of nitpickyness that
DarkMatter's use of EJBCA has been examined, we'd find reasons why their
implementations are non-compliant as well.
Seconds after sending i
Matthew Hardeman writes:
>As if on queue, comes now GoDaddy with its confession.
I swear I didn't plan that in advance :-).
Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-
On Thursday, March 7, 2019 at 1:27:42 PM UTC-5, Kristian Fiskerstrand wrote:
> On 3/7/19 6:59 PM, Jaime Hablutzel via dev-security-policy wrote:
> > So the following holds true and (from my point of view) very critical
> > indeed. Quoting Benjamin Gabriel:
> >
> >> ...that sovereign nations have t
On Thu, Mar 7, 2019 at 8:20 PM Peter Gutmann
wrote:
> I swear I didn't plan that in advance :-).
I believe you. When the comedy is this good, it's because it wrote itself.
:-)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.or
On Thu, Mar 7, 2019 at 9:18 PM Peter Gutmann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Oh, and the BR's need an update so that half the CAs on the planet aren't
> suddenly non-BR compliant based on the DarkMatter-specific interpretation.
Past analysis and discussi
On Thu, Mar 7, 2019 at 8:29 PM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Past analysis and discussion have shown the interpretation is hardly
> specific to a single CA. It was a problem quite literally publicly
> discussed during the drafting and wording
Ballot 164 statement of intent is pretty clear: (arbitrary) 64 bit of
randomness was needed to defeat collisions in broken MD5.
With SHA2, the missing 1 bit does not seem to have any impact on the possible
collisions.
But BRs are not to be interpreted, just to be applied to the letter, whether
On Thu, Mar 7, 2019 at 8:54 PM bif via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> But BRs are not to be interpreted, just to be applied to the letter,
> whether it makes sense or not. When it no longer makes sense, the wording
> can be improved for the future.
>
Indee
On Thu, Mar 07, 2019 at 09:03:22PM -0600, Matthew Hardeman via
dev-security-policy wrote:
> On Thu, Mar 7, 2019 at 8:54 PM bif via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> > But BRs are not to be interpreted, just to be applied to the letter,
> > whether it makes sen
On Thu, Mar 7, 2019 at 9:47 PM Matthew Hardeman wrote:
>
> The actual text of the guideline is quite clear -- in much the same manner
> that frosted glass is.
>
> "Effective September 30, 2016, CAs SHALL generate non-sequential
> Certificate serial numbers greater than zero (0) containing at lea
On Thu, Mar 7, 2019 at 9:28 PM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> The "CS" is "CSPRNG" stands for "cryptographically secure", and "CSPRNG" is
> defined in the BRs.
>
Yes. There are various levels of qualification and quality for algorithms
and
On 07/03/2019 23:02, Ryan Sleevi wrote:
Do you believe there is new information or insight you’re providing from
the last time this was discussed and decided?
For example:
https://groups.google.com/forum/m/#!searchin/mozilla.dev.security.policy/Government$20CAs/mozilla.dev.security.policy/JP1gk7
Matt Palmer via dev-security-policy
writes:
>If you generate a 64-bit random value, then discard some values based on any
>sort of quality test, the end result is a 64-bit value with less-than-64-bits
>of randomness.
That's not what 7.1 says, merely:
CAs SHALL generate non-sequential Certifi
On Thu, Mar 7, 2019 at 11:38 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 07/03/2019 23:02, Ryan Sleevi wrote:
> > Do you believe there is new information or insight you’re providing from
> > the last time this was discussed and decided?
>
> I took ca
On Thu, Mar 7, 2019 at 11:45 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Currently the Mozilla root program contains a large number of roots that
> are apparently single-nation CA programs serving their local community
> almost exclusively, including by
73 matches
Mail list logo
