On 2/23/19 11:07 AM, 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. We have
Op zaterdag 23 februari 2019 20:38:51 UTC schreef Todd Troxell:
> IDK this seems like an obvious one to me. Let them find another way. We don't
> have to make it easy.
>
> -Todd
It should also be noted DarkMatter has very strong ties with the UAE government
and operates the UAE national PKI
This certificate already infested all major browsers. Removing it breaks a lot
of pages and gives you Invalid certificate error.
TOR, Chrome, Firefox... all infested.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
This seems like an absolute no-brainer to me. DarkMatter's past behavior and
line of business are fundamentally incompatible with the level of trust reposed
in CA's. This is not even a close call. I believe Mozilla should:
1. Deny the root inclusion request;
2. Add the intermediate CA
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
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
On Sunday, February 24, 2019 at 7:39:34 PM UTC-5, Scott Rea wrote:
> 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
On Sunday, February 24, 2019 at 8:05:10 PM UTC-5, Scott Rea wrote:
> 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
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
On Friday, February 22, 2019 at 4:28:30 PM UTC-5, Corey Bonnell wrote:
> Hello,
> Section 7.1 of the Baseline Requirements states that, "Effective September
> 30, 2016, CAs SHALL generate non-sequential Certificate serial numbers
> greater than zero (0) containing at least 64 bits of output from
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
On Mon, Feb 25, 2019 at 02:11:40AM +, Scott Rea via dev-security-policy
wrote:
> My anticipation is that what happens is that CSPRNG process is repeated
> until a positive INTEGER is returned. In which case a 64-bit output from
> a CSPRNG is contained in the serialNumber as is required.
Matt Palmer via dev-security-policy
writes:
>Imagine if a CA said "we generate a 64-bit serial by getting values from the
>CSPRNG repeatedly until the value is one greater than the previously issued
>certificate, and use that as the serial number.".
Well, something pretty close to that works
13 matches
Mail list logo
