As Matthew highlights, this is not a new or novel interpretation.
It was introduced in Ballot 164 -
https://cabforum.org/2016/03/31/ballot-164/
The first discussion of this in the CA/B Forum as a Ballot was
https://cabforum.org/pipermail/public/2016-February/006893.html . This
discussion
The issue I see with that interpretation is that the very same matter has
previously been discussed on this list and resolved quite vocally in the
favor of the other position: that making careful choices about the CSPRNG
output to conform it to mask out the high order bit makes the output of at
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,
Mike Kushner via dev-security-policy
writes:
>EJBCA was possible the first (certainly one of the first) CA products to use
>random serial numbers.
Random serial numbers have been in use for a long, long time, principally to
hide the number of certs a CA was (or wasn't) issuing. Here's the
>From our side, a validation agent weirdly scoped the domain, saying that the
>domain was approved using an email to ad...@in-addr.arpa. However, the email
>clearly went to ad...@5.168.110.79.in-addr.arpa. We're looking to see 1) how
>did the validation staff override the domain approval scope
I'd like to take a moment to point out that determination of the beneficial
ownership of business of various sorts (including CAs) can, in quite a
number of jurisdictions, be difficult to impossible (short of initiating
adverse legal proceedings) to determine.
What does this mean for Mozilla's
I am not so sure that is proper to have .arpa domains in the SANs.
But I think the larger issue I think is that this might allow for non
in-addr.arpa domains to be used as well.
It was just that I just tried to get a cert for my domain for a test to
see if that would be issued.
And upon
Is it even proper to have a SAN dnsName in in-addr.arpa ever?
While in-addr.arpa IS a real DNS heirarchy under the .arpa TLD, it rarely
has anything other than PTR and NS records defined.
Here this was clearly achieved by creating a CNAME record for
69.168.110.79.in-addr.arpa pointed to
Le mardi 26 février 2019 16:35:11 UTC+1, Hanno Böck a écrit :
> This statement repeats the claim that you wrote here previously,
> specifically:
> "I want to assure you that DarkMatter's work is solely focused on
> defensive cyber security, secure communications and digital
> transformation."
>
>
Thanks Cynthia. We are investigating and will report back shortly.
From: dev-security-policy on
behalf of Cynthia Revström via dev-security-policy
Sent: Tuesday, February 26, 2019 12:02:20 PM
To: dev-security-policy@lists.mozilla.org
Cc: b...@benjojo.co.uk
Hello dev.security.policy
Apologies if I have made any mistakes in how I post, this is my first
time posting here. Anyway:
I have managed to issue a certificate with a FQDN in the SAN that I do
not have control of via Digicert.
The precert is here: https://crt.sh/?id=1231411316
SHA256:
Thank you. I have created a bug and requested a response from T-Systems:
https://bugzilla.mozilla.org/show_bug.cgi?id=1530718
- Wayne
On Tue, Feb 26, 2019 at 8:07 AM michel.lebihan2000--- via
dev-security-policy wrote:
> Hello,
>
> While looking at CT logs, I noticed multiple certificates
On Sat, Feb 23, 2019 at 06:51:11AM -0800, alex.gaynor--- via
dev-security-policy wrote:
> (Writing in my personal capacity)
I'm writing in my personal capacity, as much as possible, as well (I am
a Tor/Tor Browser developer).
>
> One of the things that I think is important is to tease out
Thanks for the clarification.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Scott,
On Tue, Feb 26, 2019 at 3:21 AM Scott Rea via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> G’day folks,
>
> we appreciate the many suggestions made on the list to strengthen the
> entropy of random serialNumbers.
>
> One challenge we face currently is that our
This statement repeats the claim that you wrote here previously,
specifically:
"I want to assure you that DarkMatter's work is solely focused on
defensive cyber security, secure communications and digital
transformation."
The statement does not comment on the Reuters article, but it is in
stark
On Tue, 26 Feb 2019, Rob Stradling via dev-security-policy wrote:
Hi Scott. It seems that the m.d.s.p list server stripped the
attachment, but (for the benefit of everyone reading this) I note that
you've also attached it to
https://bugzilla.mozilla.org/show_bug.cgi?id=1427262.
Direct link:
On Tue, Feb 26, 2019, at 10:06, Scott Rea via dev-security-policy wrote:
> 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
Hi Scott. It seems that the m.d.s.p list server stripped the
attachment, but (for the benefit of everyone reading this) I note that
you've also attached it to
https://bugzilla.mozilla.org/show_bug.cgi?id=1427262.
Direct link:
https://bug1427262.bmoattachments.org/attachment.cgi?id=9046699
On
So then every cert signed by the keys intended for the trust store will be
CT logged?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Hello,
While looking at CT logs, I noticed multiple certificates issued by T-Systems
that have SANs that seem invalid. The first certificate I noticed is
https://crt.sh/?id=1044575692=ocsp,cablint,zlint The DNS name has a leading
/. That certificate was revoked, but I didn't see any report
Hi,
Since EJBCA as a product was mentioned we thought we could chime in with some
background and updates.
EJBCA was possible the first (certainly one of the first) CA products to use
random serial numbers. From the very beginning, 64 bit random serial numbers,
from a CSPRNG, were used. This
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
G’day folks,
we appreciate the many suggestions made on the list to strengthen the entropy
of random serialNumbers.
One challenge we face currently is that our platform (which does support higher
entropy) but only supports this at a global level. So if we make a global
change, then ALL our
26 matches
Mail list logo
