the sender and destroy any copies of this information.
> On Jul 24, 2019, at 10:42 AM, Scott Rea via dev-security-policy
> wrote:
>
> Caution: This email originated from outside DarkMatter. Do not click links or
> open attachments unless you recognize the sender and believe the con
G’day Devon et al,
Can you please detail the reason behind Google withdrawing trust for the UAE
NPKI intermediates?
Can you also please provide the timeline for the in-band delivery of the
restriction by Google? As you can imagine this will have catastrophic impact
for existing customers and
G’day Folks,
DigitalTrust first learned of the Mozilla decision via Reuters. We believe this
is emblematic of Mozilla’s approach to our application which appears to have
been predetermined from the outset.
We believe yesterday’s decision is unfair and demonstrates an anti-UAE bias
where a
in the CCADB.
Please advise if additional information relating to this change is required.
If anyone has any questions regarding this matter, please do not hesitate to
contact me.
Regards,
--
Scott Rea
On 3/19/19, 10:25 AM, "dev-security-policy on behalf of Scott Rea via
dev-securi
G’day Folks,
It was a pleasure meeting many of the Mozilla community face to face at the CAB
Forum meeting at Apple HQ last week. There are many others of you however,
whose interface to the community is right here on this list, and so I wanted to
share my perspective and feedback here on the
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
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 Compliance Concerns and Risk of Misuse Concerns:
1. Compliance
Questions have been raised about DarkMatter’s
lpful to dig up those past incidents for
such examples.
On Sun, Mar 3, 2019 at 2:47 PM Scott Rea via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org>>
wrote:
G’day Folks,
we have updated https://bugzilla.mozilla.org/show_bug.cgi?id=1531800 with the
latest actions taken by DarkMatter
A
On Thu, Feb 28, 2019 at 4:43 PM Scott Rea via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> This incident report relates to the 64-bit serial numbers in all
> certificates that DarkMatter CAs have issued since their inception. The
>
This incident report relates to the 64-bit serial numbers in all certificates
that DarkMatter CAs have issued since their inception. The dialog surrounding
CABF Ballot 164 “Certificate Serial Number Entropy” was unknown to DarkMatter
until shared with us recently by Ryan Sleevi of Google, and
point when your
> request for inclusion is at a crucial phase.
>
> On Wed, Feb 27, 2019 at 12:56 AM Scott Rea via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > G’day Wayne et al,
> >
> > I am not sure why memb
G’day Wayne et al,
I am not sure why members of the group keep making the claim that these
certificates are misused under the BRs.
Corey pointed to the following paragraph in Section 7.1 of the BRs as the
source of the control that DM is accused of not complying with:
“Effective September 30,
G’day Folks,
DarkMatter CEO (Karim Sabbagh), has provided an official response to Mozilla on
the recent media article about the UAE that referenced security and
intelligence matters. Per Wayne’s request to potentially share this on the
list, I am attaching a copy of that letter to this post.
G’day Rich,
This is correct with one qualification – every TLS cert chained to the
submitted Roots are CT logged. The exception is that we also issue Public Trust
client certificates (through a separate Issuing CA) and these are not required
to be logged. From memory, our EV’s currently go to
G’day Rich,
DM has submitted Roots intended for Public Trust to Mozilla and other browser
operators, but we also operate private trust PKIs under separate anchors. These
private PKIs also issue certificates to secure TLS in closed environments, but
Private Roots are not in public CT Logs and
2/25/19, 3:58 AM, "dev-security-policy on behalf of Scott Rea via
dev-security-policy" wrote:
I think it reasonable to expect that EVERY implementation of a
compliant CA software is doing this post-processing to ensure the intended
serialNumber has not already been used,
olicy" wrote:
Hi Scott,
Comments inline.
On February 25, 2019 at 4:58:00 PM, Scott Rea via dev-security-policy (
dev-security-policy@lists.mozilla.org) wrote:
G’day Corey,
To follow up on this thread, we have confirmed with the developers of the
G’day Corey,
To follow up on this thread, we have confirmed with the developers of the
platform that the approach used to include 64-bit output from a CSPRNG in the
serialNumber is to generate the required output and then test it to see if it
can be a valid serialNumber. If it is not a valid
G’day Corey,
I can see your point – perhaps the more accurate way explicitly allowed under
5280 would have been to encode the constraint as type uniformResourceIdentifier
rather than the type dNSName that was used.
I don’t recall if we actually tried that in our tests at the time with QV, but
G’day Corey,
I am not sure if the phrase “…outputting 64 random bits from the CSPRNG and
then coercing the most significant bit to 0” is actually an accurate
representation of what is happening under the covers – we have asked for
clarification from the developers so we can all have an
G’day Corey,
In respect to the previously issued constrained intermediates – can you clarify
where in RFC5280 Section 4.2.1.10 that the prohibition against a leading period
is specified for the name constraints?
I see in the RFC the specific sentence: “When the constraint begins with a
G’day Corey,
I did not check your math, but is it possible that you are interpreting the
serial number conversion output as an unsigned integer representation? If so,
then I can understand your potential concern regarding the findings of your
analysis.
DarkMatter uses an EJBCA platform with
38PM +0400, Scott Rea via dev-security-policy
wrote:
> G’day Wayne et al,
>
> In response to your post overnight (included below), I want to assure you
that DarkMatter’s work is solely focused on defensive cyber security, secure
communications and digital transformation.
G’day Wayne et al,
In response to your post overnight (included below), I want to assure you that
DarkMatter’s work is solely focused on defensive cyber security, secure
communications and digital transformation. We have never, nor will we ever,
operate or manage non-defensive cyber
24 matches
Mail list logo
